Dariusz Szybowski, Aspediens Director of Technology, held this presentation at the Knowledge11, ServiceNow’s user conference taking place in Frankfurt. He discussed cases that we have achieved to date on how to integrate with SAP solution manager.

1. SAP Integration
Dariusz Szybowski
Director of Technology
Aspediens

2. Agenda
• SAP Integration Overview
• Functional requirements
• Technical aspects
• Implementation approach
• Examples
• Q/A session

3. Aspediens
• European Partner of ServiceNow since 2007
• 100% dedicated to ServiceNow implementation
• Offices in Paris, Geneva, Zurich
• 25+ ITIL certified professionals dedicated to ServiceNow
• 30+ customers, including international companies
• 60+ implementations to date
• Top EMEA Partner 2011 award
• Authorized Training Partner

4. Aspediens – our services
Consulting Training Academy Out-Tasking
Implementation Partner Education Partner Delegation Partner
•Solution Design •Standard Admin (exam) •Virtual administrator
• Configuration and Scripting • Advanced Scripting Training • Release management
• 3rd party tool integration • Service Request Catalog • Managed services
• Business Process • A la carte
Automation

5. SAP Integration Overview
• SAP – ERP system covering all aspects of
business
• SSM – SAP Solution Manager
– Support Messages created directly from SAP UI
– Link with SAP Support System
– SAP Development/Customizations management
• Existing Service Desk WebService API
– Exhaustive and complex but Incidents oriented

6. Agenda
• SAP Integration Overview
• Functional requirements
• Technical aspects
• Implementation approach
• Examples
• Q/A session

7. Functional requirements
Incidents - unidirectional
• SNC – main ITSM company system
• SAP Support Message via SAP GUI +
attachments
• ServiceNow Incident creation + attachments
• Incident lifecycle in ServiceNow

8. Functional requirements
Change/Change Tasks - bidirectional
• Change for SAP Business Service
• Workflow driven
• Change Task business rule creates SAP Support
Message
• Attachments
• SAPupdates the status field in SN Change
• Closure

9. Functional requirements
Problems - bidirectional
• Problem on SAP Business Service
• Manual action of CS L2 to pass it to CS L3
(SAP)
• Update from SAP to SN with resolution only.

10. Functional requirements
SAP HCM System - user provisioning
• User data provisioning from two different sources: AD
and SAP HCM
• AD via LDAP(S) protocol
• HCM as the web service call

11. Agenda
• SAP SSM Integration Overview
• Functional requirements
• Technical aspects
• Implementation approach
• Examples
• Q/A session

12. Technical Constrains
• Connectivity
– Peer-to-peervs ESB
– Accesibility by SN Instance
• SOAP Message Format
– complexType (nested structures)
– Imposed tag names
– SN attachment default handling
• Data Treacability (import sets)
• Error Handling (all types)

13. Technology
Only answer - SOAP Web Services
• SAP Systems Side
– ABAP Proxy
– Java Proxy
– SAP PI or Peer-to-Peer
• ServiceNow side
– All Web Service related plugins for pluglishing
– Web Service Consumer plugin
• SOAP Envelop and SOAPMessage objects

14. Interface design best practice
• Data flow Tracking
• Asynchronous exchange
• Object ID exchanged and stored in two systems
• Type Transactions (INSERT, INSACK, ERR, …)
• Use Transaction GUID for the message exchange
• Use the process state matrix if possible
• Error Handling
– Communication, data, process

15. Diagram – implementation example

16. Agenda
• SAP SSM Integration Overview
• Functional requirements
• Technical aspects
• Implementation approach
• Examples
• Q/A session

17. Implementation
Challenges
• High technical complexity
• 3rd parties involvement: you, customer and
SAP specialist (often external)
• Complex integration testing

18. Implementation
Approach
• Separated project inside the main
ServiceNow roll-out
• Careful planning - external systems and
teams availability

19. Implementation
Prerequisites
• Functional design agreed with 3 parties
(Data exchanged, Data mapping
,Transformation, Triggers)
• Assess the SAP specialist skills
– SAP BC specialist is not necessary SAP
Integration specialist
• Agreed Technical Architecture

20. Implementation
Success factors
• Prerequisites
• Strong customer ownership to bring all parties
together
• Anticipate connectivity setup
• Estimate data volumes (SOAP Messages)
• Multiple Integration Testing runs
• Use built-in platforn feature but with optimized
scripting.

