Writing Workflow PeopleCode

To trigger a business event from a page, you add a PeopleCode program to the workflow event in the record definition for one of the tables to which the page writes. For example, to trigger events from the Course Request page, add Workflow PeopleCode to the TRAINING record definition; TRAINING is the record definition with which the Course Request page fields are associated.

If you’re triggering business events from a page that includes scrolls, add the Workflow PeopleCode to the record definition at the appropriate scroll level. If, for example, you add it to the record definition that is associated with a level one scroll area, the PeopleCode runs once for each row at that level. A Workflow PeopleCode program can reference record fields from record definitions at the same scroll level or at a lower scroll level. These rules also apply to the SaveEdit PeopleCode for Virtual Approver.

Workflow PeopleCode runs after the user saves the page group and before it updates the database with the saved data. More specifically, it runs after SavePreChange PeopleCode and before SavePostChange PeopleCode. Because SavePostChange PeopleCode runs after Workflow PeopleCode, it does not run if the Workflow PeopleCode fails to finish.

Workflow PeopleCode programs typically review the data in the saved record, then decide which business event to trigger, if any. They all include at least one use of the PeopleCode function that triggers events, or Virtual_Router, a PeopleCode library function that is associated with Virtual Approver, which uses TriggerBusinessEvent internally. The Virtual_Router PeopleCode library function is located in the FieldFormula event of the APPR_VA0_WRK.FUNCLIB_02 record field.

You can add the Workflow PeopleCode to any field in the record definition. For clarity, you can add it to a field that the program itself references. For example, you might add the Workflow PeopleCode that triggers an approval process to the Approval Status field.

You use this function in every Workflow PeopleCode program.

In components that use Virtual Approver, you do not use these functions explicitly in the Workflow PeopleCode. Instead, you use the Virtual_Router PeopleCode library function, which uses these two functions internally.

TriggerBusinessEvent triggers a specified business event and the workflow routings that are associated with that event. The syntax is:

TriggerBusinessEvent(BUSPROCESS.BusProcName, BUSACTIVITY.ActivityName, BUSEVENT.BusEventName)

The BusProcName, ActivityName, and BusEventName parameters are the names of the business process, activity, and event from PeopleSoft Application Designer. They are all strings, enclosed in quotes. For example, the following code triggers the Deny Purchase Request event in the Manager Approval activity of the Purchase Requisition business process:

TriggerBusinessEvent(BUSPROCESS."Purchase Requisition", BUSACTIVITY."Manager Approval", BUSEVENT."Deny Purchase Request")

See TriggerBusinessEvent.

Do not use this section for components with Virtual Approver.

The general structure of all Workflow PeopleCode programs is the same:

• Check for the condition under which a business event should be triggered.

  This condition is a business rule.

• If the condition is true, trigger the event.

  The system automatically determines whether the event is active and, if so, triggers it. If you have deactivated the event, the system does not run it.

A typical Workflow PeopleCode program looks like this:

/* Start the Employee Training process for a new course request */
if RecordNew(ATTENDANCE) then
     if COURSE_TBL.INTERNAL_EXTERNAL = "I" then
          /* For internal courses */
         &TEMP = TriggerBusinessEvent(BUSPROCESS."Employee Training",BUSACTIVITY."Request Course",
         BUSACTIVITY."Request Course",BUSEVENT."Internal Course Request");
     else
         /* For external courses */
         &TEMP = TriggerBusinessEvent(BUSPROCESS."Employee Training",BUSACTIVITY."Request Course",
         BUSEVENT."External Course Request");
     end-if;

There may be instances when you want to share business processes and activities across applications or portals. This sharing can lead to instance ID overlap in applications, making it difficult to identify different transactions with the same business process name.

Using the CloneBusProc library function, you can clone the business process by providing a new name. This function clones all associated activities, steps, and events for the business process with the new prefix.

Declare Function CloneBusProc Peoplecode WF_FUNCLIB_WRK.BUSPROCNAME FieldFormula;

Local string &oldname;
Local string &newname;
Local string &prefixname;
&oldname = "EOAW_APPROVALS";
&newname = "EPRO_APPROVALS";
&prefixname = "NEW_";
&bReturn =  CloneBusProc(&oldname, &newname, &prefixname);