Workday - Workload Automation - How to Automate Workday Jobs

In this guest post, Venkatesh Manian discusses the challenges and problems faced in handling Workday integration jobs with the use of Workload automation tools and explores possible solutions.

As technology continuously evolves, it provides greater and newer capabilities in solving the existing problems or reduces the mundane and manual jobs. Cloud computing was one such IT wave and ERP products were not far behind to ride the cloud wave. Workday – cloud ERP is a pathbreaker in many ways in the ERP market and leads in terms of technology innovations rather than just keeping pace with the technological advancements. Workday being a cloud product, integration with various in-house internal and external systems is inevitable and Workday provides simpler and intuitive integration capabilities through Workday Integrations. Workday Integrations make it easier to connect with other systems like ADP, Fidelity, BSS, etc. 

Workday - Workload Automation 

However, with the larger population of the vendor applications trying to stay integrated with Workday and employee's it still difficult to manage the integrations. With Workday’s customer base increasing continuously the workload automation system within Workday will gain prominence as the customers move on to the next stage post implementation of Workday. This post is an introductory and research article in its baby steps, on the various options around workload automation. First up, here are some basics for beginners on workload automation and Workday integration ecosystems:

Workday Web Services

 Workday implements WWS  (Workday Web Services) with industrial standards to provide a public API for our On-demand Business Management Services and keep on enhance using version control.

WWS is a service that uses an XML messaging system to provide the various operations of Workday. In all the operational domains, Workday provides a number of web services to do the GET and PUT operations.

Workday also provides web service in Integration Domain as well.  As on the publication of this post, Workday provides  Web Service: Integrations (v32.0) and it provides 25 operations related to all integrations within the Workday system primarily based upon Get and Put services.

Workload Automation Tools

Workload automation tools are used to manage and automate background processes. A typical Workload automation tool will process various background processes across multiple business systems as needed. This reduces the turnaround time for workflow across multiple platforms and products and subsequently reduces delays from end-to-end business processes. These automation tools also provide a centralized view of all the jobs across platforms and the best thing is they can be dependent on the other platform jobs as well.

In traditional on-premise products, workload automation software such as AutoSys, Control-M, JAMS, vCloud, Automate, and several other similar products are used to schedule, initiate, run and manage the batch jobs. Apart from the automation of job processing, these tools provide us great capabilities of monitoring and alerting features that help in ensuring timeliness between various data exchange partners.

Altogether we have below advantages of using a workload automation tool

• Workload automation tools have event-driven scheduling providing options to ensure successful completion of jobs within time and in the desired manner.
• Facilitates synchronizing between cross domain jobs. 
• Custom notifications via e-mail, SMS, calls, on job events.
• Simplified file transfers for Inbound and Outbound jobs.
• Enables well-structured and unstructured calendar driven job scheduling 
• Logging of data and output responses for auditing

In a tool like Control-M, it is possible to have a file watcher job, which will trigger a PeopleSoft(or similar ERP) job which needs to process the inbound file and after this job completion, we can have a downstream job which can run in a third-party system outside the ERP.   In Workday too, integrations can pull the file directly from the FTP server and start processing. However, Workday integrations do not support file watcher or daemon processes that continue to wait for a particular input condition and trigger the required dependent jobs. Due to this, an inbound file delay by even a single second can cause the integration to fail. This situation can be handled better using workload automation tools by having integration jobs followed by a file watcher.

Workday Job scheduling ideology

Workday being a cloud product, jobs will be executed in the cloud. We need to use web services to synchronize job events. We can divide this synchronization into two steps as given below:

• Job triggering or initialization
• Execution and status retrieval

Below are the Workday web service operations from integration WWS that can help us in the above phases.

WebService Operations	Description
Launch_EIB	This operation will Launch an EIB Integration. The request has the ability to accept override Runtime Parameters that should be used within the integration processing. If no override is provided within the request, the System Default, which has been defined on the EIB Definition, will be used. The result of this operation will be the creation of an Integration Event along with the processing of the integration itself.
Launch_Integration	This operation will Launch an Integration. The request has the ability to accept Runtime Parameters and the Workday Account that should be used within the integration processing. The result of this operation will be the creation of an Integration Event along with the processing of the integration itself.
Get_Integration_Events	This operation will retrieve data related to the execution of an Integration Event. Data included will be Integration System, Launch datetime, Triggering User, Status and Runtime Parameters.

