Orchestrator has reached a new level of maturity in digital transformation and become a true application integration engine. Users are getting a handle on building simple automations to update or change records or to activate emails. Now, we are seeing client requests for more complex JDE integrations with other core business systems.
With an automation, it’s relatively easy to understand inputs and outputs because these remain static. With integrations, the types of data that are being sent or received can vary widely and there are MANY scenarios to consider.
Here are a couple of integration examples from ACBM clients.
This manufacturing client needed a robust integration because they had a different system of record for some modules. Financials, inventory, sales, and accounting were handled in JDE. BOMs, CAD models, drawings, and technical documentation resided in a Product Lifecycle Management system called Windchill.
This integration made use of REST APIs for bi-directional information transfer, allowing both systems to be in sync. The orchestrations were run on a schedule, but the client could choose to run it on-demand as needed. They also had options for one-way or two-way updates between JDE and Windchill.
We could have built the BOM integration as a set of separate orchestrations to handle additions, updates, and deletes but we ended up choosing to build a single orchestration for simplicity and security. That way, Windchill only needed one endpoint to connect with JDE. The rules components and other features provided in Orchestrator made this possible.
The result was a fairly complicated orchestration that allowed the client to accomplish multiple actions. Here’s a look at the overall orchestration.
This orchestration had ten possible inputs (such as component #, parent #, item # and what stocking type to update or dates to change). There is also an input for the mode to determine and flag the type of operation desired. For example, we could send an input with a flag to add, delete, or update, or send it with nothing.
In either case, the system would return all the current information for that particular BOM for that component. This allows them to push an update from Windchill into JDE and also pull back any new information from JDE into Windchill in a single streamlined process for true two-way synchronization. In this way, Orchestrator lets us build multi-purpose API tools with ease.
Let’s take a closer look at the ADD path to get a feel for how this orchestration works. It starts with the orchestration rule to determine the path, then it automatically takes these actions.
Before building this integration, the client had no automated way to send and receive information between JDE and their construction management system (Masterworks). They did have a number of other integrations running for other systems and were using Boomi for those connections. So, we used both Orchestrator and Boomi to create this integration. One benefit of using Boomi was the ability to perform error handling and logging at a level that’s currently not possible with Orchestrator alone.
The integration we built spanned five key areas of the business, each requiring multiple orchestrations:
Within each area, there are several orchestrations. For example, with payments, direct expenses, pay estimates, and miscellaneous expenses are all treated completely differently. In total, there were 86 different components for these 5 integrations (with many components being reused between orchestrations). There were also wrapper orchestrations that called other orchestrations.
Let’s look at one orchestration within this integration project: Adding New Vendors
This looks like a lot of steps, but you can see that the top and bottom pathways are similar. The difference is the Groovy Script at the start. We have one for a new record and one to update an existing record.
The way it’s set up, the integration must be able to be triggered for either scenario. This means users are able to work with address book information and also supplier master information. We don’t want to send address information if there is still supplier information to be sent as well.
You can see that the orchestration also has four connectors. These are the same connector used 4 times. The only difference is the rule to check the hold code. This allows us to check the hold code and hard code the default value (such as yes or no). A cross-reference or Groovy script might have worked as well, but we wanted to use as little GS as possible to keep this low-code.
Although building an integration of this scope was complicated, using Orchestrator saved a massive amount of time and effort. Without Orchestrator, a job this size would have taken 4-6 months and cost $150-200k. We completed it in just over 100 hours at a fraction of the price.
Is custom JDE integration within reach for your organization? It is, and we make it risk free. Learn how here.