21. Agenda
• SAP SSM Integration Overview
• Functional examples
• Technical aspects
• Implementation approach
• Examples
• Q/A session

22. Example 1
• ServiceNow remains the main ITSM application
• Integration on SN Change, with approvals and
validations
• Workflow driven
• SAP SSM used for SAP systems to manage
development and transport
• Asynchronousmessage exchange
• Set of transactions
• Matrix of possible transactions

23. Example 1 Workflow implemented

24. Example 1 Transactions matrix

25. Example 1
Implementation
• Based on System Web Services plug-in
• Attachment sent as a separated WS call
• Process state validation table/function
• Automatically triggered by business rules
• The most advanced on SAP side, the easiest to
implement on ServiceNow side

26. Example 1 - Diagram

27. Example 2
Requirements
• Create the SAP Support Messages directly from
SAP GUI Interface
• Trigger the SAP systems customization
• Follow the SAP implementation process

28. Example 2
Implementation details
• Based on Scripted Web Services
• Up to 5 attachments together with the
main SOAP message
• Automatically triggered by business rules
• Use of sys_import_set_row GlideRecord
• Use of Attachment Object
• Double Transformation Maps

29. Example 2 - Diagram

30. Example 3
Requirements
• Create a Support Request in SAP SSM from a
problem
• Handle the resolution process related in SAP
environment (updates)
• Allow the SSM users to close an existing Support
Request in SSM related to the ServiceNow
Problem

31. Example 3
Technical Constraints
• Predefined Generic SOAP XML message
structure
• Imposed tag names
• ComplexTypestructure
• Possibility to extend the interface beyond
problems

32. Example 3
Implementation
• UI Action to trigger the interface
• Based on Static WSDL Web Services
• Global Business Rule to parse SOAP
message
• Use of sys_import_set_row GlideRecord

33. Example 3 - Diagram

34. Agenda
• SAP SSM Integration Overview
• Functional examples
• Technical aspects
• Implementation approach
• Examples
• Q/A Session

35. Questions?

36. ThankYou
Director of Technology
Dariusz Szybowski
Aspediens SA
dariusz.szybowski@aspediens.com

37. BACKUP SLIDES

38. Aspediens
• European Partner of ServiceNow since 2007
• 100% dedicated to ServiceNow implementation
• Offices in Paris, Geneva, Zurich
• 25+ ITIL certified professionals dedicated to Service-
now.com
• 30+ customers, including international companies
• 60+ implementations to date
• Top EMEA Partner 2011 award
• Authorized Training Partner

39. Aspediens – our services
Consulting Training Academy Out-Tasking
Implementation Partner Education Partner Delegation Partner
•Solution Design •Standard Admin (exam) •Virtual administrator
• Configuration and Scripting • Advanced Scripting Training • Release management
• 3rd party tool integration • Service Request Catalog • Managed services
• Business Process • A la carte
Automation

40. About the speaker
• 25 years in IT
• 7 years in Oracle Technical Consulting
• Used to be Sap BW certified
• Automated Testing
• Software Development on various technologies
(Uniface, Oracle Developer 2000, ServiceNow)

41. SAP Integration Overview
• SSM Support Message management
– can be replaced by Servicenow, including the creation of
SAP Support Messages directly SAP UI
• Link to SAP Support System
– can’t be replaced in this context
• SAP Development/Customizations management
– can’t be replaced for SAP development management
– can be integrated into ServiceNow Change
management processes

42. Technical Constrains
SOAP Message formats
• “complexType” and nested structures of SAP SOAP
Message with changing number of occurrence
• Imposed XML tag names and named spaces
• SAP Difficulties to match ServiceNow naming
conventions
• Attachments are sent in the main message (often)
• Difficulty to support Default ServiceNow Web Service
Response

43. Technical Constrains
Data Traceability
• Use of default ServiceNow Data Import built-in
features
• Possibility to handle the data related errors
• Possibility to apply to the data the complex
validation and transformation treatments

44. Technical Constrains
Error handling
• Connectivity errors
• Inbound data errors
• Third System treatment errors (Transaction
errors)

45. Technology
SOAP Web Services
• ServiceNow – inbound messages
– System Web Services plug-in (1 implementation)
– Scripted Web Services plug-in (1 implementation)
– Static WSDL Web Service ( 1 implementation)
• ServiceNow - outbound messages
– Web Service Consumer
• SOAPEnvelope and SOAPRequest
• SOAPMessage

