ACRIS Service Definition-Baggage Check-In Draft v09

ACI AIRPORT COMMUNITY
RECOMMENDED INFORMATION
SERVICES – ACI ACRIS
BAGGAGE CHECK-IN SERVICE

SERVICE DEFINITION
An ACI World Airport IT Standing Committee initiative
Draft version 0.9

May 2012
SERVICE DEFINITION – BAGGAGE CHECK-IN SERVICE
ACI ACRIS Service ID
Service Name Baggage Check-in Service
Version number 0.9
Release Date : 2012-05-04
Status : Ready for presentation to ACRIS community
Change History
Version Date Description Author
0.1 2 May 2012 Initial draft Arie van der Veek
0.2 3 May 2012 Incorperated feedback Eric Lansbergen Arie van der Veek
0.9 3 May 2012 Finalized draft version for presentation to Arie van der Veek
ACRIS community
ACI WORLD AIRPORT IT STANDING COMMITTEE 2/36 Draft v.0.9 - 20120504

Table of Contents
References ...............................................................................................................................5
1. Introduction........................................................................................................................6
2. Requirements ....................................................................................................................8
2.1. Level 2 requirements – (Non-) functional requirements for all implementations ...............8
2.2. Level 3 requirements - (Non-) functional requirements for specific implementations ........8
3. Design Decisions ...............................................................................................................9
4. Service Description.......................................................................................................... 12
4.1. Business Object............................................................................................................. 12
4.2. Static View..................................................................................................................... 13
4.3. Dynamic View ................................................................................................................ 13
5. Definition of message structure ....................................................................................... 14
5.1. Common data structures ............................................................................................... 14
5.1.1. BCPB data structure ................................................................................................... 14
5.1.2. UniqueIdOfAirline element .......................................................................................... 17
5.1.3. Result data structure .................................................................................................. 17
5.2. Identify Passenger method ............................................................................................ 19
5.2.1. Message: IdentifyPassengerRequest ......................................................................... 19
5.2.2. Message: IdentifyPassengerReply ............................................................................. 20
5.3. Get Bag Tag method .................................................................................................... 26
5.3.1. Message: GetBagTagRequest ................................................................................... 26
5.3.2. Message: GetBagTagReply........................................................................................ 27
5.4. Commit Bag Tag method .............................................................................................. 31
5.4.1. Message: CommitBagTagRequest ............................................................................. 31
5.4.2. Message: CommitBagTagReply ................................................................................. 33
6. Error handling .................................................................................................................. 34

Abbreviations and Definitions

This chapter will contain abbreviations and definitions which are used in this document.
Abbreviation/Definition Meaning
ACI Airports Council International.
ACRIS Airport Community Recommended Information Services.
BCBP Bar Coded Boarding Pass, the IATA standard which describes the
data elements of the barcode on the boarding pass.
BSM Baggage Source Message, a message sent from the DCS to the
BHS to indicate a bag is injected into the BHS.
BHS Baggage Handling System is a system that routes and transports
baggage from the point the passenger drops it off to the airplane.
Contract/Code first Contract first development refers to the method of Web Service
development development where first the service contract is designed in the
form of a WSDL and then the implementation is made of the
service. This is contra to code first development where the WSDL
is generated from the actual code.
Coupling (tight/loose) The terms tight data coupling and loose data coupling are used to
denote whether the WSDL will contain a description of the data.
DCS Departure Control System.
SOA Service Oriented Architecture, an Information Technology
principle based on loosely coupled services in order to support
business flexibility in an interoperable and technology
independent way.
SSDOP Self Service Drop Off Point
Web Service A method of communication between two electronic devices over
the web.
WSDL Web Services Description Language, a XML format for describing
network services.
XML Extensible Markup Language, a markup language that defines a
set of rules for encoding documents in a format that is both
human-readable and machine-readable.

References
Nr Document
1 ACI - ACRIS Recommended Practice, ACI_RP502A10_ACRIS, version 1.0, April 2011
2 Air Transport & Travel Industry, PADIS EDIFACT and XML codeset, version 12.1,
February 2012
3 IATA RESOLUTION 792 Bar Coded Boarding Pass (BCBP), Version 3

1. Introduction
This document describes the baggage check-in service. This documentation contains
information about the functionality of the service and how it can be used by client. This
documentation does not contain information about the implementation logic and requirements of
all the different departure control systems (DCS) wrapped by this service. These should be
described in separate implementation document.
This service provides the following functionality to support the baggage check in process within
the passenger process:
 Check if the passenger is on the flight and the passenger is allowed to check in baggage
 Get a bag tag from the DCS
 Commit a bag tag in the DCS when the bag is fully processed
The current version does not (yet) support functionality which has already been identified as
potential additions in functionality: registration of payment information, calculation of overweight
fee, support for pre-tagged luggage, visa check and support for upgrades. At this point in time
only the boarding pass is used as identification token of passengers. Tokens like passport of
frequent flyer card are not (yet) supported.
The service itself doesn’t handle any airline business logic. The logic for checking if a passenger
is allowed to check in baggage or how a License Plate Code (LPC) is generated is the
responsibility of an airline. This logic is present in a system that is called a Departure Control
System (DSC). A DCS is an airline system and not an airport system. Each DCS has his own
way of exposing services to use the DCS and provide baggage check in functionality. This
service provides a uniform way to access all these different DCS with their different technologies
and interaction protocols and hides airline specific logic from its clients. This service is designed
to be capable to interact with multiple DCS.
This service is a technical service and not a business service, because it does not contain the
actual business process that handles the full baggage check in. This process still requires user
interaction and can differ per airport/airline. This service provides building blocks that enable
applications to implement this business process. This service is only limited to baggage check-in
and not passenger check-in. Passenger check-in is viewed as a separate service. Both services
could of course be combined in one business process that does both passenger and baggage
check-in.

The typical use case for this service is when functionality of more than one DCS needs to be
exposed to clients. For example a series of common use self-service drop off point (SSDOP)
which needs to service passengers of all the airlines in one single terminal. This service can be
used to provide one uniform interface towards the SSDOP’s and hide airline specifics.
Figure 1 shows an example application of the baggage check-in service. It provides one uniform
service definition for the SSDOP’s, so they only need to implement one client and its
corresponding logic. The Baggage Check-in Service handles the requests and translates them
to the logic and protocols for the different DCS. Also it can for example invoke an external
business rule engine if the business rules are not present in the DCS.
Figure 1 - Example application of the Baggage Check-in Service
The service definition is not limited to only cases where multiple DCS need to be exposed.
Figure 1 also shows that DCS of Airline D uses the ACRIS Baggage Check-in Service Definition
to expose its baggage check-in functionality. This service can also be used on the DCS side, or
wherever it fits the requirements.
This service is also not limited to only Self Service Drop Off Points. For example it can also be
used for off airport bag drop at a car park or a specialized company that picks up luggage at
home. The building blocks are available and do not limit the business processes developed by
clients.

