We have created a custom internal ticketing/work order system that’s coming along great. One concept I’m trying to make smoother is sending out an email through our Alarm Pipeline when a new ticket is created.
I have all the logic and steps working, but I’m trying to prevent a race condition if multiple people were to create one at the same time. I have created a way through system.net.sendEmail that works since it’s done in the client itself using system.util.invokeAsynchronous to prevent client lock up, but wanted to utilize our already setup Alarm Pipeline with Associated Data groups which gives us some more dynamics.
What I did was setup a memory tag with 4 alarms on it (low, medium, high, critical), with each set to trigger when equal to 1, 2, 3, 4 respectively. What I also did was create other memory tags which hold strings that the Alarms are binded to for things such as subject, message, assoc. data. (Note I could do one dataset tag with everything, but the same concept).
When a new ticket is created, a button will do all the necessary things, and then write the priority number to the memory tag (which triggers one of the 4 priority alarms on it), which then has a tag event script that simply changes it back to 0. With the Alarm Pipeline’s Dropout Conditions for acknowledge and cleared off, the alarm runs fine. I can create tickets one after another seconds apart. However, if done fast enough or at the same time, the memory tags that hold string data for the alarm’s binded subject, body, etc… from the previous tag might still be go into a ticket after it.
I created a while loop that does a check to match everything up and an invokeLater, which improved it, but I would still like to foolproof it a little more. I though of the system.tag.configure to write the alarm’s data directly, but I believe that still could cause a race condition. Any suggestions?