Set up the Openflow Connector for Workday¶
Note
The connector is subject to the Connector Terms.
This topic describes the steps to set up the Openflow Connector for Workday.
Prerequisites¶
Ensure that you have reviewed Openflow Connector for Workday.
Ensure that you have set up Openflow.
Get the credentials¶
As a Workday administrator, perform the following actions:
Create a user in Workday:
Go to Workday and log in as an administrator. In the Workday search bar, type Create user.
Click Create Integration System User: Task.
Enter a username and password.
Create a security group and add the user from step 1 to it:
In the Workday search bar, type Create Security Group.
Click Create Security Group: Task.
Set the type to Integration System Security Group (Unconstrained).
Enter a Security Group Name and click OK.
In the Edit Integration System Security Group (Unconstrained) window, add the integration system user created in Step 1 in the Integration System Users field.
Add domain security policies to the security group created on step 2:
In the Workday search bar, type View Security Group.
Go to Security Group Settings » Maintain Domain Permissions for Security Group.
In the Integration Permissions section, in the Domain Security Policies permitting Get access field, select the security domains associated with the reports you want to sync.
Go to the Activate Pending Security Policy Changes page and click OK.
Create an OAuth client app:
In the Workday search bar, type Register API Client, and click Register API Client for Integrations: Task.
Enter a Client Name.
Click Non-Expiring Refresh Token.
In the Scope search bar, type System and select it.
Click OK.
Copy the Client ID and Client Secret, then click Done.
In the View Integration System Security Group page, note the functional areas under Domain Security Policies. Then, add these as Scopes/Functional Areas in the API Client:
In the search bar, type View API Client.
Choose your API client from the list.
In the top blue bar, click the three dots, then select API Client » API Clients for Integrations.
In the Scope (Functional Areas) field, search for and add the functional areas that you noted.
In the same menu as before (5c), select Manage Refresh Tokens for Integrations.
In the form, search for the ISU user and select it.
Click OK.
Click Generate new token and copy the refresh token details which will be used later.
Set up Snowflake account¶
As a Snowflake account administrator, perform the following tasks:
Create a new role or use an existing role and grant the Database privileges.
Create a new Snowflake service user with the type as SERVICE.
Grant the Snowflake service user the role you created in the previous steps.
Configure with key-pair auth for the Snowflake SERVICE user from step 2.
Snowflake strongly recommends this step. Configure a secrets manager supported by Openflow, for example, AWS, Azure, and Hashicorp, and store the public and private keys in the secret store.
Note
If for any reason, you do not wish to use a secrets manager, then you are responsible for safeguarding the public key and private key files used for key-pair authentication according to the security policies of your organization.
Once the secrets manager is configured, determine how you will authenticate to it. On AWS, it’s recommended that you the EC2 instance role associated with Openflow as this way no other secrets have to be persisted.
In Openflow, configure a Parameter Provider associated with this Secrets Manager, from the hamburger menu in the upper right. Navigate to Controller Settings » Parameter Provider and then fetch your parameter values.
At this point all credentials can be referenced with the associated parameter paths and no sensitive values need to be persisted within Openflow.
If any other Snowflake users require access to the raw ingested documents and tables ingested by the connector (for example, for custom processing in Snowflake), then grant those users the role created in step 1.
Designate a warehouse for the connector to use. Start with the smallest warehouse size, then experiment with size depending on the number of tables being replicated, and the amount of data transferred. Large table numbers typically scale better with multi-cluster warehouses, rather than larger warehouse sizes.
Configure the connector¶
Each process group is responsible for fetching a single report from the Workday API. If you need to download multiple reports on a regular schedule, a separate process group must be created for each report.
As a data engineer, perform the following tasks to configure a connector:
Create a database and schema in Snowflake for the connector to store ingested data.
Download the
connector definition file
.Import the connector definition into Openflow.
Open the Snowflake Openflow canvas.
Add a process group. To do this, drag and drop the Process Group icon from the tool palette at the top of the page onto the canvas. Once you release your pointer, a Create Process Group dialog appears.
On the Create Process Group dialog, select the connector definition file to import.
Right-click on the imported process group and select Parameters.
Populate the required parameter values as described in Flow parameters.
Flow parameters¶
The configuration is divided into three parameter contexts. The Workday Destination Parameters and Workday Source Parameters contexts are responsible for connecting with Snowflake and Workday. The Workday Ingestion Parameters contains all parameters from both configs and other parameters specific to a given report (e.g., Report URL).
Because the Workday Ingestion Parameters parameter context contains report-specific details, new parameter contexts must be created for each new report and process group. To create a new parameter context, go to the menu, select “Parameter Contexts”, and add a new context. It should inherit from both the Workday Destination Parameters and Workday Source Parameters parameter contexts.
Workday Destination Parameters parameter context
Parameter |
Description |
---|---|
Destination Database |
The destination database in which the destination table is created. It must be created by the user. |
Destination Schema |
The destination schema in which the destination table is created. It must be created by the user. |
Snowflake Account Identifier |
The Snowflake account (in the [organization-name]- [account-name] format) where data retrieved from the Workday API is stored. |
Snowflake Authentication Strategy |
Defines how the connector will
connect to Snowflake. Use the
value |
Snowflake Private Key |
The RSA private key which is used for authentication. The RSA key must be formatted according to PKCS8 standards and have standard PEM headers and footers. Note that either Snowflake Private Key File or Snowflake Private Key must be defined |
Snowflake Private Key File |
The file that contains the RSA Private Key used for authentication to Snowflake, formatted according to PKCS8 standards and having standard PEM headers and footers. The header line starts with —-BEGIN PRIVATE |
Snowflake Private Key Password |
The password associated with the Snowflake Private Key |
Snowflake Role |
The Snowflake role with appropriate privileges on the destination database and schema (USAGE and CREATE TABLE). |
Snowflake Username |
The Snowflake user with a role specified in the Snowflake Role parameter is assigned. |
Snowflake Warehouse |
The Snowflake warehouse is used to load data into tables. |
Workday Source Parameters parameter context
Parameter |
Description |
---|---|
Authorization Type |
Choose between OAUTH or BASIC_AUTH. If OAUTH is chosen, then OAuth Client ID, OAuth Client Secret, OAuth Refresh Token and OAuth Token Endpoint must be defined. If BASIC_AUTH is chosen, then Workday Username and Workday Password must be defined. |
OAuth Client ID |
The client ID of an application registered in Workday. |
OAuth Client Secret |
The client secret related to the Client ID. |
OAuth Refresh Token |
The refresh token is obtained by a user during the app registration process. It is used together with the client ID and the client secret to get an access token. |
OAuth Token Endpoint |
The token endpoint is obtained by a user during the app registration process. |
Workday Username |
The username is used to log into a Workday account. Must be set only when BASIC_AUTH is chosen. |
Workday Password |
The password is associated with the Workday username. Must be set only when BASIC_AUTH is chosen. |
Workday Ingestion Parameters parameter context
Parameter |
Description |
---|---|
Destination Table |
The destination table where report data pulled from Workday is stored. It is created by the connector if it does not exist. |
Report URL |
A RaaS API URL to a report created in Workday. |
Run Schedule |
Run schedule on which data is retrieved from Workday and saved in Snowflake (by default the Timer driven scheduling strategy is used and here the user specifies an interval, e.g, 8h). |
Run the flow¶
Right-click on the plane and select Enable all Controller Services.
Right-click on the imported process group and select Start. The connector starts the data ingestion.