Cross References is the most underused Orchestrator component because few people understand it. But once you “get it”, there is a whole new world of functionality available to make JDE work seamlessly with other platforms. In the simplest terms, cross references give you a way to map external data values from third party systems into JDE.
For example, you might be building a Salesforce integration using an orchestrator to update address records in JDE. In this scenario, an Account ID (which would include the address for the customer) needs to be mapped onto an Address number in JDE. Since the two systems refer to the same value by different names, copying data from one system into the other requires building a cross reference. This is what lets JDE know that Salesforce is simply using a different name for the same data value. Now, you can perform a massive “find and replace” action using the Orchestrator.
How to Build Cross References
The first step is to go to the business service cross reference application. There are five fields.
- The first one is AIS and is hard coded.
- Next is the object type. This field lets you define the types of mapping you are providing so they are grouped together. These might be addresses, GL accounts, or any other type of object from the menu.
- Next is the third party app ID (such as Salesforce or another external system).
- The third party value is the value retrieved from an external system.
- The EOne value is JDE’s internal value that you match (cross reference) to the third party value.
You can keep building out as many rows as you want to capture and cross reference multiple groups to map together.
Note: Cross reference and whitelist are the only components where you build out the logic/mapping table in JDE itself instead of inside the Orchestrator Studio.
Merging Multiple Values in Cross References
Cross references also allow you to map values as one to one, one to many, many to one, and many to many. As an example, this function is helpful if a value is expressed as two separate values in a third party app but only one value in JDE (or vice versa). You can merge values together and map two third party values onto a single JDE value. Use a vertical bar | (standing pipe) as a delimiter to enter multiple values in a single field.
Note: From a conceptual standpoint, this is similar to what you might do in Excel if you wanted to put separate first and last name columns into one unified “name” column in a mailing label printing system.
Defining the Cross Reference in the Orchestrator
To put this all into action, you still need to define the cross reference for the orchestration to know what to do with it. On the cross reference screen, the orchestration needs to know the object type, the input key where the data is coming from (e.g., SF Account ID), and the output key where it is going to (e.g., ID Address Num).
When you run the orchestration, it knows to take the input key and go into the Business Service Cross Reference application and see if there is a match to the third party value. If there is, it will look up the EOne value and return it into the output key so it can flow into the next step in the orchestration.
What does this mean in practical terms? At any step of an orchestration, you can add a cross reference that pulls in data from a third party app, translates that into JDE’s “language”, and then lets you use that JDE value as a variable going forward in the rest of the orchestration.
Why Don’t More People Use Cross References?
This is a very powerful tool. One reason few people use it is that nobody wants to set up and maintain all the cross references. It seems as if you wouldn’t get much value from automating the integration if it takes so many steps to implement in the first place. If you are adding a hundred new addresses from Salesforce into JDE every day, you certainly don’t want to come in and type it all out. But this is where things can be easier than you think. For example, if you have a large initial load, you can copy and paste or import the information from an excel work file.
But the real secret is that a cross reference is just another application in JDE. This means it has an application form and version. You can create a form request for it to run by itself without any extra work on your part. Simply create a request to add a new record. Then, every time you get an “add address book record” request, you can add a form request at the end that adds a new row in the business service cross reference application because you know the 3rd party value and JDE value. Next time you need to do an update, you have all the values in place and the integration is self-maintaining going forward.
What Are White Lists?
This is simply a cross reference that doesn’t map to anything. This feature is a holdover from the early IoT days of the Orchestrator. It allows you to create a list of devices and allow only those devices to call orchestrations. If a device is not on the white list, you get an error and the orchestration is aborted. It’s basically an if/then data filter. This component is pretty much obsolete now since cross reference can do anything you would want to do with a white list.
What’s next? We’ll be learning about Data Requests using the data browser functionality in JDE.
