Starting in 11.0 SP12, Aras has been rolling out a number of platform services that can be used to power custom applications and features such as Variant Management, Effectivity, and most recently Data Synchronization. You can follow these links to find a sample application available on the Aras Labs GitHub to demonstrate what the apps that use these services may look like. In this blog post, we'll be offering an introductory look into the Data Synchronization services which are intended to make getting data from one Aras Innovator instance to another Aras Innovator instance as seamless as possible.
Data Sync API
Each of the platform services provide APIs for implementing custom applications on the Aras Innovator platform. For Data Sync, these APIs correspond to existing standard Aras AML actions with a few key differences. The goal of data synchronization is to have the data in your target system correspond as closely as possible to the original source data. With that in mind, these data sync actions allow for the setting of system properties like created_by_id and created_on which aren't typically able to be set outside of direct SQL manipulation. You can see each of these actions below as well as a highlight of the differences between them and their standard counterparts.
- This action does not generate a new ID for the item. Instead, you must pass in the id, generation, and config_id in order to use this action.
- This action will not initialize the item at the starting Life Cycle State. You must provide the state (if any) of the item when using this action.
- This action has its own custom server events to handle sync-specific functionality you may want to run. You will need to use the new onBefore/onAfterSyncAdd server events instead of the standard onBefore/onAfterAdd server events.
- This action will not version automatically versionable items. Any versioning logic should be handled in the source system and passed in through the generation and major_rev properties when using this action.
- This action also has its own custom server events: onBefore/onAfterSyncUpdate
This action is the one most similar to its corresponding action. In 11.0 SP15, there are not custom server events linked to this action.
Data Sync Sample App
Now that you have an idea of what's happening in the background to power this synchronization, we'll go over some common use cases and how to achieve them using the Data Sync Services.
This blog assumes some knowledge of the Data Sync Sample App. If you're unfamiliar with this application, we'd recommend checking out the guide included in the sample app which goes over both how to install it as well as the basics of setting up your system for synchronization.
If you're looking to sync data between two systems, you'll know that the data can change quite a bit over the course of a day. Having your users manually sync after each change can be both an annoyance and an unnecessary burden on your system to process these changes. Instead, it may be a better idea to simply schedule a sync to happen at the end of every work day to push all of the changes made during that day in one go. Because the synchronization is launched from a method, you can take advantage of the Aras Scheduler Service to automate the process of running this method periodically.
The blog post linked to above offers a nice overview of the scheduler service as a whole if you are unfamiliar with it, and there's also a handy walkthrough included with the sample app for setting up the scheduler service to specifically handle synchronization.
Automatically Flagging an Item to be Synced
When using the sample app, you'll need to individually add each Part you want to sync to the Sync Root in order to indicate to the source system that it should be synced to the destination system. This process can be automated by writing a simple method to create a relationship between your Sync Root and the item you want to sync. If you're familiar with using AML to add items, you can check out these tips on how to convert the AML to add this relationship to a server-side method. Once this Method is created, you can add it to whatever event fits your needs. As an example, you can add a server method to a Life Cycle Transition to flag your Parts to be synced whenever they enter the Released state.
Currently, the sample app is only recommended to be used for unidirectional syncing from a source database to a destination database. The limitation comes from syncing the same ItemType back and forth between two systems; however, it is possible to set up a unidirectional sync from the source system to the destination system for one ItemType and another unidirectional sync from the destination system to the source system for another ItemType. Using this method, it's possible to achieve similar results to a bidirectional sync with some additional processing.
A project I've worked on previously required this kind of two-way sync. Parts created in the source system needed to be approved in the destination system before they could continue being worked on. To handle this we created two new ItemTypes to exist in both systems: Destination Parts and Destination Sync Roots. The flow of this two-way sync can be seen below.
- A Part in the source system reaches a specific activity in its Workflow
- The Part is automatically added to the Sync Root using a server method as described in the previous use case
- The Part is synchronized to the destination system
- An onAfterSyncAdd server event creates a corresponding Destination Part
- Users in the destination system complete the workflow of the Destination Part to approve the changes
- The Destination Part is automatically added to the Destination Sync Root using a server method
- The Destination Part is synced back to the source system
- An onAfterSyncAdd server event completes a vote on the original Part's workflow
Share Your Experience
Do you have a story to share about how you already use Data Sync? Was there a use case for Data Sync we didn't cover in this blog? Let us know in the comments!