Workflow

Error Handling for Background Processes and Activities

 
  1. The server which is needed for background execution objects (process or activity), is started up by the watchdog using ECI. In case of a startup error of the server, an exception is thrown and an entry is written in the history with detailed information about the error. Possible problems are e.g. the Java daemon is not running or the environment is not set properly. During the startup of the server the watchdog and the batch executor are running synchronously. The batch call itself is asynchronous. The execution object changes to the state "Try to start (batch)".

  2. If the execution object (process or activity) is too long in the state "Try to start (batch)", the user responsible for the process is informed about this via email. The period after which this happens can be set in the ABS.ini with the value "MaxBatchStartupTime". The default value is 30 minutes. If the problem is solved, the corresponding process has to be suspended and resumed by the user responsible for the process and will then start from the beginning. This information is also written in the email that is send to the responsible user.

  3. If the server startup was successful, a trace file is written in the default tmp directory. It is still possible that something is going wrong before the execution object state is set to "Execution (batch)", e.g.: the widget is not there or cannot be opened or the parameters which are passed to the LogiView program do not match. This information is not written to the history but into the corresponding trace "*.out" or "*.err" file. If the problem is solved, the corresponding process has to be suspended and resumed by the user responsible for the process and will then start from the beginning. This information is also written in the email that is send to the responsible user.

  4. If an error occurs during processing of the background execution object, the state changes to "Error (batch)" and the user responsible for the process is informed. After solving the problem the corresponding process has to be suspended and resumed by the responsible user for the process and will then start from the beginning. This information is also written in the email that is send to the responsible user.

  5. If everything works fine during processing the execution object changes to the state "Waiting compl. (batch)" and a history entry is created: "Execution object processed successfully. Waiting for completion." When the watchdog is waking up, it will look for these objects and complete them. With this additional step a connection between Agile e6 and the external server is avoided. The server is now completely independent after it started up.

  6. All messages should be send only once.

  7. Additionally the maximum number of external servers (every server needs a license) running simultaneously is limited to avoid a shortfall of licenses at the customer's site. The value can be changed by the user in the ABS.ini - look for the entry "MaxBatchCallNumber". The value is checked with every start of a new batch executor so changes will become effective immediately within the next wake up of the watchdog. The default value is 5. If a value less than 1 is set a warning will be written in the trace file: "WARNING: Maximum number of simultaneous background processes is set to 0! Reset to 1!!". During the processing of several background processes or activities some of them may have to wait another round for the watchdog because simply the maximum number of simultaneously running servers is reached.

  8. Results may be conflicting and overwriting each other when workflow processes are modelled with the following wrong settings:

    A. Split-XOR with non-automatic resource and a LogiView procedure as background batch process



    Please note that with a non-automatic resource the LogiView procedure must be written in the On Complete field!


    B. Split-XOR without a resource and a LogiView procedure as background batch process

Please note that for the JavaClient all xwfl-userexits don't work in the batch mode (background processes). Therefore, a process that is to start automatically can't be started since the userexit "xwfl_prc_ins_tpl" returns the error code=1!