So I have a few customers which due to differing outsourced/provider relationships have some form of integration between their SDM system and some 3rd party ticketing system, generally using PAM and web services. One issue that has come up several times is ending up with several transactions being triggered from what is functionally a single ticket update. This will often happen during an initial triage, where the Priority, Assignment, and status may all be updated at once. Since currently the integration is tied to each of these Activities, when the user clicks Save, it will end up triggering 3 separate Events as it logs the Escalate, Update Status, and Transfer activities.
What I am hoping to do is find a way to just do an evaluation 'on save' to check if any of the required attributes have changed (since generally, all the key fields are sent with each transaction), and if so, fire only 1 Event/Execute IT PAM macro to send the current ticket info across the integration. I haven't found a good way to do this currently using just the normal form/condition/event/activity, but perhaps I just haven't looked at it in the right way. My current thinking is I would probably need to a a mod/spl method, where for each tenant, I can have a mod file thta would fire, and call a spl function that would evaluate the appropriate conditions, and then find a way to call the macro or event from the spl file. Fomr single tenant customers this probably would be a minimal load, but I worry about how that would behave in a multitenant environment.
If anyone has run into similar issues (around tenant specific spl code, attaching events/macros direct from spl, or more broadly a solution to finding a way to trigger an event/action on save separate from the normal activity notifications, to avoid sending multiple events for a single transaction) any thoughts would be appreciated as I continue piecing an overall better implementation together
My approach is to not use the attached events for this as this can come quite heavy for the system over the time.
High level we do a POST CI trigger on related object like CR , ALG and eventually others with an associated spl that will contain minimal logic for the filtering and send out to the system responsible of the integration (we use our ESB but same logic can apply to PAM too).
Depending of your business logic but most of activities is a reflect on change to the cr object then majority of th elogic is made on cr and minimal on the alg lfor those that don't update the cr object like Lof a comment activity.
You can either extend to more waterproof by adding attributes on those object storing a handle for this transaction that you can use for more granular control/error handling etc.
My 2 cents. Hope that give you some idea.
Hi phinchey - Did jmayer 's response help answer your question? If so please mark as Correct Answer. Thanks!