2. Requirements
Level 1 requirements are externalized as they apply to all ACRIS services.
2.1. Level 2 requirements – (Non-) functional requirements for all

implementations
Characteristic Requirement
Availability: 24/7 availability recommended. The availability does not span to the
services used on the DCS. It is recommended to agree on availability
requirements for each individual DCS in a separate implementation
document.
Message order: Parallel. The order of messages in processing is irrelevant, because
the service is stateless.
Response Time: The response time of the service is highly dependent on the DCS
that is queried and the method of querying. The maximum response
time of any DCS cannot be higher than 30 seconds. Average
response time will be between 1 and 5 seconds.
Monitoring: N/A
Error handling: Standardized error should be returned by the service, so errors can
be handles by clients in the same manner. Please read the chapter
Error Code for more information
Message Patterns: Request - Reply
Incoming protocol: SOAP over HTTPS
Outgoing protocol: SOAP over HTTPS
Message Size: The expected average message size is variable, expected to be
between 1Kb and 5Kb.
Frequency: N/A, depends on local situation
Security: Yes, WS-Security username/password token
Transaction No transactions are supported
management:
2.2. Level 3 requirements - (Non-) functional requirements for specific

implementations
2.2.1. Not applicable.

3. Design Decisions
The following design decisions have influenced the design of the service.
Design decision 1
Issue How do we manage the state between the service provider and consumer
Decision We don’t. The baggage check-in service is stateless.
Assumptions A passenger takes between 30 and 120 second to check in a bag.
Constraints
Positions
Argument Applying transactions will impose to much overhead to the solution.
The DCS is the leading source of information and this information can be
altered by many “unknown” sources. Replication state over all these
sources would lead to unacceptable complexity.
The chance that the parts of passenger data that are needed for baggage
check-in is altered during the time the passenger is dropping of a bag is
minimal. If it does happen, the solution should be able to handle the
exception state.
Also keeping state in the service will severely limit the easy by which the
service can scale.
Implications If the passenger details are updated
Notes
Design decision 2
Issue Should active bag tags (LPC’s) allowed to be returned by the service
Decision No, It must be guaranteed by the DCS that at this point in the process the
tags are NOT active yet in the DCS.
Assumptions All DCS are able to produce inactive tags
Constraints
Positions
Argument This is a security feature so there are no tags that are activated in the
passenger’s control.
An active tag in the hands of a passenger can be put on another suitcase

then for which it was distributed and it could be inserted via an unchecked
way into the BHS.
The tags should be activated by the SSDOP at the point that a non-
authorized person cannot access the bags anymore before being inserted
into the BHS.
Implications There is no functionality to “delete” a tag.
Notes If the assumption “All DCS are able to produce inactive tags” turns out to
be invalid, there must be a way to flag a tag active or not when retrieving it
and a method should be exposed to delete a tag.

