How is MultiThreading Handled in webMethods.Can any one Please explain?
How to achieve MultiThreading in webMethods…
For example i have three services one of them takes lot of time to execute and i dont want to wait for that service to complete its process as its output does’nt reflects the following services.
In such situation i dont want to wait for a service whose output doesnt effect the services after it.
How about calling those services inside a Map as Transformers?
Transformers are not run in parallel. The documentation states:
“Transformers in a MAP step are independent of each other and do not execute in a specific order. When inserting transformers, assume that webMethods Integration Server concurrently executes the transformers at run time.”
The key word is “assume.” Based on observation, and in thinking about how an implementation would handle the complexity and overhead of threading each transformer, I’m confident that transformers are not executed concurrently. In a previous thread on this topic years ago, someone confirmed this observation.
Other than not wanting to wait, is there any other technical reason to not wait? Have you considered how to handle and address errors by introducing additional complexity?
It may be worth seeing if the long-running service can be split out from the others altogether and kicked off on its own.
Thank you for quick reply…
If we are using the service as a transformers in a service …then the service will be in the waiting state…until the transformer completes its job.
I dont want any delay in my flow…
I want to make a service asynchronous…
My idea is to make a service asynchronous …
Is it possible to achieve this in webMethods…?
Let me reemphasize—using transformers does not involve multiple threads. The service will not be “waiting.” It will be executing the transformers, serially.
How about making use of doInvoke ?
It may make the parent service independent of the chaild execution.
You can use the Java API, doThreadedInvoke.
You could publish an event to the Broker and have a trigger that runs the service. You could publish the event locally, avoiding Broker.
You could split the service out from the other service and have them both kicked off by something external.
All of these add complexity to the solution. Make sure the added complexity is worthwhile and not just because you don’t want a service to have to wait.
Okay… I think, I got your point… You are looking for something like PSUtilities.misc:spawnThread service… this service basically takes fully qualified name of a flow/java service with inputs and invokes a separate thread to execute the same… the output of the threaded service will not be available for the parent service… parallely both executes without depending on each other…
HTH
Senthil
Thank you Senthil…
Yes you got what i want…will try that
I would avoid using doInvoke or doThreadedInvoke or any other code to invoke threads in nearly all cases. The natural ways to achieve multithreading in webMethods are
-
publishing a document and setting the receiving trigger to parallel with defined number of max threads (That’s what Rob already described).
-
if you are using processes, you can just draw parallel connections from a step to several following steps. If appropriate, you can join in afterwards with an and join to wait for all steps to finish. Parallel path in processes are processed in parallel (if the path are not limited by a condition).
Both are imho good and proven ways in webMethods to achieve parallel processing.
Regards
Martin
Publish the data (required for other services in the flow other then service which takes lot of time to execute) before that service which takes time. this way published document can be subscribed from broker through trigger which in turn execute rest of the flow steps in called service.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.