Customise Proclaim A2A workflow - how to not lose your code

steve
Posts: 470
Joined: Wed Nov 30, 2011 10:20 pm
Been thanked: 120 times

Customise Proclaim A2A workflow - how to not lose your code

Post by steve »

If you tap in to the Proclaim-supplied A2A workflow for the RTA Claims portal, there is a danger that your code will be overwritten by Eclipse when they update your A2A system to account for any portal version updates.

If your desired changes are small, then you can probably live with the fact that you have to re-write the code each time Eclipse re-issue an A2A update.

Perhaps a better way is to track changes to any of the RTA claim portal fields, and trigger your own workflows on the back of this.

Since many of the fields aren't designed to be 'interacted' with on any Screen, you can't plumb into the 'intelligence' of a field on Screen Designer.

What you can do instead is create a 'holding field' against any Portal field you wish to monitor. You can then check the portal field against this holding field to see if it has changed, then run your code on the back of that.

1) Create a copy of the portal field you wish to tap into. e.g. {RTA Low Value Liability Response.Code} - create {RTA Low Value Liability Response Last Processed}
2) In most cases, amend the linked action run when EXISTING UPDATE ENDS

Code: Select all

IF {RTA Low Value Liability Response.Code} <>  {RTA Low Value Liability Response Last Processed.Code} THEN
   #value changed since case last saved, run the maths to inform the client
   v-run = {M inform client of portal update.Text}
   #store the new value for next time.
   PUT ( {RTA Low Value Liability Response.Code}, {RTA Low Value Liability Response Last Processed.Code})
END
3) make sure that your LINKED ACTIONS in SCREEN DESIGNER are set to run this linked action!
4) You will need to consider how to handle existing data in the database. The above code will run the maths on each file until it has been saved at least once. For some actions this is desirable, others not. Ways to get around this include
- amend the linked action that runs on Existing Update Begins, to store the current value into the Last Processed Value. This works for updates that happen whilst the user is amending the case, but won't work for data that is sucked via A2A into the case.
- run an auto-routine to popuplate all cases with the current value, so that only new changes are detected and acted upon.
- amend the maths so that the first edit of any file is ignored. Subsequent edits will then trigger an update. You can do this by storing the timestamp of the last time the field was checked for chaged.

Code: Select all

IF   {RTA Low Value Liability Response Last Processed DATE.Date} <> "" THEN
   # we've run this once before - check for changes now.
   IF  {RTA Low Value Liability Response.Code} <>  {RTA Low Value Liability Response Last Processed.Code} THEN
      #changes detected - run code
      v-run = {M inform client of portal update.Text}
   END
END
#now in all circumstances record the last processed value and the date. ON Next run the check will take place
PUT (TODAY,  {RTA Low Value Liability ResponseLast Processed DATE.Date})
PUT ( {RTA Low Value Liability Response.Code},  {RTA Low Value Liability Response Last Processed.Code})
Care should be taken not to put the 'last processed' field into the live field by mistake!

Pros: no alteration of Eclipse supplied code.
Cons: actions you program will only start when you click the SAVE button. If there is any workflow that doesn't require you to click UPDATE (like an always-enabled button on a screen - a BAD idea!) then it won't run. For fields that are updated via the A2A Autoroutines, you could tag the detection code onto the EXISTING UPDATE BEGINS linked action, and have the maths set a popup message or diary task. Alternatively you can schedule an autoroutine of your own to check for changes made by the portal and set task diaries appropriately.