Incremental syncs are a common integration pattern done in Boomi. However, identifying changes to records in Workday isn’t as simple as using a Last-Modified timestamp in your query filter. Let’s examine the Boomi setup for a query to Workday that uses the transaction log to identify records that could have changed.
Overview
Almost all objects in Workday are effectively dated. For this reason, when trying to identify changes to records in Workday, it’s important to consider when those changes became or will become effective.
Anytime a change is made to an object, it’s done through some type of Workday transaction or business process that gets logged to the transaction log. Many of the Workday Web Services (WWS) include in the optional request criteria a transaction log service that can be queried against.
Rather than repeat those nuances here, the focus of this article is to look at how to configure a WWS request in Boomi that uses the transaction log to find workers with possible changes.
Using the Staffing: Get_Workers as an example, we’ll look at using the Transaction Date ranges as well as specifying specific transaction types.
Incremental Sync Date Handling
Since we have to consider effective dates as well as entry dates when querying the transaction it’s important to know the use cases you are looking to support in your integration. Consider the date range possibilities for incremental sync after a full extract has been done. Using the Get_Workers example, the next incremental run needs to consider how to handle:
New Hires, Rehires, job changes, or terminations that have been entered and become effective since that full run
Future dated transactions that were not effective when the full file was run but have since become effective
The Workday request schema allows for multiple instances of the transaction log to help us capture these additional scenarios.
Consider this request:<wd:Transaction_Log_Criteria_Data> <wd:Transaction_Date_Range_Data>
Considerations
Some effective dates in Workday are not effective until the end of the day. For instance, terminated employees that have a termination date of today may not show up on the transaction log unless a slightly future-dated effective date is used (tomorrow for instance).
Get the best knowledge on Workday by live industry experts at Workday Online Training
Almost all objects in Workday are effectively dated. For this reason, when trying to identify changes to records in Workday, it’s important to consider when those changes became or will become effective.
Anytime a change is made to an object, it’s done through some type of Workday transaction or business process that gets logged to the transaction log. Many of the Workday Web Services (WWS) include in the optional request criteria a transaction log service that can be queried against.
Rather than repeat those nuances here, the focus of this article is to look at how to configure a WWS request in Boomi that uses the transaction log to find workers with possible changes.
Using the Staffing: Get_Workers as an example, we’ll look at using the Transaction Date ranges as well as specifying specific transaction types.
Incremental Sync Date Handling
Since we have to consider effective dates as well as entry dates when querying the transaction it’s important to know the use cases you are looking to support in your integration. Consider the date range possibilities for incremental sync after a full extract has been done. Using the Get_Workers example, the next incremental run needs to consider how to handle:
New Hires, Rehires, job changes, or terminations that have been entered and become effective since that full run
Future dated transactions that were not effective when the full file was run but have since become effective
You may or may not want to look at future dated transactions when making the current request. E.g. new hires that start tomorrow would not yet be effective but for practical provisioning purposes we may want to include them. However, you may not want the new hire that was just entered into the system that does not start for another month.
Setup the Boomi query
First, we do the normal Boomi operation build to get the request and response profiles for the Get_Workers call.
Now let’s consider a “current date” of 2019-05-01 and a “last run date” of 2019-04-30.
Setup the Boomi query
First, we do the normal Boomi operation build to get the request and response profiles for the Get_Workers call.
Now let’s consider a “current date” of 2019-05-01 and a “last run date” of 2019-04-30.
<wd:Transaction_Log_Criteria_Data>
<wd:Transaction_Date_Range_Data>
<wd:Updated_From>2019-04-30T13:00:11.290-07:00</wd:Updated_From>
<wd:Updated_Through>2019-05-01T13:00:10.290-07:00</wd:Updated_Through>
<wd:Effective_From>2019-04-30T13:00:11.290-07:00</wd:Effective_From>
<wd:Effective_Through>2019-05-01T13:00:10.290-07:00</wd:Effective_Through>
</wd:Transaction_Date_Range_Data>
</wd:Transaction_Log_Criteria_Data>
This would pick up any newly entered changes that have also become effective since the prior run. However, because these two conditions (Updated and Effective) are evaluated as an “AND” statement, it would not pick up a change that was entered before 4/30 that became effective on 5/1. It would also not pick up someone that was keyed in on 5/1 with an effective date backdated to 4/29.
This would pick up any newly entered changes that have also become effective since the prior run. However, because these two conditions (Updated and Effective) are evaluated as an “AND” statement, it would not pick up a change that was entered before 4/30 that became effective on 5/1. It would also not pick up someone that was keyed in on 5/1 with an effective date backdated to 4/29.
Get more in detailed explanation at Workday Training
Consider this request:<wd:Transaction_Log_Criteria_Data> <wd:Transaction_Date_Range_Data>
<wd:Updated_From>1970-01-01T16:00:00.000-08:00</wd:Updated_From>
<wd:Updated_Through>2019-05-01T13:00:10.290-07:00</wd:Updated_Through>
<wd:Effective_From>2017-04-30T13:00:11.290-07:00</wd:Effective_From>
<wd:Effective_Through>2019-05-01T13:00:10.290-07:00</wd:Effective_Through>
</wd:Transaction_Date_Range_Data>
</wd:Transaction_Log_Criteria_Data>
<wd:Transaction_Log_Criteria_Data>
<wd:Transaction_Date_Range_Data>
<wd:Updated_From>2017-04-30T13:00:11.290-07:00</wd:Updated_From>
<wd:Updated_Through>2019-05-01T13:00:10.290-07:00</wd:Updated_Through>
<wd:Effective_From>1970-01-01T16:00:00.000-08:00</wd:Effective_From>
<wd:Effective_Through>2019-05-01T13:00:10.290-07:00</wd:Effective_Through>
</wd:Transaction_Date_Range_Data>
</wd:Transaction_Log_Criteria_Data>
Both instances pick up the changes that have been newly entered and immediately effective since the last run. The first instance of the Transaction Log will also grab any newly effective changes up to the Effective_Through value regardless of when it was keyed in. This would pick up those changes that were keyed in prior to the full run that has since become effective.
The second instance will capture any new changes that were entered since the last run that are effective tup to the Effective_Through date. This would include the backdated transactions that are effective prior to the full run.
Specifying Transactions
In addition to using entry and effective dates to query the transaction log, we can also search for specific transactions that occurred.
For instance, you can set up a query to just look for Hire and/or Rehire transactions to just search for the joiners of an organization.
You can view these transaction types and their associated id values in the Workday tenant using the “Transaction Types available for WWS Requests” report.
These transactions can also be managed as a subscription setup in the Workday tenant, rather than specifying the transaction IDs in the WWS request. In this case, the request would include the subscription reference rather than the transaction IDs.
Both instances pick up the changes that have been newly entered and immediately effective since the last run. The first instance of the Transaction Log will also grab any newly effective changes up to the Effective_Through value regardless of when it was keyed in. This would pick up those changes that were keyed in prior to the full run that has since become effective.
The second instance will capture any new changes that were entered since the last run that are effective tup to the Effective_Through date. This would include the backdated transactions that are effective prior to the full run.
Specifying Transactions
In addition to using entry and effective dates to query the transaction log, we can also search for specific transactions that occurred.
For instance, you can set up a query to just look for Hire and/or Rehire transactions to just search for the joiners of an organization.
You can view these transaction types and their associated id values in the Workday tenant using the “Transaction Types available for WWS Requests” report.
These transactions can also be managed as a subscription setup in the Workday tenant, rather than specifying the transaction IDs in the WWS request. In this case, the request would include the subscription reference rather than the transaction IDs.
Considerations
Some effective dates in Workday are not effective until the end of the day. For instance, terminated employees that have a termination date of today may not show up on the transaction log unless a slightly future-dated effective date is used (tomorrow for instance).
0 comments:
Post a Comment