Skip to main content

XML extensions and XBIS web service

  • November 1, 2013
  • 8 replies
  • 0 views
A
  • Anonymous

I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


Thanks

Tony

    8 replies

    D

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    Usually this means that process doesn't have permissions to create the file.  My guess, because this is not my area of expertise, is that the XBIS Web Service doesn't have permission to write to its current working directory.  You either need to use a complete pathname that your service program has write permissions to, or change the directory in which the service program runs.  (I'm not sure how to do that off the top of my head, so I recommend trying to change the pathname first.)

    A
    • Anonymous
    • November 4, 2013

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    Thanks, Mike; I do understand that the error usually indicates a permission problem. That's why I specifically changed permissions on the folders used to allow full access to "Everyone" - which should include whatever user the Acu program is running as when launched by XBIS.

    Interestingly, if I create the XML file first, as a one-byte flat file, the XML EXPORT FILE command then works correctly - it over-writes the one-byte dummy file I created in the Cobol program with the correct XML data.  It seems the problem is limited to creating the XML file, and only under XBIS.

    I have a similar problem where the subsequent commands ("JAVA -jar saxon.jar"  to create the FO file, and then FOP.BAT to create the PDF from the FO) also do not work.  The exact same code, however, works just fine when run as a local program from the same folder with the exact same data.

    D

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    It sounds like you are working on the Windows version of BIS.  Is that correct?

    A
    • Anonymous
    • November 4, 2013

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    Yes, correct

    D

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    Hi Tony:

    Follow-up questions:

    1. What version of Windows you are using?
    2. What identity did you configure XBIS to use (just say "custom identity" if you created a special one for BIS)?  If you didn't specify any identity, it's likely the "INTERACTIVE USER". 
    3. What is the full path that the XML EXPORT FILE is using?  Are you trying to write files into the web tree under inetpub?

    You said

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    You mentioned BIN and BIN\\XML receives the XML files -- are these directories under INETPUB, "Program Files (x86)" or somewhere else?  

    There are unfortunately many factors that combine to determine permissions, and for BIS, some of those depend on the BIS identity you are using; that in turn, varies with the version of IIS that you are using.  If you are dynamically creating files under your web tree (that is, inetpub\\wwwroot), you're probably aware that this directory is pretty heavily locked down to ensure that an anonymous user (or even an authenticated user) can't upload a file to your server, and then serve it to the world.  So if this is where your XML files are being created and the problem is that BIS can't write to this directory, I'd suggest you export the XML files somewhere else (say, to your TEMP directory) and then only copy the final PDF files back into your web tree (assuming the process that creates those files from the XML files is able to write to the output directory).  Note that the default BIS exchange file location is the TEMP directory for this very reason.

    If you really do want to write to a directory under inetpub, here are some things you can try (the exact solution depends on the version of IIS you are using, and the BIS identity configuration):

    • Grant the BIS application pool identity full permission to the directory. You can find the name of the application pool for your web in the IIS administrator. This is for IIS 7.5 or later only; for example, the default identity created during the BIS installation is AppPool\\acuxbis-Application-Pool-32 (replace the part after the slash with your chosen identity, if you created a separate pool).
    • For IIS 7, try granting the identity "Network Service" full permission to the directory.
    • For IIS 7, change the application pool identity from "Network Service" to the all-powerful "Local Service".  
    • As an experiment, grant user IUSR full permission to the directory.  This might work for any version of IIS.
    • As an experiment, grant user ANONYMOUS full permission to the directory.  Note that, since XP, "Everyone" does not include "Anonymous" without a system-wide security policy change.  This might work for any version of IIS.

    Be sure to undo anything above that doesn't work.  And if your BIN\\XML directory is not under the INETPUB directory, then the above doesn't apply.

    If, during BIS configuration, you created a custom identity, you could grant full permission to that identity to the output directory. But that should be covered by "Everyone". 

    Also, be aware that if you chose "Interactive User" as the default BIS identity during installation, BIS will run with the credentials of the currently logged-in user, but once you log out, it will revert to anonymous credentials.  So if you're seeing different behavior when you're logged in vs. not logged in, this might explain it.

    If you can answer the three questions above, I can probably give you more specific advice.


    #BIS
    D

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    >> is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?

    No, there is no such option or necessity for such an option.  As stated by others, it is probably a permissions problem.  A good place to put temporary files under BIS is the same directory where the exchange files are put, which is necessarily writable by the application.  This can be found by using the path portion of of the value of the environment variable BIS_FILENAME.  If the value is null, then you are not running under BIS.  If BIS_FILENAME has a non-null value, then it is the full name of the exchange file.

    A
    • Anonymous
    • November 7, 2013

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    Thanks, Bruce and Uwe; I can't say that I determined what the underlying permission problem was, but I did realize that I preferred to have the application reside elsewhere than under the wwwroot structure.  Once I moved the application into its own folder, outside of the wwwroot path, the permission problem related to create the XML using XML EXPORT FILE disappeared.  

    I am going to try the Anonymous idea (I'll need to put my files back under the wwwroot path), as I'm curious as to whether that would handle it.  That's not a system user I'd come across before, so I appreciate the feedback.

    I also appreciate the info on BIS_FILENAME; that will indeed be useful for temporary files.

    Again, many thanks to both of you for the time you spent answering.

    Tony

    D

    I have an Extend 9.1.1 program (PDFSTATEMENT) which produces an XML file, using XML extensions (XML EXPORT FILE).  This program is called from a calling program (DOPDF2) that passes just 3 arguments to it.  It works correctly, producing an XML file (and then a PDF as a second step)

    When I call the same program to produce an XML file, from a program that is invoked by a call to an XBIS web service, with the same 3 arguments as in the first case, the XML EXPORT FILE statement fails with status code 13 - which means the creation of the XML file failed.


    If the specified XML file already exists (even if it is a 1-byte file with a space in it), then the XML EXPORT FILE command executes successfully and creates the XML file!  However, if the XML file does not already exist, the create fails.

    I have changed permissions on the bin folder containing the ACU programs, and on the BIN\\XML subfolder where the XML file is created, to have full access for "Everyone" - same results.

    I don't understand why the XML EXPORT FILE fails - is there some option which needs to be set to allow XML EXPORT FILE to be created if it does not exist (like an OPTIONAL clause in Cobol) work when called from a program that has been invoked by XBIS?


    Thanks

    Tony

    You're welcome -- glad we could help.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement