Master and Meta distribution
Master & Meta: White paper
Master- & Meta-
Data Distribution
Technical White Paper
Last updated: 2017-11-29
Document Revision: 1.01
Author: Frank Vandervelpen (Oryx)
Contents
Flex²B Meta data distribution........3
Document Purpose........3
Background........3
Positioning........3
Technology Representation........4
Flex²B Web enabled architectures........5
Components........7
Flex²B Open API Connectivity........8
A closer look to one of the API open methods........9
Visualised (sample)........10
Possible flows for Data Distribution........11
Flex²B Master- & Meta- Data distribution
Document Purpose
The purpose of this document is to provide an overview on the Master- & Meta- Data Distribution characteristics of a Flex²B implementation.
You can skip the general introduction and continue reading on page 7 for Production and Packing related information
Currently Flex²B has a major revision 6. The document can be seen on a central site installation or a decentral installation that synchronises to the central site, as well as 3rd party vendors and connectivity towards ERPs.
Background
Flex²B is a solution for the Fresh Produce industry, including vegetables, fruit, wood, … to provide in depth information for the Cold Chain, Logistics, Quality, Location positioning, … It is proven to be a wide accepted, strategic tool, for more than two decades of loyal customers and site.
As an extend to the local used application, Oryx has made the decision to let Flex²B break out of local implementations and be shared over intranet and internet connections.
To provide an interface to a wide public and a wide integration, Oryx provides through Flex²B a wide range on connectivity and clients to attach and hook in, into Flex²B.
To open its connectivity, Flex²B has 2 major components for the Web and Cloud environments.
It provides a full set of Web Objects and Methods to automate a wide range of clients and operating systems using miscellaneous techniques. This component can be used by 3rd party clients, such as industrial PDAs, automation lines, B2B sytems…
The Flex²B Cloud/Web edition is designed as one platform that integrates information across applications and business processes. It navigates through your quality and delivery information, revealing what’s important to know, to manage, to strategize, to decide and to act.
The latest cloud & web version (build in 2013, first operational since 2014 and maintained until now) is built on top of Microsoft IIS using dHtml, javascript and json techniques.
Positioning
Oryx includes the Web services, background utilities, Windows GUI, Cloud & Web module as well as the integration between Flex²B and ERP systems, Lab environments, Agronomist environments … – as being a part of the Flex²B suite, spreading over 3 Pillars. The ‘Pillars’ is one of the three important legs of the Flex²B suite.
Technology Representation
High level
Flex²B Web enabled architectures
Visualisation 1: Web architecture
Visualisation 2: Overall
Visualisation 3 - Protocols:
To ↗ From |
Cloud Internal |
Cloud DMZ |
Head Quarter |
Production Site |
Outlying cold stores |
Internet |
VPN users |
ERP |
Cloud Internal |
All |
https ftp |
http/https ftp smtp sql |
http/https ftp smtp sql |
http/https ftp smtp sql |
http/https ftp |
/ |
SAP HTTPpat HTTPSpat |
Cloud DMZ |
SQLpat
|
All |
/ |
/ |
/ |
smtp |
/ |
/ |
Head Quarter |
http/https ftp smtp rdp/ica |
https ftp |
All |
http/https ftp smtp |
http/https ftp smtp |
http/https |
/ |
SAP HTTPpat HTTPSpat |
Production Site |
http/https ftp smtp rdp/ica |
https ftp RDPhop |
All |
All |
All |
http/https |
/ |
SAP HTTPpat HTTPSpat |
Outlying |
http/https ftp smtp rdp/ica |
https ftp |
All |
All |
All |
http/https |
/ |
SAP HTTPpat HTTPSpat |
Internet user |
/ |
https ftp |
/ |
/ |
/ |
classic |
/ |
/ |
VPN User |
http/https ftp smtp rdp/ica |
https ftp |
http/https ftp smtp rdp/ica |
http/https ftp smtp rdp/ica |
http/https ftp smtp rdp/ica |
http/https |
All |
SAP HTTPpat HTTPSpat |
ERP |
http/https SMB FTP |
/ |
/ |
/ |
/ |
/ |
/ |
All |
Flex²B Suite:
Distributing Master- & Meta- data
As already stated before, Flex²B can run in a central or decentral configuration.
When running in a decentral configuration, data generated in the decentral site can be replicated to the central site, through the replication mechanisms. These mechanisms are out of the scope of this document.
The idea is to automate the distribution of some Master- & Meta- data to the decentral sites. It should run as autonomous as possible. The concept covers several components that closely join and or work together.
During this document, we will use the Client/Customer data as a sample. However, others will follow and the same mechanism is used.
Data changes can occur by several applications or mechanisms. Some will belong to the Flex²B Suite, while others will connect over the connectivity solutions in Flex²B. An ERP, posting updates through the soap, json or REST interface, can also be the source of the changes (updates/inserts) Deleting data will currently not be pictured, as Flex²B flags a record as deleted (inactive), but will not erase the data itself. 3rd party tools might do this directly to the database.
Components
- SQL Trigger: the event is fired for any change or addition of data to a particular table (ie Client)
- Trigger will check whether the site is indicated as a Central Site (CSSys). When not a decentral site.
- Trigger is based on Cursors to handle bulk changes as an individual entry.
- Trigger will generate an entry in the F2BDistriHead with a pointer to the changed record (abstract collected over all different tables) – unique identification by a UUID/GID
- Trigger will inspect all defined sites. For each site that is indicated as a receiving Distribution client, an entry will be generated in the F2BDistriDetail with the parameters as they are known at the time of the change to the central DB environment.
- A specific module can be started in the Flex²BDaemon. This will check in the F2BDistriDetail for new occurrences that have the status ‘C’reated.
- When a new entry is picked, the Daemon will first do a ‘ServerAlive’ call to the remote site. In case this call fails (internet connection down, decentral http-server down, Flex²B connectivity services down, other/security…) it will keep the status but it will lower the priority. This means that this call will be reattempted later, but as the last in the sequence.
- In case the Daemon receives an acknowledgement of the ‘ServerAlive’ call, it will post the entry to the remote site. This will be handled by the decentral receiving open method(s), and it will be handled. The central Daemon will interpret the response and change the Status as according.
- Open Methods for posting the Master- & Meta- updates.
- Any Flex²B Web Service mechanism for PDA or B2B postings will have a definition to receive data updates. (see later)
Flex²B Open API Connectivity
Flex²B has a rich set of Open Architecture methods available that can be installed in any site with its own Flex²B operating environment. It can action as a server for PDAs, ERPs, 3rd party systems, but also for B2B and F2B-to-F2B communications.
Sample:
http(s)://your-Flex²B-site-name/Flex²B.eu/testcontent.htm
Will give you an overview on all available open web service objects and the published web service methods.
The description of the web service object is described as ‘Open API Connector for Flex²B’.
Investigating into this WSO, you will see all the defined methods that are published.
One of the basic methods is the getServerAlive that can be queried first to see whether the remote server is responsive.
http(s)://your-Flex²B-site-name/Flex²B.eu/ConnectAPIFlex²BMetaData.wso
For your own client development, you can get the description of the methods on:
http(s)://your-Flex²B-site-name /Flex²B.eu/ConnectAPIFlex²BMetaData.wso?WSDL
When successful, you can try to post your data to the Web Service Object. This can be done on one of the web service objects.
A closer look to one of the API open methods
Analysing an individual method and the arguments.
POST /Flex²B.eu/ConnectAPIFlex²BMetaData.wso HTTP/1.1 Host: localhost Content-Type: application/json; charset=utf-8 Content-Length: length { "tConnectAuth": { "sLogin": string "sAuthSecret": string "sTenant": string } "tCommUUID": { "sCommUUID": string } "tCustomerData": { "tConnectReturn": { "bReturn": boolean "iErrorcode": int "sErrorDescription": string } "sClient_c": string "sClient_name": string … } } |
Structs:
|
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Content-Length: length { "bReturn": boolean "iErrorcode": int "sErrorDescription": string } |
Return sequence
|
Visualised (sample)
Possible flows for Data Distribution
Some sample flows. This is just to give you an impression on some flows. We will describe some mechanisms that occur.
Data change in the Central site.
Daemon actions
Open architecture APIs