A process can have a timeout condition.  However, there are confusions on why to use it, when to use it, and how to use it.

In conventional webMethods publish-subscription model, a transaction is executed following the steps below:

1)Transaction document is published to the broker, and queued on the broker for trigger to pickup.
2)Subscription trigger picks up the document, and invoke a trigger service.
3)Trigger service finishes the execution, sends acknowledgement to the broker to delete the broker document.

Typically a broker document never expires. If for some reason, the link between broker server and integration server is broken, the document will be queued on the broker. Once the link is re-established, the document will be consumed by trigger service. However, if we set Time-To-Live (TTL) for the broker document, the document may get lost in unusual circumstances such as an integration server or network outage if the outage duration is longer than TTL of the broker document, which is non-desirable in most of the conditions.

In a process model based solution, a transaction is executed following the steps below:

1)Transaction document is published to the broker, and queued on the broker for trigger to pickup.
2)Subscription trigger picks up the document, stores the document in the process queue table, signals the start of the process execution, and sends acknowledgement to the broker to delete the broker document.
3)Separate PRT threads scan the process queue; execute the processes in the table in the order when the process documents are persisted.

If a process timeout is defined, when integration server starts running a process’s start step, the Process Engine for that server creates a timer object in RAM and stores the timeout in the Process Engine database. If the Process Engine receives a status control document indicating process completion before the timer expires, the Process Engine cancels the timer. Otherwise, Timeout handler is invoked, and signals the failure of the process execution.

The risk of setting process timeout is the same as setting TTL in broker document. If unusual circumstance occurs, transactions queued in the process queue table may be executed in non-desirable fashion. For example, if the process timeout is set as one day, then after a weekend server outage, all the documents in process queue will be in timeout condition. In webMethods 7.1, the queued documents will be processed after the server is back. However, timeout will be invoked as well, signals the failure of the each process even the processes is executed successfully, resulting “false timeout”.

Even there is no server outage, if the server can’t process the incoming documents in time due to workload or performance issue, documents will stay in process queue longer than process timeout duration, resulting in the same “false timeout” problem mentioned above.
Is there a usage for process timeout? Surely there is. For example, a process to get the real-time stock quote may have a timeout of 2 seconds as this is a time-sensitive event. Process timeout should be determined by business requirements, not some default value set by webMethods tool, or some random number from our imagination.

However, because of the product stability or server stability issue, we have seen an executing process in an unusual status after long time. For example, an order process is still in the “Started” status after 12 hours. Some suggest that we use a process timeout to capture this kind of problem, signal the failure of the process, and notify support person. This is well-thought, but non-practical in reality. The main problem is how long the timeout should be. If it is too short, then “false timeout” will surface. If it is too long, then it defeats the purpose of setting a process timeout. However, to address this concern, I suggest that we schedule a house-keeping service to notify support person if any processes are in unusual status after certain time. For example, we can notify support person if any order processes are not in the Completed or Failed status after 12 hours.

In summary, the main difference between traditional publish-subscription approach and process model based approach is that transaction documents are queued on the broker in traditional approach, but documents are queued in process queue table in the process model approach. The executions are similar though. TTL or timeout should not be defined unless it is required by business.