Design decision 3
Issue Should we support committing multiple LPC’s at one time
Decision No
Assumptions When committing an individual tag it can go wrong while committing it.
The client can only inject one piece of baggage to the BHS a time.
Committing of a tag is done BEFORE it is inserted into the BHS. This gives
the DCS a final “go/no go” moment to determine if the bag can proceed or
not.
Constraints
Positions
Argument One committing one bag tag at a time is supported, because there is no
support for transactions.
The client must be forced to process and commit bags one by one to
prevent the transmission of a BSM message while the baggage is not
injected into the BHS.
Example: Two tags are committed via the service. Bag 1 is injected into
the BHS. Bag 2 gives an error. Now there is a bag in the machine that is
committed, but not inserted in the BHS. Depending on the client it can be
returned to the passenger and there is an activated tag but no suitcase in
the BHS. This can give issues with baggage reconciliation and baggage
safety.
Implications
Notes
Design decision 4
Issue What tokens should we use to identify a passenger
Decision Barcoded Boarding Pass
Assumptions Every passenger is checked in and has received a boarding pass at check
in
Constraints
Positions Use the Barcoded Boarding Pass
Use the Passport
Argument Currently each passenger has a barcoded boarding pass after he/she has
checked in. All boarding passes are implemented following BCBP as of
December 2010 as announced by IATA
(http://www.iata.org/pressroom/pr/Pages/2010-12-15-01.aspx)
Therefore it is the most widely used standard to identify a passenger when
he/she is present in the terminal.
Passport is another identification token that every passenger needs to

have when flying. The issue with the passport though is that not all
passports are machine readable, and therefore it is not a suitable token to
use for automation.
Implications
Notes

Design decision 5
Issue Some airlines, mainly low cost carriers, do not fill one or more of the
following fields: CabinType, SeatNumber and PassengerStatus.
The IATA resolution 792 states that all mandatory fields must be filled. In
practice these fields are filed with blanks (spaces).
These fields are mandatory in the BCBP schema, therefore not sending
them will result in invalid XML messages.
Decision Make fields optional in BCBP schema
Assumptions
Constraints
Positions Making the fields optional in the BCBP schema, not making any change
Argument The least evasive way to change the schema is making the fields optional.
This leaves the patterns defined for the fields intact.
If we do not make the change we exclude a significant portion of potential

users of the SSDOP service.
Implications The BCBP schema used by the service is not conform the IATA PADIS
definition
Notes
Design decision 6
Issue Some airlines do not support one unique identifier or lack a unique
identifier, while it is mandatory for all calls except the identify passenger
call
Decision The baggage check-in service shall compose a key based on values given
by the service. Each implementation is free to determine what how to
compose the key.
Assumptions
Constraints
Positions Composing a key in the service
Making the field optional and using a different way of identification (BCBP)
Argument In the field it is seen that many DCS have a form of uniquely identifying a
passenger with an ID. The form differs, but coding this form in one field by
a composite key will solve this issue easily.
Sending the BCBP each time introduces a lot of overhead to the service,
as unnecessary fields are sent over each call. Also all this data needs to
be managed by the client for the full duration of the transaction. Keeping
only an unique identifiers saves in data management on the client.
The composite key can be as long as desired, so it should not limit the
capabilities to generate a key that meets the requirements of the DCS.
Implications The key should be given unaltered from client to service and back. Once a
key has been generated it should not change during the transaction.
Notes

Design decision 7
Issue How do we make distinction between the Airline that is operating the flight
and what airline branding should be shown
Decision Introduce the field OperatingAirline and BrandingAirline

Assumptions
Constraints
Positions
Argument The operating airline is a key field for the service to determine in which
DCS the PNR is located. Operating airline is determined from the boarding
pass and should be included in each call for the service to be able to route
the messages to the correct DCS.
The BrandingAirline field indicates to which airline the solution should be

branded. This gives the client the flexibility to differ from default layouts.
Branding is the responsibility of the airline, so it is returned in the
IdentifyPassenger method after querying the DCS.
Example usage:
A passenger buys a ticket from Kenya Airways which is a partner of KLM.
KLM operates the flight and Kenya Airways is a code share. On the
boarding pass the operating airline is KL, The service knows based on the
OperatingAirline field to go to the KLM DCS to locate the passenger.
Kenya Airways has its own branding on the client. The service returns KQ
as branding airline, so the client know to load the Kenya Airways branding
instead of the KLM branding.
Implications
Notes
4. Service Description
The Baggage check-in service contains three service calls to provide the previously described
functionality. As stated before, the service is stateless.
First off the business objects that have been reused will be described. Then the static and
dynamic view is described.
4.1. Business Object

Boarding Pass object as defined by IATA within the BCBP standard. Used documentation:
1. IATA XML Schemas 12_1.zip - IATA_BarCodeBoardingPassRQ.xsd (ID:IATA2012.1)
Please find these documents and schema’s on the PADIS site of IATA. Registration and access
to the documents is free of charge.

For the other information exchanged by the services there are no known standards available
and therefore they are modeled specifically for this service. If standards prove to be applicable
they will replace these elements.
4.2. Static View

This paragraph describes the service calls, and how the service calls are structured. The in
detail message structure is discussed in paragraph “Definition of Message Structure”
Name of the Description Structure
service call
IdentifyPassenger The functionality of this method is to Pattern: Request Reply
check if a passenger is on the flight and
Request:
the passenger is allowed to check in
IdentifyPassengerRequest
baggage and return this result to the
service consumer. It will also return Reply: IdentifyPassengerReply
additional information like the
destination, baggage allowance and
departure gate of the flight.
GetBagTag The functionality of this method is to Pattern: Request Reply
retrieve one or more bag tags from the
Request: GetBagTagRequest
DCS. It will return the Tag ID’s and the
additional information needed to be Reply: GetBagTagReply
able to print the baggage labels
CommitBagTag The functionality of this method is to Pattern: Request Reply
commit a bag tag when the bag is fully
Request:
processed. The bag will be made active
CommitBagTagRequest
in the DCS. An example action that can
be done by the DCS is to send a Reply: CommitBagTagReply
Baggage Source Message (BSM) to the
Baggage Handling System (BSM).
4.3. Dynamic View

There is no predefined dynamic behavior for the service. As stated before the service exposes
building block for a business process, which defines the dynamic behavior. Also the behavior
towards the DCS is not predetermined and can in each case be different, so this also cannot be
modeled.
The logical way of handling a drop off is to first identifying a passenger, then getting a bag tag
and finally committing a bag tag. But if pre tagged luggage is used, the getBagTag operation can
be skipped. As stated before, the service is stateless and it does not prevent invocation in the
“wrong” order.

5. Definition of message structure

This chapter contains detailed information on the information exchanged. There are data
structures that are repeated in multiple messages. These will be explained in the following
paragraph. In the paragraphs following the common data structures, the methods and their
request/reply messages will be described. The repeated data structures will not be mentioned in
the message paragraphs but only referenced. The specific data elements to a message that are
not repeated will be explained in the message paragraphs.
The XSD pictures in this document represent the XSD. Any pictures of XML data structures
might contain unfolded structures or do not show all attributes fully. This is done so pictures are
readable on one page. All the elements and attributes are noted in the tables. The fields that
have a solid line are mandatory and the fields that have a broken dotted line are optional. Please
note that all XML messages in this document are example messages and might not reflect all
responses by the server.
5.1. Common data structures

This paragraph describes the data structures that are used in multiple service calls and have the
same content and meaning in each service call.
5.1.1. BCBP data structure
This service only supports boarding pass data in the format specified in IATA resolution 792 [3].
This is the IATA standard for Bar Coded Boarding Passes (BCBP). IATA has released an XML
schema for a message that contains the BCBP structure in named
IATA_BarCodeBoardingPassRQ. This structure contains all elements on a boarding pass and
extra information elements for message routing and identification.
The message is not used in its original context or IATA recommendations. It is only used to
represent a BCBP in a standardized way. This document describes the bilateral agreement
between the service producer and consumer on how the XML structure should be used and
populated.
The BarCodeBoardingPassRQ is required for identifyPassenger methods, because this is the
primary identification token for passengers at this moment in time at an airport for baggage drop
off.
Figure 2 shows the data structure schematically and Table 1 describes the elements that
should be filled.

Figure 2 - BCBP data structure

As the scan of the 2D barcode should result in the same data as defined in the BCBP XML
schema, an elaborate definition is not given. Please review the IATA resolution 729
documentation [3] in case of questions. The BCBP XML is part of IATA PADIS.
The elements in the following table should be filled. General rule is to fill in as much information
as possible, but at a minimum all the required elements. The Optional/Required indicator is
based on the optionality needed for this interface. A field might be optional in the XSD, but
needs to be filled for this service. This difference is represented in the two columns
If an element and its sub elements should be filled, then only the container element is described.
In the description is stated that the subfields should be filled.
All attributes and elements that are defined as required in the XSD, should be filled.
Field Tag Name XML Data Option or Option or Description

Type Required Required
for service in XSD
IATA_BarCodeBoardingPassRQ Container for BCBP Data
IATA_BarCodeBoardingPassRQ/ Decimal Required Required Version of message. Use hardcoded
@Version 0
IATA_BarCodeBoardingPassRQ/Originat String Required Optional The unique identification for the
or/ Souce/RequestorId/ID SSDOP client, for example
SSDOP.B12.R7
IATA_BarCodeBoardingPassRQ/ String Required Required Fill as many sub elements as
RequiredInformation / PassengerName possible. The minimal fields that
should be filled are the required
fields.
IATA_BarCodeBoardingPassRQ/ Required Required Fill as many sub elements as possible
Segment [ 1..4 ] and send all available segments. The
minimal fields that should be filled are
the required fields.
IATA_BarCodeBoardingPassRQ/ Required Required Only send the empty element
Security Security.
Table 1 - Element and attribute description for BCBP
Example of the structure with one segment:

<IATA_BarCodeBoardingPassRQ xmlns="http://www.iata.org/IATA/2007/00" Version="0">
<Originator>
<Source>
<RequestorID ID_Context="SSDOP.B19"/>
</Source>
</Originator>
<RequiredInformation>
<PassengerName>
<GivenName>ADRIANUS</GivenName>
<Surname>VANDERVEEK</Surname>
</PassengerName>
</RequiredInformation>
<Segment>

<OperatingCarrierPNR_Code ID="EJZ8MHP"/>
<FromCity>AMS</FromCity>
<ToCity>BJV</ToCity>
<OperatingCarrier>OR</OperatingCarrier>
<FlightNumber>0703</FlightNumber>
<DepartureDate>122</DepartureDate>
<CabinType>Y</CabinType>
<SeatNumber>019B</SeatNumber>
<CheckInSequenceNumber>0005</CheckInSequenceNumber>
<PassengerStatus>1</PassengerStatus>
</Segment>
<Security/>
</IATA_BarCodeBoardingPassRQ>
5.1.2. UniqueIdOfAirline element

The UniqueIdOfAirline element is the reference for a DCS to identify a passenger on a flight on a
specific date uniquely. For example 1234124|541234 can stand for a key that refers to a
passenger on a flight. This helps the DCS perform faster lookups. Generally speaking from a
technical point of view it is faster to find a passenger with an unique ID then on for example
name, flight and check-in sequence number.
This field is present in all messages except the IdentifyPassengerRequest. This field is
deliberately left out in the IdentifyPassengerRequest, because at the passenger identification
stage of the process the UniqueIDOfAirline is not present as it is not defined in the Boarding
Pass. All subsequent calls will be done based on the UniqueIDOfAirline
5.1.3. Result data structure

The result data structure will contain the result of the method with any additional information or
error messages if applicable. This is used in all reply messages, except when an SOAP fault
message occurs. Please read the chapter about error handling for details. Figure 3 shows the
data structure schematically and Table 2 describes the elements and attributes.

Figure 3 - Result data structure
Field Tag Name XML Data Option or Description

Type Required
Result Container for the result of an action
Result /ActionSuccessful Boolean Required Indicates if the action that the method should
perform is successful. What it functionally
means for a method is described in the
method paragraph.
Result /InfoMessages Optional Container for information messages. Will only

be used when ActionSuccessful is true and if
desired.
Result /InfoMessages/Message String Required Human readable information message. There

is no support for multiple languages
Result String Optional Code that represents the human readable

/InfoMessages/Message/@code message. Use this code to implement own
multi-language support.
Result / ErrorMessages Optional Container for error messages. Will only be

used when ActionSuccessful is false.
Result /ErrorMessages/Message String required Human readable information message. There

is no support for multiple languages
Result / ErrorMessages String Optional Code that represents the human readable
/Message/@code message. Use this code to implement own
multi-language support.
Table 2 - Elements and Attributes of Result

5.2. Identify Passenger method

5.2.1. Message: IdentifyPassengerRequest
The IdentifyPassgengerRequest message contains the information on the boarding pass. Figure
4 shows the message structure schematically. The BCBP XML Structure is described in the
common data structure paragraph.
Figure 4 - IdentifyPassengerRequest Message Structure

Exampe message:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<soap:Header/>
<soap:Body>
<IdentifyPassengerRequest xmlns="http://service.acris.aci.aero/baggagecheckinservice/types">
<IATA_BarCodeBoardingPassRQ xmlns="http://www.iata.org/IATA/2007/00" Version="0">
<Originator>
<Source>
<RequestorID ID_Context="SSDOP.B19"/>
</Source>
</Originator>
<PassengerName>
<GivenName>ADRIANUS</GivenName>
<Surname>VANDERVEEK</Surname>
</PassengerName>
<Segment>
<OperatingCarrierPNR_Code ID="EJZ8MHP"/>
<FromCity>AMS</FromCity>
<ToCity>BJV</ToCity>
<FlightNumber>0703</FlightNumber>
<DepartureDate>122</DepartureDate>
<CabinType>Y</CabinType>
<SeatNumber>019B</SeatNumber>
<CheckInSequenceNumber>0005</CheckInSequenceNumber>
<PassengerStatus>1</PassengerStatus>
</Segment>
<Security/>
</IATA_BarCodeBoardingPassRQ>
</IdentifyPassengerRequest>
</soap:Body>
</soap:Envelope>
5.2.2. Message: IdentifyPassengerReply

The IdentifyPassgengerReply message contains information if the passenger is found on the
flight and it is allowed to check in baggage. It also contains additional information about the
passenger, the destination and departure gate of the flight and how much bags and weight the
passenger is allowed. Figure 5 shows the IndentifyPassengerReply and Table 3 describes the
elements and attributes.

Figure 5 - IndetifyPassengerReply message structure.

Table 3 - Elements and attributes of the IdentifyPassengerReply
Field Tag Name XML Option or Description

Data Required
Type
Result Required As describes in the common data structure
paragraph
Result /ActionSuccessful Boolea Required ActionSuccessful is true when the passenger is found
n on the fight and the passenger is allowed to check in
baggage for the flight and the other elements besides
the result will contain data. If ActionSuccessful is false
then there were errors which can be found in the error
messages. When ActionSuccessful there will be no
other elements filled besides the result element.
PassengerDetails Optional Container for passenger details. This information

can be shown to the passenger to give additional
elements for the passenger to be able to
positively confirm his information.
PassengerDetails / Title String Optional The title of the person, for example Dhr. or Ir.
PassengerDetails /GivenName String Optional The given name of the passenger.
PassengerDetails /SurName String Optional Contains the passenger surname if no identification is

used that contains passenger name data.
PassengerDetails /DateOfBirth Date Optional Date of birth of a passenger.
PassengerDetails /Gender String Optional The gender of the passenger. Enum of Male, Female
or Unknown. Default: Unknown
FlightDetails Optional Container for flight details
FlightDetails / BrandingAirline String Required The IATA airline code indicating the airline for which
the Kiosk should be branded. This can be IATA 2 or 3
letter encoding.
FlightDetails/ Routes Required Container for routing information. Routes can contain
multiple route elements
FlightDetails/ Routes / Route Required List of route hops. The hops are sequentially ordered.
[1..10] The first in the list is the first stop of the flight and the
last one is the last stop of the flight. If there is only
one route it is a direct flight without stops
FlightDetails/ Routes / Route String Required The full flight number for example KL1255 or OR563
/FlightNumber
FlightDetails/ Routes / Route / Date Required The date on which the flight is scheduled to depart.
DepartureScheduleDate
FlightDetails/ Routes / Route / Time Optional The time on which the flight is scheduled to depart.
DepartureScheduleTime
FlightDetails/ Routes / Route / String Required The IATA code of the airport the flight departs from
DepartureAirportIATA


Data Required
Type
FlightDetails/ Routes / Route / String Optional The full name of the airport as returned from the DCS.
DepartureAirportName Language of name is not specified. There is no
support for multiple languages. The IATA code can be
used to translate the airport name to the required
FlightDetails / Routes / Route / String Optional The terminal the flight is departing from and where the
DepartureTerminal gate is located
FlightDetails / Routes / Route / String Optional The gate the flight departs from. Note it is optional
DepartureGate and might not be returned, even if it is the local
departure station.
FlightDetails/ Routes / Route / Date Optional The scheduled date on which the flight arrives. Is not
ArrivalScheduleDate mandatory, as it is not the departure time at the local
station
FlightDetails/ Routes / Route / Time Optional The scheduled time on which the flight arrives. Is not
ArrivalScheduleTime mandatory, as it is not the departure time at the local
station
FlightDetails/ Routes / Route / String Required The IATA code of the airport
ArrivalAirportIATA
FlightDetails/ Routes / Route / String Optional The full name of the airport as returned from the DCS.
ArrivalAirportName Language of name is not specified. There is no
support for multiple languages. The IATA code can be
used to translate the airport name to the required
FlightDetails / Routes / Route String Optional The terminal the flight is departing from and where the
/ArrivalTerminal gate is located
FlightDetails / Routes / Route / String Optional The gate the flight departs from. Note it is optional
ArrivalGate and might not be returned, even if it is the destination
from the airport the flight departs from.
UniqueIdOfAirline Required As describes in the common data structure

paragraph.
Booking Required Container for the booking data
Booking /SeatNumber String Optional The seatnumber of the passenger on the local flight
Booking /Compartment String Optional The compartment in which the seat is located like
business class.
Booking /Compartment /@Code String Optional The IATA code for the compartment
Booking / BaggageAllowance Required This element contains the allowance for a pieces or
weight based system.
Booking / BaggageAllowance / Decima Required The amount of KG a single bag may weigh If there is
WeightPerBag l a limit to the total weight of all the bags of a
passenger, it should be stated in the Weight element.
This element regards both to pieces and weight
concept.


Data Required
Type
Booking / BaggageAllowance / Boolea Optional Indicator if the allowance is estimated by applying
AllowanceIsEstimated n default rules instead of actual baggage allowance. If
for example for an airline the allowance is set in the
comments and this cannot be read, then default rules
are applied to give an allowance. This flag can be
used to indicate this happened and the service client
can anticipate to it if needed.
The field is optional. If the field is not present, the
information is not available. No assumptions are
made if allowance is estimated or not.
Booking / BaggageAllowance / Choice Information regarding the piece allowance

PieceAllowance Element
Booking / BaggageAllowance / Integer Required The amount of bags that the passenger is allowed to
PieceAllowance / AllowedPieces check in
Booking / BaggageAllowance / Decima Required The tolerance that can be given in kilograms on top
PieceAllowance / l of the allowed weight, for example 0.9KG. By
WeightTolerance separating allowed weight and tolerance one can hide
the tolerance applied from the passenger.
Booking / BaggageAllowance / Decima Required The amount of weight that all the bag in total may
PieceAllowance / l weight in kilograms
TotalAllowedWeight
Booking / BaggageAllowance / Choice Information regarding the weight allowance

WeightAllowance Element
Booking / BaggageAllowance / Decima Required The tolerance that can be given in kilograms on top
WeightAllowance / l of the allowed weight, for example 0.9KG. By
WeightTolerance separating allowed weight and tolerance one can hide
the tolerance applied from the passenger.
Booking / BaggageAllowance / Decima Required The amount of weight that all the bag in total may
WeightAllowance / l weight in kilograms
TotalAllowedWeight
Booking / BaggageAllowance / Decima Optional Contains data about the baggage already checked in.
BaggageAlreadyCheckedIn l If the DCS does not contain the information, the
element will not be filled. If it is present then it is filled.
If the element is not present it can be assumed that
there is no baggage checked in.
Booking / BaggageAllowance / Integer Optional The amount of pieces of baggage already checked in
BaggageAlreadyCheckedIn /
AmountOfPieces
Booking / BaggageAllowance / Integer Optional The amount of weight already checked in

TotalAllowedWeight
Booking / BaggageAllowance / Optional Container for array of bag tag id’s already checked in.


Data Required
Type
BagTagIds
Booking / BaggageAllowance / String Required A bagtag id that is already checked in for passenger.
BagTagIds / BagTagId
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<S:Body>
<ns2:IdentifyPassengerReply xmlns="http://www.iata.org/IATA/2007/00" xmlns:ns2="http://
service.acris.aci.aero/baggagecheckinservice/types">
<ns2:Result>
<ns2:ActionSuccessful>true</ns2:ActionSuccessful>
</ns2:Result>
<ns2:ResultData>
<ns2:PassengerDetails>
<ns2:Title>Ing.</ns2:Title>
<ns2:GivenName>Adrianus Cornelis</ns2:GivenName>
<ns2:SurName>VANDERVEEK</ns2:SurName>
</ns2:PassengerDetails>
<ns2:FlightDetails>
<ns2:BrandingAirline>KL</ns2:BrandingAirline>
<ns2:Routes>
<ns2:Route>
<ns2:FlightNumber>KL1945</ns2:FlightNumber>
<ns2:DepartureScheduleDate>2011-04-17+02:00</ns2:DepartureScheduleDate>
<ns2:DepartureScheduleTime>14:03:22.954+01:00</ns2:DepartureScheduleTime>
<ns2:DepartureAirportIATA>AMS</ns2:DepartureAirportIATA>
<ns2:DepartureAirportName>Amsterdam</ns2:DepartureAirportName>
<ns2:DepartureGate>E23</ns2:DepartureGate>
<ns2:ArrivalScheduleDate>2011-12-29+01:00</ns2:ArrivalScheduleDate>
<ns2:ArrivalScheduleTime>14:03:22.954+01:00</ns2:ArrivalScheduleTime>
<ns2:ArrivalAirportIATA>BCN</ns2:ArrivalAirportIATA>
<ns2:ArrivalAirportName>Barcalona</ns2:ArrivalAirportName>
<ns2:ArrivalGate>A10</ns2:ArrivalGate>
</ns2:Route>
</ns2:Routes>
</ns2:FlightDetails>
<ns2:UniqueIdOfAirline>PUK|23453|92474324</ns2:UniqueIdOfAirline>
<ns2:Booking>
<ns2:SeatNumber>14D</ns2:SeatNumber>
<ns2:Compartment ns2:code="C">Economy</ns2:Compartment>
<ns2:BaggageAllowance>
<ns2:WeightPerBag>32</ns2:WeightPerBag>
<ns2:AllowanceIsEstimated>false</ns2:AllowanceIsEstimated>
<ns2:WeightAllowance>
<ns2:WeightTolerance>0.9</ns2:WeightTolerance>
<ns2:TotalAllowedWeight>23</ns2:TotalAllowedWeight>
</ns2:WeightAllowance>
</ns2:BaggageAllowance>
</ns2:Booking>
</ns2:ResultData>
</ns2:IdentifyPassengerReply>
</S:Body>
</S:Envelope>

5.3. Get Bag Tag method

5.3.1. Message: GetBagTagRequest
The GetBagTagRequest message contains information about the passenger like the flight of the
passenger, the passenger UniqueID and the amount of tags requested
Figure 6 shows the GetBagTagRequest message and Table 4 describes the elements and attributes.
Figure 6 - GetBagTagRequest Message

Type Required
Flight Required
FlightNumber String Required The full flight number, for example: KL2535 or
OR2347
ScheduleDate Date Required The date on which the flight is scheduled to

depart.
OperatingCarrier String Required IATA 2 or 3 letter code for the operating Carrier as
specified on the boarding pass, for example KL or
EZY.

paragraph.
AmountOfTags Required The amount of tags that the DCS should return.
The amount is limited to 1 upto and including 25
tags per request.
Table 4 - Element and attribute description for GetBagTagRequest

Example:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance">
<soap:Header/>
<soap:Body>
<GetBagTagRequest xmlns="http://service.acris.aci.aero/baggagecheckinservice/types">
<Flight>
<FlightNumber>OR0703</FlightNumber>
<ScheduleDate>2012-05-01</ScheduleDate>
</Flight>
<UniqueIdOfAirline>|CODECO|01MAY|OR0703|BJV|L|109B36CB006C|</UniqueIdOfAirline>
<AmountOfTags>1</AmountOfTags>
</GetBagTagRequest>
</soap:Body>
</soap:Envelope>
5.3.2. Message: GetBagTagReply

The GetBagTagReply message contains the bag tag information like the Bag Tag ID and the destinations
on the tag. The method does not support multiple tags with multiple destinations in one method call. All
ID’s that are on a tag, must share all the data. Otherwise the creation of the physical tags can become
very complex and error prone. So a tag with ID 12345 and destination AMS and a tag with ID 0987 to
destination FRA is not supported in the same call.
This does pose a problem with for example short labeling one bag in a set of multiple bags. This is not
supported in the current setup.
Figure 7 shows the GetBagTagReply message and Table 5 describes the elements and attributes.

Figure 7 - GetBagTagReply message

Type Required
Result Required As describes in the common data structure
paragraph.
Result /ActionSuccessful Boolean Required ActionSuccessful is true when a bag tag has been
successfully created and the other elements besides
the result will contain data. If When ActionSuccessful is
false then there were errors that can be found in the
error messages and no other elements will be filled
besides the result element.
Choice BagTagData or Required Choice containing either the Bagtag data as normal
PECTAB Data data or in the AEA PECTAB standard
BagTagData String Choice Container for bag tag data to create own tags.
BagTagData/ PassengerName String Optional The name of the passenger that should be printed on
the baggage label


Type Required
BagTagData / PNRCode String Optional The PNR Code of passenger
BagTagData / String Optional The check-in sequence number of the passenger

CheckinSequenceNumber
BagTagData / BagTagIDs / Required Container for bag tag id’s
BagTagData / BagTagIDs / Required The bag tag id’s as issued by the airline
BagTagID [1..25]
BagTagData / Required The numeric value of the issueing airline of the

IssuingOperatingAirline baggage tags.
BagTagData / Required The IATA 2 code of the issuing airline

IssuingOperatingAirline /
@IATA2
BagTagData / Required The IATA 3 code of the issuing airline

IssuingOperatingAirline /
@IATA3
BagTagData / Required Container for a destination

DestinationsOnTag /
Destination [1..10]
BagTagData / String Required The IATA Code of the destination

DestinationsOnTag /
Destination / IATAAirport
BagTagData / String Optional The human readable name of the destination

DestinationsOnTag /
Destination / IATAAirport /
@name
BagTagData / String Required The flight number of the flight towards the destination,
DestinationsOnTag / eg. KL0334 or OR235
Destination / FlightNumber
BagTagData / Date Required The departure date of the Flight

DestinationsOnTag /
Destination / DepartureDate
PECTABData Choice Container for raw PECTAB data that can be sent to
AEA Compatible printers. No additional data is
supplied
PECTABData / String Required The template of the bag tag

BagTagTemplate
PECTABData / String Required The bag tag print stream of a tag

BagTagPrintStream
Table 5 - Elements and attributes of the GetBagTagReply message

Example with Pectab:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
<S:Body>
<ns2:GetBagTagReply xmlns="http://www.iata.org/IATA/2007/00"
xmlns:ns2="http://service.acris.aci.aero/baggagecheckinservice/types">
<ns2:Result>
</ns2:Result>
<ns2:ResultData>
<ns2:PECTABData>
<ns2:BagTagTemplate>BTT0100+F 530245=)01I1 1004130431)02I1 1016130431=01)03I1
A195259931=01)04I1MC165514923=01)05C0M1132020303)06C0M1132180303)07K0M1132260303)08C0M2126040303)
09C0 1117040201PNR:)0BC0 1121040201)0CC0
1121130201)0EC0M1054040303)0FC0M1061051006)11C0M1054380201)12C0M2067370303)13C0M1072050303)14C0M1
081051006)15S0M1092010251)16C0M1072380201)17C0M2088370303)18S0M1071010251)19C0M4080360202)1AC0M20
79390504)1BC0M1093050303)1CC0M1101051006)1DS0M1115010751)1EC0M1093380201)1FC0M2111370303)20C0M410
3360202)21C0M2100390504)22C0M1112050201)23S0M3053330262)29C0 5491500303=05)2AC0
5491340303=06)2BK0 5491250303=07)3FC0 1009130201=05)40C0 1009250201=06)41K0 1009320201=07)42C0
1021130201=05)43C0 1021250201=06)44K0 1021320201=07)E9C0M2152020303)EDC0 5369490201)EEC0
5369370201)EFC0 5373490201)F0C0 5369260201)F1C0 1117390201)F2C0 5481500303)F3C0
5485500201=0B)F4C0 5485410201=0C)F5S0M1053010251)</ns2:BagTagTemplate>
<ns2:BagTagPrintStream>BTP010001)010074605319)050074)06KL)07605319)08021)09F2QHBU)0BNME:)0CADDIN
K)1BKL1615)1CIST)1E29APR)22ISTANBUL)ED29APR)EEKL/SS)EFSSDOPAM)F0AMS)F1
1)F229APR)</ns2:BagTagPrintStream>
</ns2:PECTABData>
</ns2:ResultData>
</ns2:GetBagTagReply>
</S:Body>
</S:Envelope>
Example with BagTagData:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-
open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
<S:Header/>
<S:Body>
<ns2:GetBagTagReply xmlns="http://www.iata.org/IATA/2007/00"
<ns2:Result>
</ns2:Result>
<ns2:ResultData>
<ns2:BagTagData>
<ns2:PassengerName>Jansansen</ns2:PassengerName>
<ns2:PNRCode>DAHRY7</ns2:PNRCode>
<ns2:CheckinSequenceNumber>152</ns2:CheckinSequenceNumber>
<ns2:BagTagIDs>
<ns2:BagTagID>000002</ns2:BagTagID>
</ns2:BagTagIDs>
<ns2:IssuingOperatingAirline ns2:IATA2="XH"
ns2:IATA3="XH">0000</ns2:IssuingOperatingAirline>
<ns2:DestinationsOnTag>
<ns2:Destination>
<ns2:IATAAirport>BCN</ns2:IATAAirport>
<ns2:FlightNumber>OR0367</ns2:FlightNumber>

