Concept: Workday Studio

Workday provides 2 ways to perform integrations:

Connectors: Packaged integrations that connect to a variety of common third-party services.

Enterprise Interface Builder (EIB): A simple tool for creating integrations without doing any programming.

Workday Studio is a third option that enables you to build, own, and support much more sophisticated integrations, which Workday hosts and runs on your behalf. Unlike Connectors and EIB, Studio isn't part of Workday. It's an Eclipse-based Integrated Development Environment (IDE) that you download separately. As with any other integrations in your tenant, you can launch, schedule, and audit the integrations you build with Studio. You can launch Studio-created integrations from Studio itself or from the Workday application.

The target user for Studio:

Has a development skill set.

Is familiar with integration programming concepts.

Is comfortable using an IDE.

The Studio platform has 4 principal components:

The Studio IDE.

Integrations, collections, and the Cloud Repository.

The Workday application.

Cloud Runtimes.

The Studio IDE

Studio is an Eclipse-based IDE. You use it to construct integration flows that:

Access information from Workday.

Manipulate it.

(Optional) Send it somewhere.

These flows are called assemblies. You create assemblies by adding and connecting graphical elements called components and steps in the Studio Assembly Editor.

Studio includes components and steps for many actions, including splitting, transforming, and routing. Workday-specific components have a built-in description of how Workday represents information.

You can test your integration in Studio before deploying it directly to your Workday tenant.

Studio supports the use of Java extensions in assembly projects. You can supply your own Java code and configure it as a Spring bean. In addition, you can package third-party Java libraries within your integrations.

Integrations, Collections, and the Cloud Repository

The Cloud Repository is Workday's term for its Studio integration storage. Before deployment, Studio assigns each integration to a collection. A collection can contain multiple integrations. An integration can belong to more than 1 collection. This means you can easily reuse assemblies and subassemblies across integrations and tenants.

Only 1 instance of a particular collection can run at any time. If you modify an assembly project within a collection and redeploy the project, it replaces any previously deployed version.

The binary file that Studio deploys to the Workday Cloud Repository is called a CLAR (CLoud ARchive). A CLAR contains:

All of the artifacts from the included integration projects, such as their assembly.xml, XSLT, and Text Schema files.

Any compiled Java code or third-party Java libraries that developers have added to the integration projects.

As binary objects, CLARs don't include source-code artifacts like Java source files.

The Cloud Repository stores CLARs in an encrypted format. However, don't store information like passwords directly in your integrations. Configure sensitive details in the Workday application instead so you can manage them dynamically.

The Workday Application

Workday uses an abstraction called an integration system to model integrations. In Workday, for each integration you can specify:

Which users have permission to launch the integration and the rights the integration has while executing.

How and when to notify different Workday users when the integration executes.

Because you design and configure your Studio integrations separately, you can redeploy an integration without affecting its configuration.

Workday enables integrations to launch in a number of different scenarios. You can:

Manually launch integrations.

Schedule integrations to run automatically as an event.

Launch an integration automatically as part of a business process.

Trigger launch remotely using a web service client to invoke a Workday Web Service.

You can use the Workday

Process Monitor

report to monitor the execution of an integration.

Cloud Runtimes

When an integration launches, Workday:

Generates an integration event.

Retrieves the integration from the Cloud Repository.

Assigns a protected set of processing resources called a Cloud Runtime.

Executes the integration in the Cloud Runtime.

If Workday is unable to execute an integration, it updates the

Process Monitor

with an integration launch status of

Failed

If Workday encounters a problem during execution, such as the unavailability of an external resource, it terminates and updates the

Process Monitor

with an integration launch status of

Completed with errors

It's the integration developer's responsibility to deal with integrations marked as

Completed with errors

Workday terminates integrations that take longer than 2 hours to execute. Developer-supplied Java code can't, in general, read from or write to the file system or Java system properties. Developer-supplied Java code can't spawn new Java threads.

Security and Privacy

Studio supports 2 Cloud environments automatically:

Sandbox

Production

You can add connections to other Workday environments. It's your sole responsibility to ensure that you deploy the correct integrations to the appropriate environment. Standard Workday Web Services security policies apply to all data accessed using Studio integrations.

You can create assemblies offline in Studio, but you must have the appropriate security configuration to integrate them with Workday. Once deployed, integrations launch and run with the credentials and privileges of the user who runs them.

Workday has no insight into what your integration looks like or what it's designed to do. It's your responsibility to ensure that it behaves as expected. Your integration's interactions with your Workday tenant happen over the Workday Public APIs, so you inherit all the associated robustness and security guarantees.