Get the WID of the business process event, and its target, that launched an orchestration

Pass the event's Workday ID as a trigger parameter

A business-process-triggered orchestration only receives the values the business process passes to it. To get the event's WID, declare a parameter for it on the orchestration and map the event's Workday ID to that parameter on the business process step.

The pattern from Workday's Request Credit Card sample app:

1. In Orchestration Builder, on the Business Process Trigger step, click Configure Request and add a parameter of type String, for example actionEvent.
2. Deploy the app. In the tenant, on the business process definition, open the Service step that specifies Orchestration Service, then Configure Orchestration Service.
3. In the orchestration data grid, add a row with Key actionEvent. For its value, choose Value from Field and search for Workday ID.

The sample's instructions say the search returns a single Workday ID result, whose business object is Default Business Object, and that it returns the WID of the action event associated with the business process. The key has to match the trigger parameter's name. Workday requires the step's data to match the parameters you configured on the trigger.

Inside the orchestration, read the value in either form:

data("start", "actionEvent")
data.start.actionEvent

Log it with a Log step as the first step, as the sample does. The first run then shows you exactly what arrived, before anything depends on it.

For an orchestration launched by a Cancel, Rescind, Correct or Deny status change, the same trigger parameters appear in the Configurable Parameters section of Create Orchestration Launch Configuration. Set the values to pass there. If they look wrong after a launch, use Relaunch Orchestration to adjust the launch parameters and run it again.

Read the event's context without passing anything

Orchestrate also has business process global functions, qualifier bp, that read the launch request:

The InstanceReference results are references, not strings. To put one in a URL or a WQL WHERE clause, use the InstanceReference member functions: getIDValues() returns the reference's ID values as a StringList, and toString(idType) returns one ID type as a String. Log the result of bp.eventTarget().getIDValues() on a test event before you build on it, so you can see which ID types the reference actually carries for your business process.

Use the passed parameter when you need the event's own WID. Workday describes bp.actionEvent() as the business process action, and its documentation doesn't show that value as an event WID. A value you mapped explicitly on the step is unambiguous, and it's visible in the step configuration for the next person who reads it.

Turn the event WID into the target

Any business process, through the Events API. With the event WID, call the Business Process REST service with Send Workday API Request:

GET /businessProcess/v1/events/{eventWid}

The response carries the event's status, initiator, effectiveDate, overallBusinessProcess and for. The for field is what the business process is about, and for.id is the target's WID. For a sub-process, the API reference notes that for can be another business process, so check its descriptor on a sub-process event. Read it with:

data("GetEvent", "response").asJSON().stringAtJsonPath("$.for.id")

Extend pages use the same field. In the Request Credit Card sample, the event details page loads events/{eventId} and then reads the request with event['for'].id.

An Extend business process, through WQL. The sample orchestration queries the business process's events data source, whose name is built from the app reference ID and the business process name (requestCreditCardEvents here), for businessProcessTarget:

s"${"SELECT businessProcessTarget FROM "}${context.appReferenceId()}${"_requestCreditCardEvents WHERE workdayID = '"}${data("start", "actionEvent")}${"'"}"

It sends that as the query parameter of a GET to /wql/v1/data, then reads $.data[0].businessProcessTarget.id. With that ID it calls the business object's own API, /apps/{appReferenceId}/v1/{collection}/{id}, to read and later PATCH the request. Using context.appReferenceId() keeps the query correct in every tenant the app is deployed to.

The Events API needs the processing user to have the Core Navigation and Public Business Processes domains that secure it. The WQL route needs access to WQL and to the Extend data source. In the sample, the ISU's group is given View on WQL for Workday Extend for this call. If either call returns an empty result rather than an error, check security before you suspect the ID: Workday filters some Business Process results by the processing person's View access to the event (GET /eventSteps documents this), so missing access can look like missing data.

Use the right ID for each next call

Keep the IDs apart, because Workday's APIs take different ones:

• Event WID: GET /events/{id}, /events/{id}/inProgressSteps and /completedSteps, and the Extend Events data source's workdayID.
• Event step ID: approve, deny, send back and submit, POST /eventSteps/{id}/.... Get it from inProgressSteps. See approving, denying or sending back a step from Orchestrate.
• Target WID: the business object's own API, for example the Extend collection, and anything you write back to the record.

If you are passing results back to a later step's page, write them against the target WID, because that's what the page can reach from the event. See returning per-row results from a business process orchestration.

Prove you have the right IDs

Run one test event and check two things. The GET /events/{eventWid} call made with the logged WID should return the event you just submitted: its descriptor, initiator and creation date should match what you see in Find Events. Then the record your orchestration read with for.id should be the record shown on that event. If both hold, every later call is working on the right event and the right record.