<ns2:DepartureDate>2012-02-09</ns2:DepartureDate>
</ns2:Destination>
<ns2:Destination>
<ns2:IATAAirport>LHR</ns2:IATAAirport>
<ns2:FlightNumber>KL4725</ns2:FlightNumber>
<ns2:DepartureDate>2012-02-20+01:00</ns2:DepartureDate>
</ns2:Destination>
</ns2:DestinationsOnTag>
</ns2:BagTagData>
</ns2:ResultData>
</ns2:GetBagTagReply>
</S:Body>
</S:Envelope>
5.4. Commit Bag Tag method

5.4.1. Message: CommitBagTagRequest
The CommitBagTagRequest message contains information about the passenger flight, the bag tag id and
the final baggage measurements. This information is used to look up a bag tag of a passenger and
commit it in the DCS. Figure 8 shows the GetBagTagRequest message and Table 6 describes the
elements and attributes.
Figure 8 - CommitBagTagRequest message


Type Required
Flight Required
FlightNumber String Required The Flight number, for example: KL2535 or

OR2347
ScheduleDate Date Required The date on which the flight is scheduled to

depart.
OperatingCarrier String Required IATA 2 or 3 letter code for the operating Carrier as
specified on the boarding pass, for example KL or
EZY

paragraph.
Bag Required Container for information about the bag
Bag/@BagTagID String Required The unique ID of a bag tag following the IATA
licence plate coding
Measurements Container for the measurements of a bag
Measurements /Dimensions Optional Container for the dimensions of a bag
Measurements /Dimensions/ Decimal Required Height of the bag in centimetres

