Category: AE Action Plug-ins

Following on from my piece on Application Engine Action Plug-ins we are going to look at the new functionality of 8.59 around the On-Exit Application Engine Plug-in. If you are not familiar with Application Engine Action Plug-ins then it might be worth going and visiting my previous blog as that is the exact subject that I covered. This new On-Exit feature allows you to now execute a plug-in step after the Application Engine has completed and also depending on the way that it completed. There are four different exit conditions that can be used as triggers: On Success, On Skip Step, On Break, On Abort. These exit conditions trigger based on the last Peoplecode or SQL action executed before the program exited. This in essence gives us a little more control than I initially thought as I simply thought this was to be a test of the Application Engine going to success or error.

So let us think about this, if the process runs successfully then the last step should be an On Success. This is where it took me a while to realise the difference between a normal step Action Plug-In and an On-exit Plug-in. You see the Action Plug-in is on a specific step, so we are saying if step ‘LAST’ runs then we put code after that and we know the process has completed, but what if you have a branching Application Engine that has multiple possible end states, then suddenly you would have to put Action Plug-ins on every final step, but with an On-exit Plug-in we can cover all end states with the one piece of code, which could be handy.

Where the new possibilities really open up are in the other states. If the last step was an On Abort then chances are you have some sort of error and so we could try capturing or even correcting the error, although the App Engine would still end. An On Skip Step state might be useful if you have logic in your interface that says if no file is in the directory then skip step. The On-exit Plug-in could capture this and choose to run a process that sends a request to the other system to resend the file.

For the first example I am simply going to recreate what I did in my last blog on App Engine Action P.Is. I am going to use the Build Search Index Application Engine PTSF_GENFEED and use the partition count on the run control page to break process into 16 smaller processes. This will create 16 run controls which we will then clean-up with our On-Exit plug-in.

We will re-use our little Action P.I App Engine that I created last time, re-usability – another great feature of Application Engine Action Plug-ins!

The first step contains our code to be used as the On-Exit Action P.I.

We will use the Step TIDY which contains the above code to delete those annoying run controls. Next, let’s navigate to Home > PeopleTools > Application Engine > AE Action Plugins. Choose the name of the Application Engine that we want to ‘Plug-in’ some new functionality, in our case PTSF_GENFEED.

You will see that there is this new section on the page now that allows you to enter one On-Exit condition. Why only one, I wonder? Maybe in the future you could have different code for On success compared to On Abort.

Now if we go to our App Designer and open up the Application Engine PTSF_GENFEED that we have just mapped to, we should see an On-Exit mapping indicator if we go to the Program Flow tab.

We are now ready to run the process which will create those 16 run controls, but after a few minutes that has gone down as some of the processes complete and remove their run control using the Action P.I. code.

And once again we have removed all those untidy run controls, but this time using the On-Exit Action P.I rather just the Action P.I.

For the second attempt we will switch the same PTSF_GENFEED Application Engine to use the step EDG_TIDY_AE.MAIN.TIDY2 this time on an abort event only. 

The step contains a single line of peoplecode to put out a message to the log so that I know this On-Exit plugin has been triggered.

To ensure we get an error I have added an error to one of the steps in PTSF_GENFEED. Once again we run the PTSF_GENFEED, but just a single instance this time.

And here is the resulting log file showing the ‘Added an error’ that I put to purposely break the App Engine and then further down we can see the message that I created using the Action P.I On Exit functionality. Brilliant!

Maybe I am being short-sighted but I am struggling to come up with many good ideas around this functionality. I think my problem is that my brain still sees this as what I originally thought the On-exit was, which was if the Application Engine ran to success do this or if it runs to error do that. I’m sure people will come up with great ideas, but we need time to tinker with it.

I can only really see how you could daisy chain a set of application engines and even create a decision tree using the On-exit plug-in, to take one path if an Application Engine runs to success or take another path and run a different set of processes if the Application engine Fails. Imagine you run your payroll and you have logic that says if the process fails then there is no point in running payslips and payroll to GL instead run your pre-payroll checks again to try to highlight any problems. This would be all very good, but I can’t help but feel that this concept would be better moved out of the Application Engine and into Schedule JobSets.

Wouldn’t it be great if you could create your batch to run over night and have it somewhat intelligently react to the processes that you run, so you don’t get that sinking feeling when you logon in the morning and say, ‘Oh the AP interface fell over so the whole batch stopped and we need to run the rest of the batch to catch up in the morning’. Your Schedule JobSet could have paths defined after each process. On successful completion of the ‘New_Starters’ interface for example, run the ‘Onboarding’ process, on error of the ‘New_Starters’  interface, request a new interface file.

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!