Martyn Houghton Posted October 20, 2016 Share Posted October 20, 2016 In the recent ESP release there is reference to a experimental setting bpm::processResume for performance improvement, is there any further details on what his setting changes. Cheers Martyn Link to comment Share on other sites More sharing options...
Lyonel Posted October 20, 2016 Share Posted October 20, 2016 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 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. Link to comment Share on other sites More sharing options...
Victor Posted October 20, 2016 Share Posted October 20, 2016 @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. Link to comment Share on other sites More sharing options...
Lyonel Posted October 21, 2016 Share Posted October 21, 2016 Fair point @Victor! Thanks for the clarification Link to comment Share on other sites More sharing options...
Martyn Houghton Posted October 24, 2016 Author Share Posted October 24, 2016 @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 Link to comment Share on other sites More sharing options...
Victor Posted October 24, 2016 Share Posted October 24, 2016 @Martyn Houghton to be honest I am not sure, perhaps one of the dev team members has more insight on this... Link to comment Share on other sites More sharing options...
Gerry Posted October 24, 2016 Share Posted October 24, 2016 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 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now