Create a Supply Chain Track and Trace solution in 5 minutes

In this tutorial we create a simple Supply Chain Track and Trace solution based on Sales Orders and Deliveries.

We learn how to

• create Entity Models
• create Transformation Models
• create Internal Rules
• and Alerts.

In just 5 minutes you can see how your solution posts Sales Orders, receives delivered quantities and sends Alerts in case of a delay.

We will do the following:

• We create an Entity Model, which will store our Sales Orders.
• Create two Transformation Models:
  • One to receive updates with the delivered quantities,
  • One to check time to time whether the deliveries are in time.
• And some rules to define what to do when a transformation message arrives to a Sales Order.

This is a very simple Track and Trace model, in a later Tutorial we will extend it with several new functions, using more sophisticated SYGR technics.

Let’s start!

Log in and start Master Data Maintenance

Log in to a SYGR Reporter Server (or Bunch Server if you use a standalone system)

and select Master Data.

Master Data Maintenance

Select Entity Models.

Create new Entity Model

Select Create New

and give it a name. All other fields are optional.

Click on master data structure.

Attribute Editor

It opens the Attribute Editor. The Attribute Editor is a very powerful tool to create flexible data structures in SYGR.

It starts at the ROOT node, every other node comes under it, so click on node below.

Create a field called material and click the OK button.

You can see on the right side, that the material field is created.
Now create a requested quantity field on the same level.

The next field, the received quantity we create under the requested quantity (just to intruduce some hierarchy. Attribute hierarchies can be any depth in SYGR).

We just add two more fields: a requested delivery date and a status field, which has a default value.

We have all the fields we need.
Click on the OK button on the top.

Save the Entity Model

We returned to the main screen.
Click on save.

The Entity Model is saved and in the list of models.

Create Entity Model – Store Type link

The next step is, to link our model to a Store Type.
Store Types determine, which SYGR servers will process the transformations and which databases will store the results.
One Entity Model can be linked to exactly one Store Type.

On the list page select new.

Select your Entity Model, a suitable Store Type and save.

Post a Sales Order

Let’s try it!
We did not create an own API, so we use the default SYGR API, which accepts a fix structure JSON or XML input.
The matchkey0 and matchval0 stores our Sales Order number. It will be used later to send transformation messages to it.
This example message is composed and sent by Postman:

(To send RESTful messages to SYGR, a user has to be created in the system with the necessary authorizations.)

Check the result.
On the system main page select Reporting

Then select Entities

The Entity Reporting provides a lot of selection possibilities, now just press the run button at the bottom.

And here it is, our very first Sales Order.

This is the standard SYGR report format, later we will learn how to make customized reports.
Have a look at the details (eye icon on the left).

What happened here?
Our predefined fields in the Master Data (copy) are empty, but the same fields were created in the transactional data.

The reason is, that when one posts a new Entity, only the transactional data part is accepted from the message.
The master data is always copied from the Entity Model (but later can be modified by Transformations).
So we must modify our Model, to have the fields in the Transactional Data part (except for the status field).

Now it is good.
The Master Data (copy) contains only the status, the Transactional Data all other fields, which we sent with the message.
In this picture you can see also how the sales order number is stored as a match key-value pair.

Create Transformation Models

As next step we create two Transformation Models.
One to post delivered quantities. To keep the model simple, we transfer only the quantity, no delivery number or other information.
The second is to check the delivery status and send alert in case of a problem.
Click on Transformation Models.

Create the models the same way as the Entity Model was created.

The model "Deliver sales order" has one field, the delivered quantity.

The model "Check sales order status" has a timestamp field, against which we will check the status.

Link Transformation Models

The Transformation Models must be linked to one or several Entity Models. The Entity Models can belong to the same or to different Store Types, so a Transformation can be sent to different business processes.

We have linked both Transformation Models to our only Entity Model, the My test sales orders.

Create Rules