Job triggering or initialization

We can trigger integrations using Launch_EIB/Launch_Integration operations by passing an integration system ID and required parameters.

Let’s see below a simple request using Launch EIB with default parameter

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
   xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <env:Body>
    <wd:Launch_EIB_Request xmlns:wd="urn:com.workday/bsvc" wd:version="v31.2">
       <wd:Integration_System_Reference>
          <wd:ID wd:type="Integration_System_ID">{Integration System ID}</wd:ID>
       </wd:Integration_System_Reference>
     </wd:Launch_EIB_Request>
    </env:Body>
</env:Envelope>

replace the {Integration System ID}  with the required Integration System Id. 

Execution and status retrieval

For the above operation, Workday in response returns the Background_Process_Instance_ID along with other relevant information after triggering the integration. Using this Background_Process_Instance_ID as an input to the web service operation Get_Integration_Events, we can get information on the triggered jobs. The response returned by Get_Integration_Events operation includes the below information using which we can use to build the logic for workload automation jobs to set the status and write to the logs.

Below is a sample request for Get Integration Events.

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope
  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <env:Body>
    <wd:Get_Integration_Events_Request
      xmlns:wd="urn:com.workday/bsvc"
      wd:version="v31.2">
      <wd:Request_References>
        <wd:Integration_Event_Reference>
        <wd:ID wd:type="Background_Process_Instance_ID">{Backgrnd ID}</wd:ID>
        </wd:Integration_Event_Reference>
      </wd:Request_References>
      <wd:Response_Filter>
         <wd:Page>1</wd:Page>
         <wd:Count>100</wd:Count>
      </wd:Response_Filter>
    </wd:Get_Integration_Events_Request>
   </env:Body>
</env:Envelope>

In the above code snippet, replace  {Backgrnd ID} with the appropriate Background_Process_Instance_ID.

Note: Optionally, we can use Get_Event_Documents operation if the output documents are required for detailed logging purposes.

Scheduling the Jobs in workload automation tool

Yes, another big part would be scheduling the jobs in workload automation tools. Most of the traditional automation tools are well designed to handle synchronous jobs. However, Workday jobs would be processed asynchronously independent of the previous job’s status. For example, using a workload automation tool if two jobs are to be processed in sequence i.e. if we need to ensure the second job gets triggered only after the successful completion of the first job, it is not straight forward to do it in the Workday server. This is because the workload automation tools lack the penetration to handle such scenarios for Workday and SOAP-based jobs.

Let’s examine Control-M for the experimental purpose. Control-M has various job types set up for Informatica, SAP, PeopleSoft, Amazon Server, OS jobs and so on. 

It also has a Web service job type as shown in the image.  

We can schedule two web service jobs one to trigger the actual integration and the other to just monitor it.  

However, both these jobs will be moving to success status irrespective of the job status as soon as they receive the responses. To handle this, we can have a script based job where the script is programmed to trigger the integration job, read the job initiation request and read the job status upon completion. The script should able to read the response and mark the job status in the workload automation tool accordingly as success or failure.





In addition to scripting, Control-M provides additional functionality, where we can have a custom job template defined as per our requirements. Then given is the design of the Control-M custom job functionality.

  Currently, I am exploring the designing aspects of custom jobs and will share the details once available.  For further information or suggestions, please comment or drop a mail to me.

Limitations 

As per Workday, we have below limitations:

It is not possible to launch an integration via web service and provide a determine at runtime value. For example, you can't select Last Successful Integration Event as a value for Last Successful Runtime Date. The web services expect explicit values.

It is not possible to provide values for cascading prompts. For example, if you're trying to launch an EIB that calls a custom report where the prompt values are dependent on each other for content you will get an error returned. A more specific example is if there is a Pay Group prompt that precedes a Pay Group Period prompt.

However, I am exploring the possibilities and workarounds for this.

Disclaimer

This post is based on the author’s exposure and ideas and there may be limitations in its implementations. As stated in the post, the pros and cons of Workday job scheduling is being explored by the author and the findings will be eventually updated.

This is a guest article by Venkatesh Manian.