1 of 1 people found this helpful
In Helix platform, you can write a process that wait for signal. Once the signal is received it can take the action like updating existing ticket. There is REST API to send the signal for any waiting process instance. You can follow below given steps
1. Create Process, that have input process variables which will get some value from signal e.g. Ticket Status and Work Note.
2. When you create ITSM ticket using connector, you can use process co-relation id keyword to send the co-relation id of current process instance to ITSM. This co-relation id should be stored on ITSM side so that it can be used to signal the Innovation Suite process.
3. After connector action, Process uses "Receive Task" to wait for signal. It will map the process variables (Ticket Status and Work Note.) as "Signal Parameters"
4. On ITSM side when any change happens to given ticket, use Filter to send signal to Process instance. You can use Filter API plugin to create custom code action which is called by Filter and this custom code will perform REST API to Innovation Suite process. Please refer attached screens for Signal Process REST API payload. Or there may be other option on ITSM side to perform REST API that you can explore.
5. Once this call received by Innovation Suite Process, we can use exclusive gateway to take further action e.g. update ticket status and work note. If the ticket is not closed then you can loop back to same "Receive Task" to wait for further signal from ITSM, and once ticket is closed, we complete the ticket and end the process instance.
Signal Process REST call. (processCorrelationId is sent by each process instance to ITSM before it calls Receive Task and code that performs Signal Process form ITSM to innovation Suite uses this ID)
Hey thanks Ranjit.
That's indeed a good idea
I will work on the provided steps and let you know the result.
I have some confusion in point #5 though,
So each instance of "Receive Task" will wait for the signal from ITSM, until the ticket is closed. Lets say multiple tickets are created in ITSM, say 20+ tickets in a day and are open, this will trigger 20+ instances of process and wait till the ticket is closed.
Will this not affect the performance of Helix Platform over the period as these process instances are alive?
1 of 1 people found this helpful
Active process instances are persisted in DB, they are not kept in platform memory and as soon as instance is complete it is moved to history table from active table. So for small number of active instances (few hundreds to few thousands) there wont be any performance impact as such but yes if active instances number grows then it may impact on process execution time.
As an alternate approach following steps can be considered
1. instead having process instance waiting for signal from ITSM, we can send ticket ID to ITSM through connector.
2. write a process that takes input as ticket id and other variables like status and work note. This process when started will update the ticket with given details, take any other actions if needed (like notify assignee etc.) and complete.
3. For any action/update happens on ITSM side, Filter API code will performs start process instance command by providing related ticket ID and update information.
4. The process instance will not remain active, it will do the update and complete.
5. if there is no other actions needed then instead of triggering a process, Filter API can perform update record instance call directly on ticket.
I checked internally, it seems difficult to make customization in Helix ITSM.
However, to showcase the capability, can we use On-Prem ITSM to do the same?
Yes Akshay, I believe this should work from on-prem ITSM instance.