I have been using Service actions more and more instead of Set Fields, Push Fields, etc. (where it makes sense). One cool use case we came up with recently is we have a Vendor Form to integrate xMatters for alerts (using LJ's Restful Plugin). Basically you can push a record to the Vendor Form from any form and alert somebody via xMatters. However, we leave XM alerts turned off in our dev and QA environments so people are not sent alerts from others testing (we turn on only when alerts or end-to-end processes need testing) . If all of the workflow from various forms did a push fields we would have to disable all those objects each time we did a DB restore from production.
Instead of building a bunch workflow that pushes to the form I created a Service filter on the form that does a Push Fields to itself. All all of the workflow that uses this form (the form itself is basically a service) make service calls. Now when we need to disable alerts in non-production environment we can disable this one service filter and the whole "service" is disabled. I have also seen the performance improvements when setting configuration data in the UI. Just like many other Remedy apps we have fields with menus that set multiple values in the form upon selection. So we use the trick were the menu puts a unique identifier (the value instead of the label) in the the field and then workflow uses that to fetch rest of the data from configuration record(s) and in the process also replace the unique ID with the label the person chose. Traditionally these were all Set Fields actions and while the performance we usually acceptable the user could often see the unique ID for a moment while the Set Field(s) actions were processing. With our most recent app I built these using Service actions instead of Set Fields. You can feel/see the performance improvement in the UI. I almost never notice the unique ID in the field anymore because it is so fast. One last example I just started building last week is a service to get people data. Our apps are all home grown but we have a "people" form similar to CTM:People that has a record for everybody affiliated with our company. We have many, many, many Active Links and Filter that perform Set Field actions from this form to get requester/assignee information. I decided on the new application I am building to create a service filter that returns the data I would normally create a Set Field action to fetch. Now all I need to do is send the people form a username in a Service action and map the return data I want to use to my form. Doing it this way I also have an opportunity to manipulate the data before it is returned. For example our people form is loaded automatically from an HR source. All of the data in uppercase. All upper case data is not always the most user friendly. Short of transforming all the data as it comes in to our people form (which isn't a bad idea either) I can call our initcap function before the data is returned. Because I am doing this as a service all of the workflow calling this service automatically benefit from the initcap formatting. Jason On Tue, Apr 19, 2016 at 6:17 AM LJ LongWing <[email protected]> wrote: > ** > Madhu, > A Service action doesn't interact with a record, it interacts with a > service. that service can reference a real world record, or not. I'll > give you an example. Lets say that you have many places in your system > where you need to get the square root of a number. This is fairly simple > workflow, but you need it in 10 different places in your application. You > can write the workflow to generate the square root once, write it as > service filters on a form, from that point forward, all you need to do is > call that form via service, provide the input value, and get the output > value....this isn't related to a specific record...so a setfields wouldn't > work for this purpose. Now, replace 'square root' with any 'function' in > your system, and you can see how the ability to make a Service call via > either AL or Filter to this centralized 'function' capability would allow > modularization of your code to the point of write once, use many > style.....something you simply can't do with a setfield action in the same > way :) > > On Tue, Apr 19, 2016 at 4:09 AM, Madhu V < > [email protected]> wrote: > >> Hi, >> >> I am basically confused on the purpose of using Service action instead of >> usual Set field action. >> >> Example, while I type something on Assignee field and hit 'Enter' (i.e >> return action), there are some active links written with service action to >> get the other details of Assignee. I have understood Service action >> triggers the filters who fire on Service Execution options and the behind >> logic is to get the other details through these filters. My question is >> instead of Service action, Set field action could have been used to get >> these Data. What is the purpose of using Service action here?? >> >> Can you please make me understand this ?? >> >> Regards >> Madhu V >> >> >> _______________________________________________________________________________ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "Where the Answers Are, and have been for 20 years" >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
