Recently, I was required to inactivate workflow that were delivered ACTIVE.Since we are not using workflow, we will eventually have to inactivate all the events.
While I got to manually inactivate a few that were causing errors, I identified a peopletools table that could potentially be used for the purpose.
PSEVENTDEFN stored this information.
Instead of manually opening up each workflow, you could update the ACTIVE field to 0. But be sure that you are not really using thr work flow.
If you have a better way of doing it, please share with me and I will thank you for it!
Till next time.
Tuesday, February 19, 2008
Sunday, February 3, 2008
How do you get an AE program to abort?
In certain situation, you want to stop processing and fail the program ?
There are certain places where you can accomplish this:
1. SQL Action with On Error set to Abort.
Other values are
Continue: Continue processing. It will continue processing the next action within the step.
Skip step: Skip this step and go to the next.
Section break: Stop processing the current section and pass control back to calling section.
2. Peoplecode Action with OnReturn set to abort and exit(1) fired within the peoplecode on encuntering the error condition.
3. SQL Action which returns no rows can be flagged to Abort.
Other possible value for Peoplecode On Return are Skip Step, Break.
With break, subsequent steps in section are not processed and control is returned to calling section.
With skip step, the existing step and ( subsequent actions ) are skipped and control is passed on to the subsequent step.
There are certain places where you can accomplish this:
1. SQL Action with On Error set to Abort.
Other values are
Continue: Continue processing. It will continue processing the next action within the step.
Skip step: Skip this step and go to the next.
Section break: Stop processing the current section and pass control back to calling section.
2. Peoplecode Action with OnReturn set to abort and exit(1) fired within the peoplecode on encuntering the error condition.
3. SQL Action which returns no rows can be flagged to Abort.
Other possible value for Peoplecode On Return are Skip Step, Break.
With break, subsequent steps in section are not processed and control is returned to calling section.
With skip step, the existing step and ( subsequent actions ) are skipped and control is passed on to the subsequent step.
%TruncateTable
%TruncateTable
While we know that oracle implicitly commits after the execution of a Truncate statement, one might wonder the impact of using this in an AE program and causing issues.
Per peoplebooks, AE is smart enough to recognize that and converted a %TruncateTable to a delete!
Wondering whether it will add a where clause ( where process_instance = %processinstance ) ?
Anyone who has worked on it can comment ?
While we know that oracle implicitly commits after the execution of a Truncate statement, one might wonder the impact of using this in an AE program and causing issues.
Per peoplebooks, AE is smart enough to recognize that and converted a %TruncateTable to a delete!
Wondering whether it will add a where clause ( where process_instance = %processinstance ) ?
Anyone who has worked on it can comment ?
ApplicationEngine Action
A few things about Actions.
1. There is a specific order in with Actions get executed. The order in which you create them does not matter.
1. DO when ( like a if statement.) If the sql returns 1 or more rows, subsequent actions are executed just once.
2. Do While ( Loop. Will exceute all subsequent actions once for every row returned by query.
3. Do SELECT ( Like a for loop. Will execute once for every row returned. )
4. Peoplecode
5. Call Section:
6. SQL
7. Log Message
8. Do Until: Will execute subsequent actions till no rows are returned by the query. Will executed at least one. If if no rows returned the first time, it will executed actions at least one time.
2. Only one SQL action can exist in a Step.
3. SQL Action and Call section are mutually exclusive in a step.
1. There is a specific order in with Actions get executed. The order in which you create them does not matter.
1. DO when ( like a if statement.) If the sql returns 1 or more rows, subsequent actions are executed just once.
2. Do While ( Loop. Will exceute all subsequent actions once for every row returned by query.
3. Do SELECT ( Like a for loop. Will execute once for every row returned. )
4. Peoplecode
5. Call Section:
6. SQL
7. Log Message
8. Do Until: Will execute subsequent actions till no rows are returned by the query. Will executed at least one. If if no rows returned the first time, it will executed actions at least one time.
2. Only one SQL action can exist in a Step.
3. SQL Action and Call section are mutually exclusive in a step.
AE State Record
A state record used to store values to e shared across sections/steps can be a
1. Record ( with an underlying database table)
2. derived work record
If you do decide to use a derived work record always disable restart. If not so disabled, after every commit the derived work record will be reinitialized resulting in unexpected behaviour.
An AE program can have multiple state records. In this case only one can be defined as a default state record. The fields of the default state record can be accessed w/o prefixing the record name. For non default state records, you have to prefix the record name.
To set a value of a state record's field use %SELECT ( FIELD name or RECORD.FIELDNAME)
To retrieve values, use %BIND(fieldname/ recordname.FIELDNAME )
1. Record ( with an underlying database table)
2. derived work record
If you do decide to use a derived work record always disable restart. If not so disabled, after every commit the derived work record will be reinitialized resulting in unexpected behaviour.
An AE program can have multiple state records. In this case only one can be defined as a default state record. The fields of the default state record can be accessed w/o prefixing the record name. For non default state records, you have to prefix the record name.
To set a value of a state record's field use %SELECT ( FIELD name or RECORD.FIELDNAME)
To retrieve values, use %BIND(fieldname/ recordname.FIELDNAME )
AE Tables
This is an attemp to track all the tables used in Application engine programs
1. PS_MESAGE_LOG: ( Messages logs are inserted into this table)
2. PS_MESAGE_LOGPARM: ( Messages logs are inserted into this table)
3. PS_AERUNCONTROL: This table stores the point upto which a restartable AE program has completed.
If there is a dedicated temporary table that has been locked, you can unlock it by going to PeopleTools, Application Engine, Manage Abends and clear the locks.
1. PS_MESAGE_LOG: ( Messages logs are inserted into this table)
2. PS_MESAGE_LOGPARM: ( Messages logs are inserted into this table)
3. PS_AERUNCONTROL: This table stores the point upto which a restartable AE program has completed.
If there is a dedicated temporary table that has been locked, you can unlock it by going to PeopleTools, Application Engine, Manage Abends and clear the locks.
Application Engine Commit/Controlling flow of program.
One common issue faces by developers as they create an application engine program is committing of data.
Unlike Sqr, where you can fire the commit yourself, it is also possible to define commit strategy in an App engine program and let that do the work for you. In fact, in app engine, to take benefit of restartability, that is what you should do.
CONTROLLIING COMMITS
=====================
First of by default, ( if you do not explicity change the settings and simply create your section, steps and actions ), the default behaviour is to commit at the completion of the AE program.
While this may seem to be the best alternative. Consider a very long running program which runs for 5 hours. If the program aborts everything is rolled back and you have to run again after rectifying your problem.
In this respect, it makes sense to understand how you can control commits in an AE progam.
Here are the different places where you can configure commit:
At Section: You can specify that the commit will happen after every step.
This will control the behaviour of commits after each step in that section is executed.
However, since each step can have its own unique requirement, you can overide this behaviour at a specific step.
At Step:
Various options include:
1. After Step: ( After the step completes. )
2. Later: Do not commit now. If you have flagged the Section to commit after step, use this to override and not commit after this specific step.
3. Default: use the value supplied at the section level. ( If at section not checked. Commit will occur for the AE at the end of the progam. If checked, commit will be after the step completes.
You can set the frquency option which is handy if you had do select, do while or do until action.
Exceptions
=======
When the program is restartable ( AE program is flagged as restartable ), the commits defined within a DO Select of type Select/Fetch are ignored.
For e.g. if there is an action wich calls a section with commit after step defined, the commit is ignored.
CONTROLLING FLOW ( when errors are encountered )
1. Step's On error property:
Depending on whether the above property is set to Abort, Ignore or suppress, the AE program will behave:
If Abort is selected, AE program will terminate. It will also rollback uncommitted changes.
If Ignore: Error will be logged but program will continue. No rollback issued.
If suppress: AE will not log and will continue. No rollback issued.
There is no property at the Section level that can control program flow when errror are encountered.
2. SQL Action:
You can control behaviour when No Rows are affected:
1. Set to Abort to rollback and terminate the AE progam.
2. Section Break: Break execution of the existing section.l Any subsequent steps in the section that sql action is part of are not executed. Returns control to the calling section.
3. Continue: Continue processing.
4. Skip Step: Seusequent actions in th step are skipped and control goes back to the next step.
Finally, if the application engine program is called synchronously on an event during component rocessing, all commits are ignored and the commit occurs after save psot change as part of the component commit.
Unlike Sqr, where you can fire the commit yourself, it is also possible to define commit strategy in an App engine program and let that do the work for you. In fact, in app engine, to take benefit of restartability, that is what you should do.
CONTROLLIING COMMITS
=====================
First of by default, ( if you do not explicity change the settings and simply create your section, steps and actions ), the default behaviour is to commit at the completion of the AE program.
While this may seem to be the best alternative. Consider a very long running program which runs for 5 hours. If the program aborts everything is rolled back and you have to run again after rectifying your problem.
In this respect, it makes sense to understand how you can control commits in an AE progam.
Here are the different places where you can configure commit:
At Section: You can specify that the commit will happen after every step.
This will control the behaviour of commits after each step in that section is executed.
However, since each step can have its own unique requirement, you can overide this behaviour at a specific step.
At Step:
Various options include:
1. After Step: ( After the step completes. )
2. Later: Do not commit now. If you have flagged the Section to commit after step, use this to override and not commit after this specific step.
3. Default: use the value supplied at the section level. ( If at section not checked. Commit will occur for the AE at the end of the progam. If checked, commit will be after the step completes.
You can set the frquency option which is handy if you had do select, do while or do until action.
Exceptions
=======
When the program is restartable ( AE program is flagged as restartable ), the commits defined within a DO Select of type Select/Fetch are ignored.
For e.g. if there is an action wich calls a section with commit after step defined, the commit is ignored.
CONTROLLING FLOW ( when errors are encountered )
1. Step's On error property:
Depending on whether the above property is set to Abort, Ignore or suppress, the AE program will behave:
If Abort is selected, AE program will terminate. It will also rollback uncommitted changes.
If Ignore: Error will be logged but program will continue. No rollback issued.
If suppress: AE will not log and will continue. No rollback issued.
There is no property at the Section level that can control program flow when errror are encountered.
2. SQL Action:
You can control behaviour when No Rows are affected:
1. Set to Abort to rollback and terminate the AE progam.
2. Section Break: Break execution of the existing section.l Any subsequent steps in the section that sql action is part of are not executed. Returns control to the calling section.
3. Continue: Continue processing.
4. Skip Step: Seusequent actions in th step are skipped and control goes back to the next step.
Finally, if the application engine program is called synchronously on an event during component rocessing, all commits are ignored and the commit occurs after save psot change as part of the component commit.
Saturday, February 2, 2008
Types of Handlers in Application messaging
We are used to hearing about only one type of handlers in Application Messaging where in fact there 3 types of handlers
1. Application Packages.
2. Component Interface.
3. Data Mover.
I need to explore the functionality of using the other two.
1. Application Packages.
2. Component Interface.
3. Data Mover.
I need to explore the functionality of using the other two.
Application Engine Restart and Commit
Restart feature and commit work hand in hand. Every time a restartable AE program, commits, a check point is issued and the following is saved to the database to facilitate restarts.
1. State record.
2. Local and Global variables.
However, if an AE porgram with restart enabled calls a Section in another AE program with restart disabled and a commit is fired in the that section, no check point is issued.
Restart is suspended till cntrol is transferred back to the calling AE program.
Careful out there! Else you might find that your program behaves irrationally.
1. State record.
2. Local and Global variables.
However, if an AE porgram with restart enabled calls a Section in another AE program with restart disabled and a commit is fired in the that section, no check point is issued.
Restart is suspended till cntrol is transferred back to the calling AE program.
Careful out there! Else you might find that your program behaves irrationally.
Subscribe to:
Posts (Atom)