We’ve implemented a workflow that is instantiated by the API method runtimeAPI/instantiateProcessWithVariables().
This method should return the instance UUID.
During our tests, we found it took time to return the value, causing functional timeout exception (partner waiting too long cuts off the comm).
Further investigation of log file shows that returning instance UUID will not take place until all automatic steps have finished. In fact, we have many automatic steps between the start event and the first humain step.
Could you please confirm this assumption: runtimeAPI/instantiateProcessWithVariables() will not return instance UUID as long as there are still automatic steps taking place; the return will be done at the beginning of first humain step. If so, how can we prioritize the task of returning instance UUID?
in V5.10, the engine run all service task when you create a case, then give back the result.
This is a main difference with the V6 : in V6, all are asynchronous. Case is created, API is return, then the engine do all the service task.
By the way, in V5, you can control this asynchronous : look for starter event on your process, then go to the tab “general”, then “Advanced” and you have here a check box “Synchronous”, which are checked by default. uncheck it.
We’ve made tests, which show a behavior that is consistent with the assumption.
We added a human step between the start event and the first step, with a timer set so that the process could continue without human intervention in some seconds.
As expected, we cut the time of instance UUID returning down to less than 10 sec, while it always took 20 to 40 sec formerly. We checked log file and confirmed that instance UUID was returned as soon as the added human step was ready.
We don’t want to change the workflow to remedy a performance issue. So: how can we prioritize the task of returning instance UUID over other step or connector executions?
I set the start event as asynchronous and got the response very quick. There are still some starting connectors before API is returned, I suppose these connectors are globally effective and are started even before the start event. I guess with V6 the return of API will totally decoupled with these kind of connector executions, am I right ?
Further question:
what would be your suggestion on this setting if we expect simultaneous starting of the same process (with independent subject) ? We are initiating from third-party application with API call, it happens that more than one agent start the same business process from their own web page.
Can we make a human step asynchronized if we don’t have any business data transaction outside the process (I mean each process is really independent from others: no data synchronization needed) ? We’ve seen certain “system busy” behavior when two agents advance with their own task on the same time during a stress test : one waiting another causing timeout.
Well, move to version 6 ! Jobs are completely asynchronous in V6 (and the version is close to 2 years old now).
1.what would be your suggestion on this setting if we expect simultaneous starting of the same process (with independent subject) ? ==> No suggestion. Two cases will be created by the engine.
2.Can we make a human step asynchronized
==> Human step are asynchonized per nature.
(I mean each process is really independent from others: no data synchronization needed
==> I don’t understand. by “each process” you mean each process (pool) or each case (process instance) ? In both case, data are independent, until you use Messages.
We’ve seen certain “system busy” behavior when two agents advance with their own task on the same time during a stress test
==> My recommendation is 1/ to move to V6, 2/ use a Subscription version, because some service in the subscription are different, and are developed for this kind of management. On a Subscription, tests show that you can manage more than 100 000 process instance at the same time without any issue (issue come from connector in general). And then you can access to the Cluster function, and different management tool to check what’s happen on the system.
Bonitasoft empowers development teams with Bonita, the open-source and extensible platform to solve the most demanding process automation use cases. The Bonita platform accelerates delivery of complex applications with clear separation between capabilities for visual programming and for coding. Bonita integrates with existing solutions, orchestrates heterogeneous systems, and provides deep visibility into processes across the organization.