BagHeight
Measurements /Dimensions/ Decimal Required Length of bag centimetres

BagLenght
Measurements /Dimensions Decimal Required Width of bag centimetres

/BagWidth
Measurements /WeightOfBag Decimal Required Weight of the bag in kilograms.
Table 6 - Elements and attributes of CommitBagTagRequest
Example:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:typ="http://service.acris.aci.aero/baggagecheckinservice/types"
xmlns:ns="http://www.iata.org/IATA/2007/00">
<soapenv:Header/>
<soapenv:Body>
<typ:CommitBagTagRequest>
<typ:Flight>
<typ:FligthNumber>KL7346</typ:FligthNumber>
<typ:ScheduleDate>2011-12-16</typ:ScheduleDate>
<typ:OperatingCarrier>KL</typ:OperatingCarrier>
</typ:Flight>
<typ:UniqueIdOfAirline>12345123451234</typ:UniqueIdOfAirline>
<typ:Bag typ:BagTagID="0074234151234234">
<typ:Measurements>
<typ:WeightOfBag>12.4</typ:WeightOfBag>
</typ:Measurements>
</typ:Bag>
</typ:CommitBagTagRequest>
</soapenv:Body>
</soapenv:Envelope>

5.4.2. Message: CommitBagTagReply

The CommitBagTagReply message contains only a result object. No response is expected back from the
DCS except if the action was successful or not. The ActionSuccesful indicator is true when the bag tag is
committed successful. When the ActionSuccesful indicator is false there was an error while committing the
bag tag and the error messages can be found in the ErrorMessages element. Figure 9 shows the
CommitBagTagReply message.
Figure 9 - CommitBagTagReply message
Exampe:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:CommitBagTagReply xmlns="http://www.iata.org/IATA/2007/00"
<ns2:Result>
</ns2:Result>
</ns2:CommitBagTagReply>
</S:Body>
</S:Envelope>

