Expand the Order entity

Decision Insight supports a very broad range of interfaces, methods, and configurations. Nearly every task you perform with DI could be done another way. In this section, you will create a standard route to process three different types of events that correspond to the steps of the Step entity.

The route will invoke a different mapping for each event type, as shown in the schema below.

There are other options that would work just as well. This is simply what you will be doing as part of the tutorial.

One of the most important steps in any Decision Insight project is to understand the data you will receive. In many cases the data you will access is less than, or different from, what you expected. 

1. Explore data and adapt the Order entity

Overview of the sample data

 You've been provided with sample order test data in the file Part-4-10.Orders.txt.

Let's look at this file more closely. If you open the file in a text editor, you can see that the file:

  • Contains a list of purchase orders, including the same 10 orders you've worked with in Parts 1-3.
  • Includes additional information for each order, including the current state of the order, for example Order Valid and Payment Received. 

The file contains the new following fields:

  • Process step, for example New Order, Order Valid, Payment Received...

  • Total amount of the order

  • The number of line items in the order

  • The freight carrier used for the shipment

  • Invoice number

  • Credit card number

Each of these new fields corresponds to an additional attribute that you must add to your Order entity in Decision Insight so that the application will be able to process the data you want to import. 

If you look carefully at the data sample, you can see that depending on the event (or process step) that the order is at, you receive different types of information. You have ten event types but you have no events where all attributes are filled in. Within this limited set of data, there is one field – Carrier – that does not appear at all.

Here is a table that shows all the available attributes once you receive all event types.

Attributes and Event Types

Gaps in the data are often the result of using different data sources for different events. All information may not (and usually does not) flow forward through the process.

For example, in the image above, when an order is received, it arrives as a block of data. The information known at that time is origin (customer name) and identity (customer reference) of an order. Other information (like amount and line item count) cannot be seen until the file is cracked open for validation.

This type of missing data is not a problem. You do not need to pass all the data types to a mapping for each event. Take Customer name for example. Once you have an instance of Order with that attribute set, it will persist until you unbind the event. If a process included a change of customer name during processing, you could update it to the new value. That new value would persist until changed.

From an overall view, the six changes needed to adapt your solution are:

  1. Incorporate the Step name as a relation from Order to Step. 

  2. Populate the total Amount value. 

  3. Populate the line Items count. 

  4. Populate the invoice Number field. 

  5. Populate the credit Card Number field. 

  6. Create a placeholder for the carrier field (you will use that when the data arrives).

Adapt the Order entity




Click the Configuration icon > Entities.

2 Edit the Order entity.

In the Attributes tab, add the observed attributes that are missing to import your sample data:

  • carrier String type

  • cC Number String type

  • invoice Number String type

  • line Items Integer type

  • total Amount Decimal type


Add an observed relation to Step:

  • Name: Current Step
  • Reverse name: 2Orders
  • Make sure Multiple tail is checked.

Click Done and Save until you are back at the list of entities.


On the left menu, click Diagram. Check your model diagram. See if it looks like the one in the figure below.

When working with Decision Insight one of the important skills to learn is to leave a way to undo actions. 

Now that you have added new attributes to the Order entity, your next step is a perfect example of a situation where it makes sense to make sure you can easily revert your changes: you could easily update your existing mapping and route for Order to manage the integration of the new event types and attributes. However, by updating your existing route and mapping, you always run the risk that your first resources (that contain the first ten orders in your application), may become incompatible with your route and mapping. Sooner or later you may need to delete all the data for Orders. Making incompatible changes to data integration for Order would make reloading that information difficult.

The safe course is to modify a copy of your resources. You will see how that is easily done in the next task.

2. Clean up your existing data

Up till now, you were working with a small sample of orders for test purposes. To import the Part-4-10-Orders.txt resource which corresponds to a more realistic batch or orders, first clean up your application to get rid of the test data.

The data you used to create your first orders – and to unbind all but one of them – are still stored in Decision Insight. The first nine orders are already completed – you won't see them unless you intentionally move back in time to when they were active. The other one, though is still active. The completed status from earlier tests – which you created – are out of sequence with the actual data sample from the client. There are two ways to approach the clean-up.

  1. One method is to "hide" the old events – you can tell Decision Insight to not show any of the existing transactional information. For information about which function to use to hide your data, see How to hide data. This is not the cleanest process but it is the quickest.

  2. Another method is to start with a clean slate – create a backup, reset the solution data, then restore your backup. The configuration, your integration definitions, and instances of configuration entities will all be restored, but none of the transaction data will exist. This was the reset method described during Part 1 of the tutorial. This is the more complete of the two methods and is the recommended way to have a clean start for your new data.

Whichever method you use, once the old data is gone, you can move to the next task.

Related Links