anatomy of ebonding
TRANSCRIPT
Anatomy of a 2 way eBonding Integration
Welcome to FruDevCon 2014!
• Background
• Previous Integrations Team Lead w/ FP
• Software developer background
• UMass Comp Sci Major
• Lives in Boston, MA
• Enjoys playing bass guitar, electronics, hack-a-thons,
motorcycles, traveling and currently learning
PortuguesePaul SenatillakaSenior Developer @ [email protected]
Agenda
• eBonding?
• Thinking about synced data
• Architecture
• Components
• Code Walkthrough
• Logging
• Retry Logic
eBonding?
• What is an eBonding? Diff between regular Integration?
• A two way data exchange between ticketing systems
• Why eBond?
• Usually to support a legacy ticketing system or extra functionality
• Common eBondings: Incident, Request, Change with tools
like:
1. HPSX (HP Service Manager, HP Digital Workstation)
2. Verizon eBonding
3. Unisys (Remedy)
4. CA Spectrum*
4 Tuesday, March 10, 2015
Thinking about synced data
• Correlation ID - Ticket # in external system
• State Field – Careful consideration as this
usually drives the workflow of tickets and states
might not match.
• Trigger Field – What identifies to eBond Ticket
• Reference Fields – Careful with these as well.
Ensure reference table data exists or sync over
display data instead of Reference Sys IDs.
5 Tuesday, March 10, 2015
Thinking about synced data
6 Tuesday, March 10, 2015
• Group new fields together from 3rd Party System so you don’t confuse it with SN sourced data.
• Complete Data Mappings & before writing any code!!! What data and which directions?
SN Field Extern Field Type Required Direction Translation Required?
state status string Y SN Out Yes
• Identify what field triggers and deactivates the eBonding. What fields have to be set for a ticket to be eBonded?
Architecture
7 Tuesday, March 10, 2015
Logical Components
Architecture
8 Tuesday, March 10, 2015
Asynchronous Transactions Common Transaction Types• Insert • Update• Close• Fault / Error
Why Asynchronous instead of Synchronous?• Can allow for a higher volume of traffic. Data is queued
up and processed when system has availability.
Architecture
• In these particular eBondings with HP, Verizon, and Unisys,
one SOAP WS Function was used for all transactions.
Transaction type was a parameter rather then a separate
SOAP function.
• We also implemented the same WS Interface (WSDL) in our
scripted WS as the external software’s WS. This saved
development time for them.
9 Tuesday, March 10, 2015
Components
Lets walk through each
component!
• Properties Page
• Inbound WS
• Scripted WS, Static WSDL, Script Include
• Outbound WS Client
• Business Rules, Script Include
• Logging
• Retry Policy
10 Tuesday, March 10, 2015
Sample SOAP Message
11 Tuesday, March 10, 2015
Code Walkthrough
• Lets look at all these pieces in a real instance!
12 Tuesday, March 10, 2015
Logging
• Outbound logging will be accomplished because of
ECC Queue. We will get a outbound message and
response from WS logged.
13 Tuesday, March 10, 2015
• We will need to setup a new table and code for inbound logging because we are using a Scripted Web Service.
Retry Logic
• With Retry Policy Plugin and because we are
using the ECC Queue we can have retry logic
defined.
• If retry fails X number of times, what should we
do? Open a Incident ticket or send an alert email
14 Tuesday, March 10, 2015
Anatomy of a 2 Way eBond
Q & A
15 Tuesday, March 10, 2015