6. Error handling
This chapter describes the error codes returned by the baggage check-in service. Each DCS
can have its own error codes. These error codes needs to be translated to the error codes
defined in this chapter. This enables the client to uniformly interpret the error codes, regardless
of source and act accordingly. The error messages are not standardized. It is recommended to
return the original messages from the source, so no meaning of the error message is lost. Error
messages can differ depending on the DCS or in which part of the service the error has been
encountered. It is not guaranteed that the error message will always be the same.
Please note that not all errors are thrown by all DCS. It can be the case that a DCS only throw 5
out of 20 defined errors. For example if an airline does allow staff travelers to drop of baggage at
an SSDOP it makes no sense that it would throw an error indicating “Staff travelers not allowed.”
The client should be able to handle all defined errors in all service calls.
The service also returns SOAP Faults and HTTP errors, which have not got error codes. SOAP
faults are thrown when an error occurs in the service framework, before the message is received
by the business logic. This is because there usually is a default way of handling infrastructure
errors like invalid XML or WS-Security. HTTP errors are given when for example the server is
found. When SOAP Faults or HTTP errors occur the transaction should be aborted.
Errors in the result object are only returned if the ActionsSuccessful field in the result is false,
therefore the transaction should be aborted.
The TEC_ prefix is for technical errors

