Communication to and from CT

= Communicating with the Control Tower: How to? = This is a quick reference guide on how to communicate with the control tower through web services. This document describes how DC’s and TC’s should implement the web services that receive data from, and in which format data should be provided when invoking web services provided by the CT.

Receiving data
The CT expects all DC’s and TC’s to implement web services that will allow them to receive data form the CT. The data will arrive in packages containing data in XML format. The schemas describing the contents of these packages will be provided by the CT (.xsd files). These schemas can also be used to map the data to the respective data models of the receiving parties.

Below you will find an example of what such a process would look like from the perspective from a Distribution Center. The example describes what happens when a new order is published.

=== Step 1: The DC receives the data === When the CT publishes an order, it calls a web service at the DC. This web service should expect a FileDocument (Mendix system.FileDocument entity) as a parameter. This FileDocument contains the order data in XML format. The DC can then map the FileDocument to their domain model. If they succeed, they can reply with true. If not, they reply with false.

The DC receives the following data in XML format:

=== Step 2: The DC maps the data to their model === This can be done using the schema provided by the CT. This should work independently of how the data model at the DC is structured.

=== Step 3: The DC replies to the CT === As a response, the CT will expect a Boolean, either true if receiving the operation was successful, or false if it was not. '''This does NOT signify whether or not the DC accepts/rejects the order.'''

Sending Data
This example explains what happens when the DC wants to accept/reject the order.

The CT requires that any data sent to them is packaged correctly. This means mapping the data to a FileDocument (XML) and sending it to a web service provided by the CT. Packaging the data can be done as follows:

Create a mapping scheme
This can be done  based on the .xsd scheme provided by the CT. The DC simply specifies from where the data can be retrieved.

=== Consume the web service from the CT === The CT will provide a web service which can receive the data. Depending on what data will be sent, the DC uses a different web service. The addresses for these services will be provided when they are available.

Create a microflow to send the data
The basic steps of such a microflow would look like this:

Data communication with CT
For everyone to be able to use the data of the other parties, we have to work with the same data coming in and out of a system.

Data communication CT and DC
Whenever an order is available the CT will send a XML package containing:

·        Ordernumber

·        Quantity

·        ProductNumber

·        Colli

The .XSD files for decoding this can be obtained on the wiki or through contacting the CT.

Whenever the DC want to send a quotation to the CT we need a XML package containg:

·        orderid (string)

·        dcid (string)

·        tcid (string)

·        arrivaltdc (dateTime)

·        cost (money)

The .XSD file for this mapping can be obtained on the wiki or through contacting the CT.

When the CT has all the bids or the time window is closed (one day before transport) the CT will select the most appropriate offer. The DC that submitted the quote that was accepted will be notified that their offer was accepted and the other DCs will be notified that their offer was rejected.

The data send to the DCs will contain:

·        OrderNumber (string)

·        Accepted (boolean)

This is not send as a XML package but as two separate variables.