When a Transformation is sent to an Entity, it does not know in itself, what to do.
We must define Rules to tell it.
Click on Rules in the Master Data Maintenance and then on the Create New icon.

We arrived to the main screen of the Rule maintenance.

This screen requires some explanation.

• The Rule ID and the Description is self-explanatory.
• The Rule Type can be External or Internal.
  • The activities of an Internal Rule are defined here, in this editor (details). This we will see in a moment.
  • External Rules are SYGR Plugins, program codes, that are much more powerful than the Internal Rules.
• Entity Model and Transformation Model:
  • Every Rule is assigned to exactly one model pair.
  • It will be executed only if the here defined Transformation is sent to the here defined Entity.
• Transformation usage: a Transformation can have different usage types. Only rules with the same usage will be applied to the Transformation. Internal Rules can have only two usage:
  • Single: works on active Entities
  • Wakeup: works on paused Entities (to set them active again).
• External rule plugin Id: the SYGR Plugin name in case of an external rule.
• Sync/Async usage: a Rule can be used only in case of an Asynchronous message, or only in case of a Synchronous message or both.

So we create a Rule to receive delivered quantities. Fill the fields like this:

It is an Internal Rule, linked to our Entity and Transformation model.
It will simply add the new delivered quantity to the already delivered quantity.
To define it, click on the details at the bottom.

In the Rule Details we can define four different things:

• Variables refer to the predefined fields in the Entity or Transformation model and used in the Steps.
• External commands are SYGR Plugins, so a Rule does not have to be fully external, can execute Plugins in a Step.
• Alerts are alert messages to be sent to different people based on conditions.
• And finally the Steps define what to do one after the other, conditionally.

We need two variables:
One for the already received quantity and one for the newly delivered quantity.
So click on “new” beside the Variables and create them.
Press the save button when done.
(POFL means the transactional data part of the Entity, BALA is the data part of the Transaction)

We also need a Rule Step.
The first Step must be labeled as “START”, otherwise the whole Rule will be not executed.
Here we simply add the new delivered quantity to the already delivered, using the Variables defined earlier.

Let us try it!
We again send a message to the default SYGR API with the number of one of our sales order, reporting the delivery of 10 Unicorns.

Opening the Sales Order details in Reporting, we can see, that the received quantity is changed from 0 to 10.

If we send the same message one more time, the received quantity changes to 20.

Now we create another Rule to execute the status check.
The method is the same as before, only we need more variables and also an alert.

Click on the details.

We use some more variables:

• Check time comes from the Transformation message field (BALA: transformation attributes)
• Delivered quantity is the sum of quantities delivered (POFL: entity transactional data)
• Requested quantity is the parent field of the delivered quantity
• Requested time: this we compare with the check time
• Status: the Sales Order status field (POFX: entity master data)

We also need an Alert.
Alerts are e-mails sent to predefined Targets, which is a list of recipients.

Create a new Alert, Set the severity to Error, give some text and select an alert target.

Alert targets are defined in the SYGR Regio Server.

The Alert is now available in the Rule details screen:

Now we create two steps.

The first checks that the requested delivery time is over AND still not enough quantity was delivered.
If it’s true, then sends the alert and moves to the STATUS_ERROR step.
The second step sets the sales order status to error.

Send a check request to the same sales order, but with a check date that is later than the requested delivery date.
Remember, we delivered so far only 20 unicorns instead of the ordered 100.

As a result, we receive an e-mail.

From an internal rule only very simple mails can be sent, if you want to include detailed information, it must be created by a Plugin (like an external step in the Rule).

And, as expected, the status of the Sales Order is changed to “error”.

Conclusion

We have arrived to the end of this tutorial.
We have learned how to create Entity and Transformation Models, how to associate Rules to them and send alert.
See you in our next tutorial, where we go into more details of the SYGR Automation System.

If you have questions, please contact us:
contact@sygr.ch
contact@sles-automation.com
+41 79 470 67 84