Error Name Description Example message
Code
TEC_00 Unknown error The cause of the error is unknown and will Unknown Error.
01 remain unknown.
TEC Unmapped error Unmapped error. The error is not mapped yet
_0002 and should be mapped. If the error is actually
unknown, but mapped it will get the code
ASB_0001
TEC Required field is A required field is missing or sent empty. This is Required field UniquePaxID
_0003 missing usually the case when an optional field is not is missing
sent but required for the handling of a specific
airline. So the XML is valid, but the content
misses crucial information.
TEC Data is not parsable The received data could not be parsed Field AmountOfSuitcases is
_0004 not a parsable int
TEC Data is not correct The received data could be parsed but is Amount of tags does not
_0005 incorrect or does not make sense. For example match. Requested: 4. In
a flight date that is 10 years in the past or there stream: 2
is a difference in the amount of requested tags
and the returned tags.


Code
TEC Airline not supported The given airline/operating carrier is not Could not find service
_0006 supported by the baggage check-in service. handler for airline HV
TEC Web service A technical error has occurred in invoking the Client ID is not allowed or
_0007 Invocation Error airline web services, like authentication or departure station is not
connection issues. allowed. Please review the
message for more details.
TEC Operation Not Operation not supported for airline. This can be
_0008 Supported the case if for example the airline does not
support payment and the payment operation is
invoked.
The DCS_ prefix is for functional DCS errors

