TRANSPORT&LOGISTICS SERVICES INTEGRATION

INDUSTRY SOLUTION

At a time, when fuel prices have reached 30% of operating expenses for an average airline, there is no financial buffer room for an error in the schedule. At a time when personnel costs are a key factor in almost any industry, there is no room for crews to sit on stand-by or for people to wait while a vehicle or train goes through unscheduled maintenance. With customer satisfaction a key differentiator, proactive communication is a necessity, whether that means letting customers know where orders and packages are in the process or that their bag did not make their flight and how you will rectify the situation.

TRANSPORT & LOGISTICS INDUSTRY IT CHALLENGE

Myths endorsed by current process-driven Integration solutions

Reality: The Message-Driven ESB Effect

Adding a new service takes 2-4 weeks Zero-latency service modifications enabled by re-usability of message-driven Services

‘Certified Delivery’ of messages consumes valuable networking bandwidth

Peer-to-peer data transport obviates any penalties of networking bandwidth

Process changes necessitate service downtime and hence lost productivity

Dynamic service replacements without downtimes – no productivity disruptions

typically tied to particular platforms - Java or Microsoft’s .NET

Standards-based, interoperable with either Java or .NET platforms

Expensive solutions, often over $1,000,000

Equivalent benefits at a fractional cost, typically less than $200,000

MESSAGE-DRIVEN SOA

Flight data files need to be uploaded into their Flight Data Management applications, for every flight that lands and takes off at terminals.

These data files get saved to a file system from the flight computer as it gets hooked on to a loading gate, and also sent through emails and IBM MQSeries.

Each file needs to be transformed into a generic format, validated (which involves database lookup and other custom rules), enriched before its pushed into the target application.

SUBSET OF THE BUSINESS PROBLEM FOR ANALYSIS

Handling Crew Assignment Messages

contains details about the crew members allocated to a particular flight, such as name and contact information (e.g. address, phone number), qualifications, crew employer, start of duty information (e.g. time, airport), and flight specifications.

Each message needs to be transformed into a generic format, validated (which involves database lookup and other custom rules), enriched before its pushed into the one or more target application

SUBSET OF THE BUSINESS PROBLEM FOR ANALYSIS

Current solution suffers from the following issues, leading to delays in flight schedules.

• Data loss without a trace• limited visibility into the flow details. [for e.g parsing the positional

CPM data is a black box, its compiled code]• debugging is limited to log files• lack of error notification mechanism• Inherent performance issues - the flow is developed such it does

not scale simply by throwing in more hardware• For the business - IBM CrossWorlds/InterChange Server product

reached end of life -> meaning extra money on support.

PROBLEMS WITH CURRENT SOLUTION

SUBSET OF THE BUSINESS PROBLEM FOR THE POC

FIORANO SOLUTION–CAM MESSAGE FLOW (FILE)

FIORANO SOLUTION–CAM MESSAGE FLOW (XML)

STEP 1: RECEIVE CAM MESSAGES

CAM Messages come in 2 formats. Unsplit Flatfile format dropped into a specific directory in the file system and split XML CAM messages send on a queue in MQseries.

File Reader component picks up CAM messages from the filesystem and MQSeries component reads the CAM messages from MQseries queue.

File Reader

STEP 2: SPLIT CAM MESSAGE

CAMSplitter identifies flat file CAM messages in groups based on pre-determined criteria and split them into multiple such grouped

messages.

File Reader

STEP 3: GATE KEEPER PROCESSING

The XSLT component generates the UTC timestamp, determines the key information and creates a message envelope for the XML CAM messages.

This is done by Javascirpt component for the flat file CAM messages. Sequencing of the CAM messages is now performed by the Sequencer component for both the type of CAM messages.

File Reader

The flat file CAM messages are parsed using CAMParser, vaidated using CAMValidator and transformed using CAMTransformer components.

Similar parsing, validating and transformation is done using XSLT component for XML CAM messages.

STEP 4: PARSING AND CREATING CANONICAL XML

File Reader

A given CAM message may need to be routed to different destinations based on business rules determined dynamically.

The rules are injected to the DynamicCBR component that will apply the rule to the incoming CAM message. Based on the rule the DynamicCBR routes the CAM message to one or more destinations.

STEP 5: DESTINATION LOOKUP

File Reader

The CAM message that needs to be routed to the target destination is transformed to target format using the XSLT component

STEP 6: OUTPUT TRANSFORMATION

File Reader

Flatfile CAM messages are written to a target directory using FileWriter component and XML CAM is written to target queue on MQseies using MQseries component.

The sequencer needs to be notified about the completion of processing so that the next message in the corresponding group can be made available for processing.

STEP 7: DISPATCH TO TARGET SYSTEMS

File Reader

Reliability Transactional visibility Ease of use – lesser time to build the flows Cost of deployment

WHY FIORANO

Reliable data transfer – 100% guaranteed delivery Greater transactional visibility

• Runtime changes and debugging in one view Data and process high availability without the need for centralized

database Lesser time to develop the flows (Because of the Tools and the

Prebuilt components)• Ability to easily debug the flow of distributed events across multiple service

components• Ability to adapt to change dynamically

Separation of flow log and system log Equal citizen status to multiple programming languages

BENEFITS WITH FIORANO SOA PLATFORM

THANK YOU!

VISIT WWW.FIORANO.COM