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.