Jump to content

Recommended Posts

Posted

Hi @Martyn Houghton, if I am correct this setting allows the system to create the new request and trigger the BPM asynchronously. Which means that you get a confirmation pop-up that your request has been created sooner as you do not need to wait until the BPM is started. 

In my case, this is very useful as our BPM has a very complex start before it hits a "suspend" task. It was causing issues on our instance and although new requests were actually created immediately, it was taking up to 15s to get the confirmation pop-up. Now we only have to wait 2-3s!

There is one downside to this though: depending on your setting / implementation, the confirmation pop-up could potentially be misleading. In our case, we auto-assign the team in the BPM (which is partly why it is so big!). As the new request is created at the same time as the BPM starts, generally the pop-up indicates that the call has not been assigned to a team yet. Also, when you click on the "View" button, the request appears as if the BPM did not start. But if you refresh then it all works and comes back to normal.

Sorry if my explanations are a bit fuzzy :blink:

Bottom line, this experimental feature allows you to raise a new request independently of the BPM being triggered. Very useful to gain performances, but it has some drawbacks you need to be aware of.

Posted

@Lyonel I think you are referring to experimental.bpm.spawnAsync. This setting is responsible for the behavior you described. What @Martyn Houghton was asking about is experimental.bpm.resumeAsync. This one does, in technical terms, the same thing but the difference is that "spawn" acts on request logging and "resume" acts on process resuming following a user action in relation to "Wait For..." type of nodes in BP configuration.

Posted

@Victor 

Thanks for the clarification, I presume the issue where the current request is not updated on the browser session automatically when the underlying BPM is updated is the thing to be aware of when trying this setting?

Cheers

Martyn

Posted

HI Martyn,

The reason why we have made it a setting was to ensure we could soft rollback should there be any problems experienced, we are aiming to move all lengthy BPM operations to asynchronous behaviour.  One of the things that has come out of looking at this is the need to have HUD notifications for display updates, this is done, or in the process of being done so this is a bit of a work in progress.  If its causing any problems please switch it off or make your users aware that there may be background tasks/updates happening for a few seconds after the request is logged. 

Gerry

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...