SugarBPM and performance, best way to reduce the amounts of saves on a module?

Hello there,

I am working with a customer on one of my own specialties, SugarCRM performance improvements.

Sugar always said: "Consolidate BPMs, it's better for performance", so let's do that!

I have two questions here:

  1. First of all, are there public resources on the latest best practices to improve the performance of SugarBPM processes?

  2. The second question is most likely about a misconception I had, and it is more involved.

    I was under the impression that if we have 2 simple processes, changing a field within the same module/record, it would equate to 2 more saves. Simple, expected. But what about consolidating them?

    What I didn't expect is, that after consolidating the 2 simple processes in various ways (the actions on field changes need to be separate as they have different conditions), and creating a before save logic hook that logs a log entry to confirm how many saves happen, the record still saves 2 more times when both actions trigger.

    So finally we have the question: Are there any ways to complete all save actions within a process, in a single backend sugar save call, or that's not possible?

Thank you in advance for your guidance

Parents
  • Hi  ,

    With regards to #2, I don't think it would be a good idea to consolidate actions within a process to a single save event. Each action on a process should be treated as its own event in my opinion. I understand the desire to make things more performant, but there are scenarios where those actions need to save independently.

    When accounting for elements like wait timers, event-based gateways, etc., I don't know how you could group specific actions within a design to complete together without causing potentially unintended side effects whether it be in the same or another definition.

    Chris

  • Hey  ,

    Hope you are well!

    Thanks for your insights.

    In my opinion, the system should be "smart enough" to understand if actions are subsequent, on the same path, and change some fields, and some other fields and some more.

    Why would those be treated as 3 separate save actions by the system and not one? Or at least the system could notify the user who is editing the process to optimise and combine the actions into one. I personally did not expect multiple saves, one for each subsequent action.

    Do you see this system improvement could potentially create problems?

    To give you a little bit more context, in this specific case, the customer had multiple BPMs, multiple actions per BPM, sugar logic formulas, related (circular) formulas and multiple logic hooks.

    A record save would take 45+ seconds. This would happen on the first save and on every subsequent save (even just a change of a description field). Which was unbearable for the users, hence they reached out. There are valid reasons why they needed each component (related records that needed savings, shortcomings etc). And every save would re-trigger most of the logic outside of the BPM again.

    This time, I had to write substantial backend code to achieve the same outcome, refactor the formulas, the hooks and the BPMs for optimised performance. The system now runs only the logic absolutely needed, when needed. Now only if all the business conditions need to trigger, a save takes about 30 seconds (which normally happens once per record only), then every other change takes < 2 seconds, which is a massive improvement. You could argue that potentially is less flexible to change for the future (which is also a positive for critical business processes that need deep testing such as this one), but it produces a big user experience and ongoing productivity improvement.

    --

    Enrico Simonetti

    Sugar veteran (from 2007)

    www.naonis.tech


    Feel free to reach out for consulting regarding:

    • API Integration and Automation Services
    • Sugar Architecture
    • Sugar Performance Optimisation
    • Sugar Consulting, Best Practices and Technical Training
    • AWS and Sugar Technical Help
    • CTO-as-a-service
    • Solutions-as-a-service
    • and more!

    All active SugarCRM certifications

    Actively working remotely with customers based in APAC and in the United States

Reply
  • Hey  ,

    Hope you are well!

    Thanks for your insights.

    In my opinion, the system should be "smart enough" to understand if actions are subsequent, on the same path, and change some fields, and some other fields and some more.

    Why would those be treated as 3 separate save actions by the system and not one? Or at least the system could notify the user who is editing the process to optimise and combine the actions into one. I personally did not expect multiple saves, one for each subsequent action.

    Do you see this system improvement could potentially create problems?

    To give you a little bit more context, in this specific case, the customer had multiple BPMs, multiple actions per BPM, sugar logic formulas, related (circular) formulas and multiple logic hooks.

    A record save would take 45+ seconds. This would happen on the first save and on every subsequent save (even just a change of a description field). Which was unbearable for the users, hence they reached out. There are valid reasons why they needed each component (related records that needed savings, shortcomings etc). And every save would re-trigger most of the logic outside of the BPM again.

    This time, I had to write substantial backend code to achieve the same outcome, refactor the formulas, the hooks and the BPMs for optimised performance. The system now runs only the logic absolutely needed, when needed. Now only if all the business conditions need to trigger, a save takes about 30 seconds (which normally happens once per record only), then every other change takes < 2 seconds, which is a massive improvement. You could argue that potentially is less flexible to change for the future (which is also a positive for critical business processes that need deep testing such as this one), but it produces a big user experience and ongoing productivity improvement.

    --

    Enrico Simonetti

    Sugar veteran (from 2007)

    www.naonis.tech


    Feel free to reach out for consulting regarding:

    • API Integration and Automation Services
    • Sugar Architecture
    • Sugar Performance Optimisation
    • Sugar Consulting, Best Practices and Technical Training
    • AWS and Sugar Technical Help
    • CTO-as-a-service
    • Solutions-as-a-service
    • and more!

    All active SugarCRM certifications

    Actively working remotely with customers based in APAC and in the United States

Children
No Data