Indeavor’s Integration Best Practices
There is no one size fits all approach to designing integrations between systems; however carefully designing a solution that considers the capabilities and limitations of systems and tools, and then weighs the pros and cons will ultimately give you the most practical and sustainable solution. The following should serve as a guide on how to approach integrating with Indeavor.
Terminology
Integration
Data integration is the combination of technical and business processes used to combine data from disparate sources into meaningful and valuable information.
Interfaces
Processes that facilitate the flow of data between systems or applications where the applications themselves are unaffected. They know how to send and receive data but otherwise they act independently of each other.
Application programming interface (API)
An application programming interface, or API, is a set of programming code that queries data, parses responses, and sends instructions between one software platform and another.
IPaaS (Integrated Platform as a Service)
Integration platform as a service (iPaaS) is a set of automated tools for connecting software applications that are deployed in different environments. iPaaS is often used by large business-to-business (B2B) enterprises that need to integrate on-premises applications and data with cloud applications and data.
Middleware
Middleware is an on-premise software that lies between an operating system and the applications running on it. Essentially functioning as hidden translation layer, middleware enables communication and data management for distributed applications.
Guidelines
Less is More
The less data per file the faster the transactions will run, which means less resources in use and less likelihood for interruptions. As a rule, we recommend not processing more than 500 rows per import transaction and choose your columns wisely. This will allow you to troubleshoot and understand the data but exclude unnecessary fields.
Organize Your Data
Organize your data into separate interfaces based on workflows and business processes. This helps keep file sizes smaller and makes troubleshooting easier, in addition it alleviates unnecessary dependencies (between different sites or workflow types that are not necessary).
- Example 1: Schedule data from Indeavor to a Time and Attendance system could be send per facility, this allows each facility to have its own schedule that aligns to their start time.
- Example 2: Human Resources Data (New Hires, Terminations, Personal Info Updates) HCM system to Indeavor interface files can be send per workflow type, File 1 is New Hires, File 2 is Personal Info Changes and File 3 is Terminations. This logic will simplify reading the log file and the operational support of the interface.
Let Your Business Process Drive
Interfaces are simply the automation of business processes. Let the requirements and dependencies of those business processes drive the organization, timing and frequency of transactions.
Design Steps
1. Choose your system of record
A system of record is the source system which is the authoritative data source for a given data element. It is imperative when moving data between systems this relationship/hierarchy is understood.
2. Identify business processes and workflows
Create a list of the business processes that will be in-scope for interfacing. This creates a logical tool to verify that all the appropriate fields and processes are considered.
3. Identify scheduling requirements
Time, frequency and dependencies between interfaces. For ex: the interface to send foundation data details (i.e. Job, Department etc.) must be scheduled to run first before running transactional interface. Create your schedule to avoid running during heavy usage in the application.
4. Choose a data approach
See Recommended Data Approaches below for a prioritized list of options.
5. Choose a data transfer approach
See Data Transfer Approaches for solution options.
Recommended Data Approaches
Organized Deltas
Only send what has changed in an organized manner. Break out your deltas into separate files organized in a way that will make supporting the data analysis efficient. This approach also aligns to the direction interfacing is moving, event based-transactional interfaces.
Using deltas makes the most sense if the process includes the ability for your system of record/source to know what was last successfully processed in the recipient system, this will ensure data between the two systems stay synched. This may be available through the source and recipient system, but more than likely would be facilitated by an IPaas or Middleware solution.
Indeavor Protip: create an adhoc-full file process for your operational support team to use in case of an issue.
Full File with splitting
Send all data but organize in a meaningful way that will help with data analysis and troubleshooting later. If you don’t have the option of deltas the next best option is sending all data, but splitting it up into smaller files (transactions) which logically align to your organization or process. This allows for easier support and breaks the process up into smaller transactions which will allow it to run faster.
Full File
Sending all data in one interface is our least preferred approach, especially on resource intense and high priority workflows such as Employee Updates. This approach can be implemented, but long run times are expected.
Data Transfer Approaches
Local Network/FTP
File Transfer Protocol
HTTP
Point to Point transfers
Intermediate Data Location
Memory or SFTP solutions
Logging, Archiving & Monitoring
Define an appropriate period of time to archive xml inputs and outputs to support data analysis, troubleshooting or rerunning of interfaces.
Each Interface should have a defined range of expected results that are monitored.
Template |
Type |
Description |
Common Workflows |
Parameters for Import |
Employee Updates |
Import |
Used to facilitate import into Indeavor from HCM system. |
New Hires with user credentials Terminations with removal of user credentials Employee Information (Not Contact Info) Role changes |
No more than 500 rows |
Employee Leave Balance |
Import |
Used to update employees leave balances as of a specific date |
Update balances after accrual or balances are awarded, typically after payroll |
No more than 500 rows |
Contact Infos |
Import |
Updates users’ phone and/or email |
Adds, removes or modifies phone and/or email addresses |
No more than 500 rows |
Charge Buckets |
Import |
Updates total in value field that can be used in scheduling |
Reconciles overtime leveling bucket |
No more than 500 rows |
Leave Requests |
Import |
Adds or Updates leaves managed in another system |
Adds, modifies or removes long-term leaves |
No more than 500 rows |
Schedule Export |
Export |
Sends employee, date and assignment information to another system |
Schedules sent to Time & Attendance system |
N/A |
For technical next steps please visit the API Overview.