Air Status EDI
From UG
(→One CT multistop flight Use Case) |
(→Business Requirements and Design Ideas) |
||
| Line 29: | Line 29: | ||
Our system may accomodate one. We need to add flexibility if there are more than one - see updated interface below. | Our system may accomodate one. We need to add flexibility if there are more than one - see updated interface below. | ||
| + | <font color="red" >'''!!!! NOTE: Below are just design ideas and must be discussed / finalized before implemented !!!'''</font> | ||
[[File:1 transhipment point.JPG]] | [[File:1 transhipment point.JPG]] | ||
| Line 40: | Line 41: | ||
* so on | * so on | ||
| - | + | ||
=== Split Use Case === | === Split Use Case === | ||
| Line 53: | Line 54: | ||
We need to modify our UI / DB to accommodate this case | We need to modify our UI / DB to accommodate this case | ||
| + | |||
| + | <font color="red" >'''!!!! NOTE: Below are just design ideas and must be discussed / finalized before implemented !!!'''</font> | ||
[[File:Split case.JPG]] | [[File:Split case.JPG]] | ||
Revision as of 21:48, 29 October 2010
Contents |
Parent mantis
0002422: [Air Status EDI] ............. <proj parent>
Business Requirements and Design Ideas
Intro
Project: Automated air status update service (EDI with Descartes)
This will allow airfreight shipments booked directly by Jaguar with the airlines, to be fed automatic status updates (departure and arrival dates), removing our need to manually check and then update the status of Airfreigt shipments.
One CT one direct flight Use Case
One CT is traveling on one airplane from origin to destination.
In this case CT2 system should send Ct#MAWB through EDI as soon as it gets assigned by oper.
We assume that Descartes will send back:
One CT multistop flight Use Case
In this case there is one or more airport of transhipment.
Our system may accomodate one. We need to add flexibility if there are more than one - see updated interface below.
!!!! NOTE: Below are just design ideas and must be discussed / finalized before implemented !!!
We assume that Descartes will send back:
- Ct#Airport_Of_Departure_Actual_Date first
- Ct#Airport_Of_Destination_Actual_Date later
- Ct#Trans_Shipment_Actual_Date - first trans-shipment
- Ct#Trans_Shipment_Actual_Date2 - 2nd trans-shipment. New field!
- so on
Split Use Case
In this case airline might call and say that X plts will be placed on Flight F1.
Later airline might call and say that Y plts will be placed on Flight F2.
Later airline might call and say that remaining plts will be placed on Flight F3.
It could be split 2,3,4, ... times.
We need to modify our UI / DB to accommodate this case
!!!! NOTE: Below are just design ideas and must be discussed / finalized before implemented !!!
Technical Requirements and Design
Intro
CT2 and Descartes system (GLN) will exchange XML messages.
In a nutshell:
- CT2 sends MAWB (same as FWB) to Descartes(GLN) network/server
- GLN forwards to Airline nework
- when update becomes available info is passed back to CT2 through Descartes
One CT one direct flight Use Case TR
Outgoing message
Must be included:
- From (Jaguar id)
- To (Airline id)
- doctype
- FWB number
Example
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns3:Envelope xmlns:ns2="http://www.myvan.descartes.com/ebi/2004/r1" [^] xmlns:ns3="http://www.w3.org/2003/05/soap-envelope" [^] xmlns:ns4="http://schemas.xmlsoap.org/ws/2004/03/addressing"> [^]
<ns3:Header>
<ns4:From>
<ns4:Address>urn:duns:657589457</ns4:Address>
</ns4:From>
<!—THIS NEEDS TO BE THE AIRLINE ID.-->
<ns4:To>urn:duns:657589457</ns4:To>
<ns4:Action>urn:myvan:FWB</ns4:Action>
<ns2:Sequence>
<ns2:MessageNumber>351-5648-6541</ns2:MessageNumber>
</ns2:Sequence>
</ns3:Header>
<ns3:Body>
<JaguarFile>
<Shipment>
<FWB>
351-5648-6541
</FWB>
</Shipment>
</JaguarFile>
</ns3:Body>
</ns3:Envelope>
Incoming message
TBD
