Perhaps, I might be approaching this solution incorrectly. To borrow a statement from ODC:

"In the context of O11, a Server Action would typically be used at this point. However, ODC doesn't allow Server Actions to be exposed across apps. Consequently, we need to utilize Service Actions."

I opted to translate these automated activities into Service Actions.

For the web client app, I simply encapsulated these Service Actions within Client Actions and employed them in the following manner:

The UpdateSageQuote automatic activity is not included here, as it should only be executed when a quote is revised or signed. Thus, it makes more sense to schedule it as a timer, and also provide the user with an option on the client side to trigger a manual sync update if necessary.

I'm unsure if this approach is considered the best practice for this scenario, but I have conducted tests, and thus far, it appears to function as if it were a part of the standard process, occurring in real time in the background. Nevertheless, I should consider adding a loading indicator to the submission screen to inform the user that the process is ongoing, as it takes a few seconds to complete the action flow. 

Hi @André Smit ,

i don't have the answer to your question, but just some observations :

Automatic activities and the logic inside them, and decision points are not the problem, they can all be implemented as bits of logic inside actions.  It is the flow, the waits and the human activities, and the ways steps in the flow are triggered that need attention.

1) CreateSageQuote, UpdateQuoteStatus and EmailQuote are 3 pieces of logic that always get executed together and in that sequence ? So the fact that they were modeled as 3 automatic activities in O11 is just an arbitrary design choice ?  It looks like each of these automatic activities (the logic in them) can be done by a service action, or even 3 server actions inside 1 single service action.

2) I guess the process got triggered at some point (by what), but there was a point later in time where the quote came into status "generated", and only then, you could start adding it into sage ? why and how long does that take ?  It's hard to help think about replacing that first "wait" part of the process without knowing this.

3) The 'WaitUntilUpdated', what is that waiting for exactly ?  t's hard to help think about replacing that second "wait" part of the process without knowing this. 

4) your proposed solution seems like you are doing an awful lot of logic in your ui / client side, It feels wrong to me, I think you can move much more of this towards a CS or a BL module.

Dorine

Hi @Dorine Boudry, always appreciate you for taking the time to reply.

The business process with the automatic activities has been outsourced to another developer and is currently housed in a separate BL module.

1. This approach aligns with the developer's vision and has been functional for us. However, I do acknowledge your points, and I'm open to exploring alternatives. 

2. The process is initiated when the "CreateQuote" function is triggered within the "Quote_CS" module. I must admit, I'm not entirely clear on the necessity of the wait in this context. I believe it might be possible to do without it. 

3. This particular aspect is quite perplexing. If I understand correctly, each quote will have a process that runs indefinitely until the status of that quote in our application changes to "revised" (equivalent to "declined") or "signed" (equivalent to "accepted"), at which point it updates in Sage.

4. I wasn't aware that my save action contained too much logic for the client side - we did not experience any performance issues of yet. I was under the impression that referencing it from our CS module was acceptable. It might be a somewhat intricate question, but could you provide insights into a more optimal approach?

Thank you for your attention and guidance.

1) it makes sense to logically separate these 3 steps to keep actions small and with a single responsibility, that's fine.  I would see them as 3 server actions inside maybe your CS module.  And that CS exposing a single service action "InitiateQuote" that is called from your ui.  That takes care of creating it in your own database with status Generated (maybe calling a crud wrapper from your CS module) followed by these 3 other steps.  

For this, here are some options :

• just execute all in the same service action, and only go back to client after all is done.
• set your initial status to some distinctive value, and kick off a timer to pick any with that status up and do those 3 extra steps.
• use the events that were discussed on the ODC conference (don't know exactly what OS is calling them, it is a bit like light BPT, I think, a piece of logic triggered by some database action)

the bottom 2 options will free up the ui quicker

2) if you don't see a reason for waiting, then you solve it (as you already seem to have done in your client side logic) by just moving right on to creating in sage, right after creating in your own database.  If there is a reason for waiting, than it should probably be done by options 2 or 3 above, where your timer or process kicks of on the desired status change

3) Aah, ok, i think it might be this : whenever the quote gets update in your database, the sage quote has to be brought in sync. And if the quote reaches EndOfLife, the process can stop.  You should be able to confirm this by looking at the CloseOn property of the Wait, it is probably an update of quote entity in your database with the given id.  

For this, you will probably have a second service action on your CS module, called something like "SaveQuote",which takes care of both updating in your own database and in Sage.  You have similar options as for 1)

4) this is not primarily about performance (although also relevant) but about where your business logic should live.  I think it should live first and foremost inside a CS or maybe BL module, that is the module that is responsible for all the rules and what steps should or should not be taken under what conditions, what changes are or are not possible, what consequence do they have, etc., not your UI module.  As an extra, you can make your UI also reflect some of these rules, but the CS or BL should guard and own them.

Dorine