Integrations are connections between different information systems that enable the sharing of data to complete steps in a process. We are integrating Workday Student with many of our student information systems to support our core academic and student processes.
Determining integrations scope
Student Sunrise held more than 60 discovery meetings with WashU system stakeholders and found approximately 80+ systems that need to exchange data with Workday Student. Each of these systems require at least one integration for a total of approximately 240 integrations. During these meetings, we also determined which systems will not need to connect with Workday Student.
Exploring integrations
The integrations process is a collaborative effort that requires system development at both ends. Workday Student is at one end. On the other, there’s a “downstream” system such as: a school- or unit-managed system, a system that’s supported by the WashU IT Enterprise Applications department, or an application programming interface (API). An API is a method of integration that enables two systems to communicate with each other. An example of an API that many WashU systems currently use is /person/students.
Some downstream systems will need refactoring, or updating, to send to or receive data from Workday Student. The updates include but are not limited to: changing a system’s business logic; changing a system’s technical design; or adding, removing or merging database fields or tables.
What are the types of integrations and how do they work?
An integration that takes data from a system and loads it into Workday Student
- Example: SLATE UG Student Applications Inbound – loads student applicant information from Slate Undergraduate into Workday Student to create the student record and begin the student matriculation process
An integration that takes data from Workday Student and loads it into a system
- Example: Canvas Course Sections Outbound – loads course section data from Workday Student into Canvas to link faculty and students to the Canvas learning activities for a specific section
The syncing of two datasets in two different systems so that they behave as one while also respecting the need for both datasets to be independent
- Example: BookNow Student Charges Punchout Bi-directional – inserts a link into Workday Student that when clicked takes students to the bookstore system to view and acquire course materials for their enrolled courses
Extracting data from Workday Student and then reloading it back to Workday Student
- Example: Instructor Eligibility Addition Boomerang – updates course instructor records in Workday Student to identify instructors who are eligible to teach based on HR data stored in a different location of Workday
Creating Integrations
We are scheduling the development of each integration so that it’s ready to supply or receive data for processes as we activate them in Workday Student during our rolling go-live. Developing an integration consists of two important phases: design and build & unit testing.
1. Design
Creating a successful integration begins with design. During the design process, we meet with our campus partners to learn about their academic processes and data needs. The product of the design discussions is an integration design document. This document serves as a blueprint for building an integration that can be updated as needed. For example, Student Sunrise may need to revise it to make the integration work with the software updates that Workday releases every six months.
2. Build & Unit Testing
Using the integration design document, a developer from our team writes the software code for the Workday Student side of the integration. The campus partner builds their side of the integration and may need to refactor, or reprogram, their system to exchange the new types of data in Workday Student.
Each team runs test data through their side of the integration in a process known as unit testing. If the integration doesn’t work on one or both sides, the developer(s) will fix the code until the data transfers with no errors. When both sides of the integration work as they should, the integration is ready for end-to-end testing.
End-to-End Testing
After unit testing is successful, the integration is ready for end-to-end testing. During this process, test data travels through Workday Student and any integrated systems to complete an academic or student process. If the integration passes end-to-end testing, it’s ready for when it will go live in Workday Student. If it doesn’t pass, the developer(s) re-code and unit test the integration(s), and the team performs another end-to-end test. This process repeats until the integration works as intended.
Questions?
Contact your school or unit’s IT Leader Advisory Group member, or you can submit questions or comments through this form.