About Process Execution
This section explains how a process is triggered and how the servers run the process steps.
Important: | The explanation assumes that the default quality of service settings for the Process Engine are applied; the default settings are designed for best performance. For more information about the default quality of service settings for processes, see Setting Quality of Service for a Process. For more information about tuning the Process Engine, see "Overview of Tuning" in Administering webMethods Process Engine. |
1. At startup:
a. When Universal Messaging or Broker is present, all Integration Servers synchronize document types with the message provider at startup, ensuring that all subscribed document types exist on the message provider as well.
b. Each Integration Server reads all packages that were generated by Designer and loads its process description file into memory.
2. An external application publishes a document to which the process trigger subscribes. This document is placed on the trigger's client queue.
3. The trigger on the server that runs the start step retrieves the document and passes it to the Process Engine service that handles external input documents. The Process Engine reads the Process Audit Log database component to find out if the process model is enabled and what the current model version is.
a. If the process is not enabled, the Process Engine service exits and the trigger sends an acknowledgment for the external document and discards the document without starting a process.
b. If the process is enabled, the Process Engine loads the document content into server memory, and the server runs the start step.
4. Step execution is handled as follows:
a. If step 2 is designed to run on the same server as step 1, the server passes the pipeline from step 1 to step 2 and runs step 2.
b. If step 2 is designed to run on a different server than step 1, step 1 produces a process transition document:
a. The Process Engine publishes the process transition document.
b. The Process Engine for the server that runs step 2 loads the document content into server memory and runs step 2. If webMethods Broker is installed, the data flow would be:
c. If step 2 is the start step for a referenced process, step 1 produces a referenced process start document instead of a process transition document.
d. The Process Engine publishes the referenced process start document. The trigger on the server that runs the referenced process start step retrieves the document and passes it to the Process Engine. If the Process Engine is configured to optimize referenced process execution, the referenced process is invoked directly rather than by a publishing a referenced process start document.
e. The Process Engine loads the document content into server memory. The server runs the referenced process start step.
5. The process continues to execute steps in this manner until the last step is complete.
For steps with AND joins or COMPLEX joins containing AND logic, the server waits until the Process Engine has received all required external documents, process transition documents, and referenced process documents to satisfy the join, and then runs the step.
Referenced processes use a referenced process done document (failure) or a referenced process return document (success), as appropriate, to transition back to the next process step. The trigger on the server that runs that next process step retrieves the document and passes it to the Process Engine. If the referenced process completed successfully, the Process Engine loads the document content into server memory so the server can run the new process step.
If the entire process runs on the same server and does not branch into multiple execution paths or contain referenced processes that are not optimized for local execution, when the process is complete, the trigger sends an acknowledgment for the external document that was the input to the start step.
