Although Action Plug-ins came in prior to 8.59 I still want to cover them. There is some new On-Exit functionality which I intend to cover at a later date. For now we are going to get up to speed with the basics.
Application Engine Action Plug-ins allow you to modify the way an Application Engine works without having to directly customise the code in that Application Engine. So what we are trying to say here is that Application Engine Action Plug-ins are Event Mapping for Application Engines. What do you mean, what is Event Mapping… quickly go read my previous blog!
So let’s address the burning question, ‘Why is it not called Application Engine Event Mapping rather than Action Plug-in?’. The name seems strange because we are mapping the new code just like in Event Mapping, I guess with an Application Engine we don’t have events we have steps and actions, so maybe Action Mapping would have been better name? For now I’m going to make it cooler by calling it ‘Action P.I’ (As a child of the 80s, I’m thinking of a certain 80’s series with Moustaches, a Ferrari 308 GTS and one Tom Selleck). But enough silliness about names, what can we do with this?
Well the good news is that, just like Event Mapping you can configure code to execute before or after a step or even instead of a step (override)., without having to customise delivered code.
Last year I had a requirement from a client to customise a delivered Application Engine. The delivered code could only deal with a single instance of data, but they wanted it to process multiple instances od data. I had to go through every one of the 100+ steps changing the code, making a big customisation… not good! Had they been on a version with Action P.I, things would have been much cleaner at upgrade time.
For my example of the Action-Plug-in I am going to use the Build Search Index Application Engine PTSF_GENFEED. If you have large Elastic Search Indexes to build then you can use the partition count on the run control page to break your large data into a number of smaller partitions. In this case I am going to break the HC_HR_PERSON search index build into 16 partitions.
When I hit the run button here, the code will create 16 new run controls that will be used to execute 16 Application Engines, each one processing one of the data partitions.
When those processes have run to success, if I go back to the run control search page I can see all those generated run controls… what a mess. So I am going to get the PTSF_GENFEED Application Engine to tidy up after itself with an Action P.I.
We start by creating our own custom Application Engine which needs only one step. This one here has two steps as the second step is for another time! The first step will contain our code to be used as the Action P.I.
We will use the Step TIDY which contains the following code to delete those annoying run controls. We navigate to PeopleTools > Application Engine > AE Action Plugin.
Here we map the custom code action TIDY to execute after the ES_STAT step01 runs in PTSF_GENFEED. And that is it done. Easy Create a custom App Engine Step and map it to the delivered App Engine. That’s even easier than 1, 2, 3, it’s just two steps!
Running the process creates 16 run controls, but after a few minutes that has gone down to 13 as some of the processes complete and remove their run control using the Action P.I. code.
A few more minutes and we are down to 7 run controls.
Finally all the run controls have gone. Look at that, an Application Engine that tidies up after itself. Now if only I could get my kids to do that!
P.S. Those that follow me on Linked In might have seen my post about the hero developer in Oracle that after 21 years has finally fixed the process definition search page so by default it is search by Process Name. I can remember this bugging me back in 2001 when I first started at PeopleSoft. It just goes to show that just because you have done something one way for a long time does not mean it is right! Well done to that champion who righted the wrong!