Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
UN/CEFACT Smart Container Project
UN/CEFACT Smart Container Project
Next steps: From Data elements to APIs
Hanane BECHA, Project Leader
Michael Schroeder, Editor
Todd Frazier, Editor
02/04/2019
Outline
I. Standards, SOA Concepts and APIs
II. UN/CEFACT Approach
III. From Data Elements to APIs (Application Programming Interfaces)
Step 1. White Paper - completed
Step 2. BRS Development – in process
Step 3. Messaging Development – in process
Step 4. API Development – planned
IV. Summary
I. Standards, SOA Concepts and APIs
APIs for SOA
• Service Oriented Architecture (SOA) is an architectural methodology built upon the concept that capabilities should be implemented as services. The ‘Client’ can utilize any software component following the usage specification, irrespective of the technologies upon which the service was developed or upon which the 'calling client' was developed.
• Application Programming Interface (API) is a source code-based specification to be used as an interface by software components (services) to communicate with each other. Independent SOA services communicate using a common API.
• APIs can be created in any chosen syntax (Web Services) based on standardized syntax-neutral data exchange structures (Master data exchange structure)
• API is a layer for providing data access. API's should be architected with SOA support in mind (e.g., JSON, REST, SOAP).
Increasing interest in API Standardization
• ISCO. A new UN/CEFACT group developing API standards.
• Openshipping.org aims to define APIs. In particular, a specific API covering the Container Status Moves for shipping lines and BCO usage only
• Digital Container Shipping Association (DCSA): A new association to encourage collaboration on digitalisation, standardisation and interoperability in the container shipping industry.
• INTTRA, a US-based software firm spearheading a non-commercial initiative CONNECT to develop standards and data sharing protocols to help improve the free flow of information between carriers, ports, freight forwarders and BCOs.
Reduction on a single format reduces the amount of necessary mappers
Without a common format, each actor With a common format, the actor only needs to communicate using a format needs to maintain one commonwith each individual; i.e. many formats standard of communication.are necessary to communicate to all.
A
B
CD
E
A
B
CD
E Standard
Format
II. UN/CEFACT Approach
Global Trade – Semantic Anchors
A Global Standard must be based on a common repository of terms. The UN/CEFACT Core Component Library is this repository. (see examples below)
• Shipment (Trade Delivery)
• A shipment is an identifiable collection of one or more Trade Items (available to be) transported together from the Seller (Original Consignor/Shipper) to the Buyer (Final/Ultimate Consignee):
A Shipment can only be destined for one Buyer
A Shipment can be made up of some or all Trade Items from one or more Sales Orders
A Shipment can have only one Customs UCR
A shipment may form part or all of a Consignment or may be transported in different Consignments.
• Consignment
• A consignment is a separately identifiable collection of Consignment Items (available to be) transported from one Consignor to one Consignee via one or more modes of transport as specified in one single transport service contractual document:
A Consignment can only have one Transport Service Buyer
A Consignment can only have one Transport Service Provider
A Consignment can only have one Consignor
A Consignment can only have one Consignee
The Transport Service Buyer can be either the Consignor or the Consignee
A Consignment is made up of one or more Consignment Items
A Consignment can be made up of some or all Trade Items (aggregated into Consignment Items) from one or more Shipments
UN Layout Key Families
Building semantic models using a common library
Supply Chain(BUY PAY Context)
Reference Data Model
e.g. Invoice
e.g. Order
e.g. Quotation
BUY PAY Master (Master message structure)
BUY SHIP PAY Reference Data
Model
UN/CEFACT Core Component Library (CCL)
Based onBased onBased on
Based on
Multimodal Transport(SHIP Context)
Reference Data Model
e.g.Bill of Lading
e.g. Booking
e.g. BayPlan
SHIP Master
(Master message structure)
Based on
Based on
Based on Based on
Based on and subset of
BUY SHIP PAY MASTER(Master message structure)
Based on
Based on
Based onBased on
UN/CEFACT BUY-SHIP-PAY reference data models• Cover the data requirements of the international supply chain (BUY-SHIP-PAY)
process model
• Share a common library (subset of the UN/CEFACT Core Component Library –CCL)
• Include “Master” exchange syntax neutral message structures for developing process aligned subset structures
• Subset message structures can be realized into any required exchange syntax (e.g. JASON, any XML or EDIFACT etc.)
• Support collaborative information sharing
- such as enabled by data exchange pipelines
UN/CEFACT – International Code Lists
13
Rec 16
UN/LOCODE
Rec 5 (ICC)
INCOTERMS
Rec 9 (ISO)Currency Codes
Rec 20 Units of
Measurement
Rec 28Transport Means
Type Codes
Commodity
Codes (WCO HS)Rec 21
Package Type Codes
Multiple
UN/EDIFACT Code Lists (UNCL)
Rec 7
Date Formats
Rec 8
UNIC
Rec 24 Logistics Status
Codes
Rec 19Transport Mode
Codes
Rec 3 (ISO)Country Codes
III. Step by Step: From Data Elements to APIs
Share a common understanding of the Smart Container Business use cases & stakeholders: SCOPE
Smart Container White Paper1
Define structured data elements generated by smart container
and their qualifiers TERMINOLOGY /SEMANTIC
Business Requirements Specifications (BRS) & Entities Relationship
Diagrams
2
Select the data elements for a given use case
Generic message structure (Technology
Neutral!)3
APIsChoose the SYNTAX (language) to
be used to communicate4
Steps Deliverables Resources
Project Working Group from different backgrounds
UN/CEFACT CODES Lists & Multi Modal Transport
Reference Model (MMT)
Contextualized Notification Messages Structures
Multi Syntax World
UN CEFACT T&L Domain Smart Container ProjectStep by Step: from Data Elements to APIs Current efforts 2
Project Time Line 10/17 1/18 4/18 6/18 10/18 1/19 2/19 4/19 6/19 10/19 4/20
PAST
• UN/CEFACT Forum – 10/17, Rome, IT - Project proposal and head of delegations approval
• Interim – T & L Domain, – 1/18, Start of the Smart Container Project
• UN/CEFACT Forum – 4/18, Geneva, CH
• Interim – 6/18, Work Session, hosted by CIF/David Roff, Liverpool, UK
• UN/CEFACT Forum – 10/18, Hangzhou, CN
• Interim – 1/19 Semantics and Message Structures, Smart container data model review , Paris, FR
• White Paper published, UNECE – 1/19
• Interim – 2/19, Smart Container data model and BRS document, Marseilles, FR
• UN/CEFACT Forum – 4/19, Geneva, CH
PLANNED:
• Interim – 6/19, Messaging and API Work Session, TBD
• UN/CEFACT Forum – 10/19, TBD
• API Development – date TBD
• BRS document, publication target – 4/20
• UN/CEFACT Forum – 10/19, TBD
NOTE: Between face-to-face meetings we have been conducting weekly conference calls to continue progress
Step 1: White Paper on real time Smart Container data for supply chain excellence
White Paper Excerpt
Contributors - Smart Container White Paper1. Hanane BECHA, Smart Container Project Leader (TRAXENS, Marseille)
2. Michael Schroeder, Smart Container Project Editor (Hapag-Lloyd AG - Project Manager / IT Consulting, Hamburg)
3. Todd Frazier, Smart Container Project Editor (FedEx/IATA, USA)
4. Stellios Stratidakis, Marine Traffic, Athens
5. Jaco Voorspuij, GS1
6. Laurent Gonzalez, GS1 France
7. Bertrand Geoffray, BIC , France
8. Jorn Heerulff, BIC,
9. David Roff, CIF, UK
10. Christophe THUILLIER (Port of le Havre.. Unfortunately, he is deceased a day or two before Christmas!)
11. Victor Dolcemascolo, French Gouverment
12. Joelle Friedmann, Geneva
13. Cleiton Alves dos Santos Joao Simoes, Brazilian Customs
14. Rudy Hemeleers, E-CMR Project Editor, DTLF rep. and an Independent consultant Luxembourg
15. Lance Thompson, Secretary, UN/CEFACT - UNECE Geneva
16. Ian Watt, UN/CEFACT Vice Chair: International Supply Chain, Australia
17. Sue Probert, UN CEFACT Chair and an Independent consultant
Step 2: Semantic
This is an example of an existing data model of the UN/CEFACT Core Component Library
UN/CEFACT Smart Container Modeling
SEMANTIC MODEL MultiModal Transport (MMT)
(subset of BSP)
MultiModal (MMT) Master message structure
Smart Container message model
APISmart Container Data schema
Buy/Ship/Pay (BSP)Semantic modelSubset of CCL
BUY SHIP PAYMaster message structure
MMT subsetExchange Syntax-neutral data exchange structure
Part of
Part of
Sensor
Sensor ID
Sensor Owner ID (optional)
Sensor Manufacturer ID (optional)
Sensor Position (optional)
Sensor type Enum
Sensor Unit Enum
Characteristics Range of Values [X, Y] (optional) ??
Expected Values Setting Configuration range [A, B] (optional)
TimeStamp
Universal UTC
Date
Hour
Minutes
Seconds
ZOI (Zone Of Interest are the places in “the itinerary/trip plan” for geofencing/facility) ??
Place Type Enum {Depot pick-up, Master Contract Consignor Place Of Acceptance, POL,
POT, POD, FDD, Depot return} (optional)
Indicator Public information OR Private information (optional)
Place Code (optional)
Place Name (optional)
Booking Reference??
Booking Reference ID (optional, example empty container)
Transport Equipment Operator (optional)
Transport Equipment ID
Trip plan {ordered set of legs (start ZOI + end ZOI) + mode of transport + Party+
ETD/ETA}??
House Transport Contract Reference(s)
Indicator Smart Booking
Requested/Expected measurements for the different sensors (e.g., humidity,
temperature settings)
Responsible Container Party
Responsible Container Party ID
Contact
Email (optional)
Phone number (optional)
Indicator ZOI or Leg
Linked to the leg/ZOI of trip plan
Semantic: Smart ContainerThis was a start on defining the semantic, currently in progress, for the Smart Container Project. This is based on the Multi-Modal Transport Data Model.
BRS Excerpts
Component Library Approach: Reduction of complexity through reusable document building blocks
23
Article IDDescriptionPriceColorWeight
Article
Article IDDescriptionPriceColorWeight
Catalog_Article
Article IDDescriptionPriceColorWeight
Order_Article
Article IDDescriptionPriceColorWeight
Invoice_Article
Contextualization by omitting non-used elements
Contextualized messages structures
24
Bill of Lading/IFTMCS
Container BayPlan/BAPLIE
Pipeline Data Exchange Structure (CORE/SELIS)
C
Operational Manifest/IFCSUM
1:1
1:1
1:1
1:1
1:1
1:*
1:1
1:1
1:1
1:1
1:1
1:1
1:1
1:* 1:*
1:1
Step 3: Example Smart Container Message layout (work in progress)
Step 4: API based on Generic Master Message structure to serve the whole ecosystem
Smart ContainerData
Elements/message
Multimodal TransportReference
Data Model
UN/CoreComponent
Library
New data
Elementshighly cross-compatible Smart Container API
APIs: JSON, REST, SOAP, etc.Multi Syntax world
IV. Summary
Summary
• CCL as semantic building blocks for the definition of business data for processes - Context free – reuse in multiple business sectors
• Customization of generic core components to specific business sectors and application domains
• Specific APIs (code-based specifications) to be used as interfaces by different services (software components) to communicate with each other and build a composite service.