46. Technical Implementation
Interface Types
• Synchronous (Peer-to-peer)
– Only default Response Message
• Asynchronous (Peer-to-peer and ESB)
– Response Message for connectivity check
– Response Message for WS consumption (successful or
not)
– Separated Acknowledge message sent after successful
transaction

47. Error handling
Event based
• Communication errors
– Sending via ecc_queue
– Use of ECC Queue Retry Policy plugin
• Missing acknowledgment errors
– Schedule job with event creation
• Inbound ERR message
– Included in main script with the event creation
• Import Data errors
– Event created based on status in sys_import_set_row

48. Inbound message
Step by step 1/2
• Format of exchanged SOAP Messages
• Transaction types
• Interface architecture (sync, async)
• ServiceNow Web Service plugins
• Import set table extending sys_import_set_row table (usually via
creation of System WS)
• Specific fields in a destination table for sync and status
• Transform maps and transform scripts

49. Inbound message
Step by step 2/2
• Script
– transform/parse inbound message into the “flat” structure.
– generate appropriate Response Message
– Insertion of the GlideRecord sys_import_set_row into the
import set table.
– Synchronous data transformation.
– Insertion of the GlideRecord into ecc_queue with the
attachment. This can be replaced by user of Attachment
object.
– SOAPClient Business Rule
• Unit test with SOAP UI or equivalent tool

50. Outbound message
Step by step
• Logical conditions to
– trigger the SAP Interface first call
– Generate acknowledge message (in script or Business Rule)
• System properties with Endpoints, users/password to
consume the SAP Web Services
• Consume the SAP WS via SOAP Message object
• Scripting using SOAPEnvelope and SOAPRequest the
outbound complex SOAP messages
• Use asynchronous sending via ecc_queue

51. Example 1
Technical details
• Asynchronousmessage exchange
• Messages with Transaction Code
• Matrix with possible status changes
• In Change (SN) dedicated field for “SAP
Implementation Status”, read-only for UI
• Interface modifies the value of this field
• Three workflows: Minor, Major, Emergency
• Two workflow activities: “Set Value To” & “Wait for”

52. Example 1 Workflow design

53. Example 1
Transactions - Messages

54. Example 2
Create Incident Interface
1. SAP Support Message is created in SAP SSM
2. The created message is immediately transferred to SNC as
a new Incident with the attachments if any – inbound 1.
3. The SNC Incident number is sent back as the
acknowledgment of creation – outbound 1.
4. The SNC number is put into “External Reference” and the
SAP Support Message is setup as “confirmed” (closed)

55. Example 2
Change Request Interface
1. SAP Support Message is created in SAP SSM
2. The created message is immediately transferred to SNC as
a new Incident with the attachments if any – inbound 1.
3. The SNC Incident number is sent back as the
acknowledgment of creation – outbound 1.
4. The SNC number is put into “External Reference” and the
SAP Support Message is setup as “confirmed” (closed)

56. Example 3
Technical Details
• 3 Types of transactions:
– CreateSupportRequest
– UpdateSupportRequest
– CloseSupportRequest
• Can work with the different types of documents
(Incident, Problem, Change, Support Request) in
different system (ServiceNow or SSM)

57. Example 3
CreateSupportRequest - Outbound
1. Call of the interface is triggered manually from the existing
ServiceNow Problem form.
2. SOAP Message is posted to ECC Queue for asynchronous
sending (not blocking).
3. SOAPClient processor reads any pending message in the queue
and attempt to post them to SSM.
4. Request is processed in SSM and a standard response containing
the new document reference is placed back in the ECC Queue.
5. SNC Problem is set to state “Waiting” for “Change result”. The
Problem becomes read-only as the update and closure are now
handled in SSM.

58. Example 3
UpdateSupportRequest - Inbound
1. Problem update request is generated in SSM from
an existing Support Request
2. Call of ServiceNow Web Service for processing.
3. Related Problem is updated with incoming
information
4. The Web Service prepares and sends the
appropriate response to the caller .

59. Example 3
CloseSupportRequest - Inbound
1. Problem closure request is generated in SSM from an existing
Support Request
2. Call of ServiceNow Web Service for processing.
3. Related Problem is updated, state set to “Closed/Resolved” and
Solution is populated.
4. The Web Service prepares and sends the appropriate response to
the caller .