Code
DCS_0001 Pax Not Found The passenger or his reservation has

not been found in the DCS
DCS_0002 Flight not Found The flight for the passenger has not
been found.
DCS_0003 Destination Not Baggage drop-off is not allowed for the

Allowed destination on the SSDOP. Example:
Flights to Atlanta require additional
labelling at time of writing, so may not
be handled at the SSDOP.
DCS_0004 Staff not allowed Staff travelers are not allowed to drop
off luggage at the SSDOP.
DCS_0005 Not checked in Passenger is found, but not checked in.
DCS_0006 Flight not open The flight is not open yet for baggage
drop-off.
DCS_0007 No single flight Passenger does not have a single flight,

so it cannot be determined for which
flight the bags are going to be dropped
DCS_0008 No valid seat Passenger does not have a valid seat.
DCS_0009 Baggage already Passenger has already checked in

dropped baggage and is not allowed to check in
more luggage.
DCS_0010 BagTag not The bag tag could not be retrieved from Printing of bag tag is denied or bag
retrieved the DCS. tag could not be created.
DCS_0011 Max Weight Maximum weight is exceeded for the

Exceeded passenger

DCS_0012 API incomplete The passenger Advance Passenger

Information (API) is incomplete.
DCS_0013 Intentionally left Not used for now, will be replaced in

blank future version.
DCS_0014 Multiple Multiple matches found for the

Passengers Found passenger in the DCS and the service
was not able to identify the passenger
uniquely.
DCS_0015 Pax marked for Passenger is marked for additional

additional checks checks by airline staff. For example a
passenger has an Amber or Red status
for ICTS or needs his/her visa checked.
DCS_0016 Error committing There was an error at the final commit At final commit it is detected that a tag
bag and the bag could not be checked in. has been already committed.

ACRIS Service Definition-Baggage Check-In Draft v09

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ACRIS Service Definition-Baggage Check-In Draft v09

Загружено:

Авторское право:

Доступные форматы

ACI AIRPORT COMMUNITY

BAGGAGE CHECK-IN SERVICE

An ACI World Airport IT Standing Committee initiative

Draft version 0.9

ACI ACRIS Service ID

Service Name Baggage Check-in Service

Version number 0.9

Release Date : 2012-05-04

Status : Ready for presentation to ACRIS community

Version Date Description Author

0.1 2 May 2012 Initial draft Arie van der Veek

ACI WORLD AIRPORT IT STANDING COMMITTEE 2/36 Draft v.0.9 - 20120504

ACI WORLD AIRPORT IT STANDING COMMITTEE 3/36 Draft v.0.9 - 20120504

Abbreviations and Definitions

ACI WORLD AIRPORT IT STANDING COMMITTEE 4/36 Draft v.0.9 - 20120504

ACI WORLD AIRPORT IT STANDING COMMITTEE 5/36 Draft v.0.9 - 20120504

 Get a bag tag from the DCS

ACI WORLD AIRPORT IT STANDING COMMITTEE 6/36 Draft v.0.9 - 20120504

Figure 1 - Example application of the Baggage Check-in Service

ACI WORLD AIRPORT IT STANDING COMMITTEE 7/36 Draft v.0.9 - 20120504

Level 1 requirements are externalized as they apply to all ACRIS services.

2.1. Level 2 requirements – (Non-) functional requirements for all

2.2. Level 3 requirements - (Non-) functional requirements for specific

ACI WORLD AIRPORT IT STANDING COMMITTEE 8/36 Draft v.0.9 - 20120504

An active tag in the hands of a passenger can be put on another suitcase

ACI WORLD AIRPORT IT STANDING COMMITTEE 9/36 Draft v.0.9 - 20120504

Passport is another identification token that every passenger needs to

ACI WORLD AIRPORT IT STANDING COMMITTEE 10/36 Draft v.0.9 - 20120504

If we do not make the change we exclude a significant portion of potential

ACI WORLD AIRPORT IT STANDING COMMITTEE 11/36 Draft v.0.9 - 20120504

Decision Introduce the field OperatingAirline and BrandingAirline

The BrandingAirline field indicates to which airline the solution should be

4.1. Business Object

ACI WORLD AIRPORT IT STANDING COMMITTEE 12/36 Draft v.0.9 - 20120504

4.2. Static View

4.3. Dynamic View

ACI WORLD AIRPORT IT STANDING COMMITTEE 13/36 Draft v.0.9 - 20120504

5. Definition of message structure

5.1. Common data structures

ACI WORLD AIRPORT IT STANDING COMMITTEE 14/36 Draft v.0.9 - 20120504

Figure 2 - BCBP data structure

ACI WORLD AIRPORT IT STANDING COMMITTEE 15/36 Draft v.0.9 - 20120504

Field Tag Name XML Data Option or Option or Description

Example of the structure with one segment:

ACI WORLD AIRPORT IT STANDING COMMITTEE 16/36 Draft v.0.9 - 20120504

5.1.2. UniqueIdOfAirline element

5.1.3. Result data structure

ACI WORLD AIRPORT IT STANDING COMMITTEE 17/36 Draft v.0.9 - 20120504

Figure 3 - Result data structure

Field Tag Name XML Data Option or Description

Result /InfoMessages Optional Container for information messages. Will only

Result /InfoMessages/Message String Required Human readable information message. There

Result String Optional Code that represents the human readable

Result / ErrorMessages Optional Container for error messages. Will only be

Result /ErrorMessages/Message String required Human readable information message. There

Table 2 - Elements and Attributes of Result

ACI WORLD AIRPORT IT STANDING COMMITTEE 18/36 Draft v.0.9 - 20120504

5.2. Identify Passenger method

Figure 4 - IdentifyPassengerRequest Message Structure

ACI WORLD AIRPORT IT STANDING COMMITTEE 19/36 Draft v.0.9 - 20120504

5.2.2. Message: IdentifyPassengerReply

ACI WORLD AIRPORT IT STANDING COMMITTEE 20/36 Draft v.0.9 - 20120504

Figure 5 - IndetifyPassengerReply message structure.