ServiceGrid Article - Workflow Ports
One connection to all internal and external systems (1:n) for accelerated service processes and increased transparency:
Cisco ServiceGrid bridge is integrated into the Cisco ServiceGrid application as a module. It contains a number of functions to implement transaction based connection between Cisco ServiceGrid and service partner systems. The connections methods, transaction types, and transaction content are customizable to fit the requirements of different systems. The design of Cisco ServiceGrid bridge is modulary and consists of a number of available transport methods (SMTP, FTP, HTTPS POST, HTTPS SOAP, Rosettanet, and so on), a flexible layer to customize the transaction content and syntax, and a framewok, to define workflow and transaction types.
Cisco ServiceGrid's bridge is a central hub connected to the service management systems of collaborating service partners. The usage of a central hub is much more efficient than building single point-to-point connections:
- To connect eight systems or service partners directly in a point-to-point mode, up to 56 connections (7 for each systems) have to be built and operated.
- To connect eight systems or service partners through a central hub, only eight connections are neccessary.
Cisco ServiceGrid used as a collaboration hub connecting service partners through an Saas (SD Software as a Service) architecture provides flexible connection methods to bridge service partners, processes and service management systems.
To set up a connection between a service provider and a service customer, it is necessary to define the following:
- the type of communication used and,
- the form of the content communicated.
This is done by selecting a communication type (for example, SMTP, SOAP, FAX) and by selecting the templates used for certain transactions (for example, XML, Name-Value-Pair, or simple text).
Cisco ServiceGrid provides a set of:
- standard communication types and,
- standard templates in the form of XSL transformation templates.
The templates can be changed to individual requirements.
In order to build a clean and efficient connection between your application and Cisco ServiceGrid, we recommend to go through a number of design decisions in a structured way as shown below:
|Task||For more details and samples, go to:|
|Define or describe the transaction types and patterns your process is publishing.||Transaction types and patterns|
|Define the content of each transaction type - the field mapping.||Transaction content - field mapping|
|Decide the used content structure and syntax.||Content structure and syntax|
|Select preferred transport method.||Transport Layer|
|Select preferred network protocol.||Network Layer|
Transaction Types and Workflow Mapping
Service providers and service customers usually have their own workflows. These workflows need to be mapped in order to be able to synchronize call information between different workflows.
CallOpen and CallUpdate
The CallOpen transaction creates calls on the Cisco ServiceGrid platform. Initial call parameters will be set in this transaction, which can be done through inbound-call-message or through the online interface(Cisco ServiceGrid call).
For this transaction, the correct contract and ContractElement have to be specified.
CallUpdate transactions are all further communications between the service provider and service customer. Call updates can be information exchange or workflow exchange depending of the content.
For more details about transaction patterns, refer to the Transaction types and patterns document.
Content of Transactions and Field Mapping
Field mapping means that each available inbound field has to be joined (assigned) with a field from the Cisco ServiceGrid platform on the inbound and outbound side.
Sample field mapping: The service customer is sending a CallOpen to Cisco ServiceGrid.
|Calls.CustCallID||M||The customer's call identification code or number.||varchar||30||4321|
|Contracts.ShortName||O||Short name of the contract between service customer and service provider.||varchar||12||Service|
|ContractElements.ShortName||O||Short name of the ContractElement between service customer and service .provider||varchar||12||SL1|
|Calls.Description||O||The incident description as free text.||Text|| —||Description Text|
|CallStates.ShortName||O||The provider's call status code.||varchar||20||Work External|
For more details about field mapping and more samples, go to: Transaction content - field mapping.
Content Structure and Syntax
An important task is to specify the syntax of the inbound and outbound transactions. The complexity of the implementation of a MessageRule depends on where and how several translations are done. If the communication partner can deliver the call content in XML-Cisco ServiceGrid namespace, the implementation effort will be reduced.
A sample XML Cisco ServiceGrid namespace is as follows:
<?xml version="1.0" encoding="ISO-8859-1"?> <CALL> <Calls.CustCallID>TT4711</Calls.CustCallID> <ContractElements.ShortName>SL1</ContractElements.ShortName> <Contracts.ShortName>Hardware</Contracts.ShortName> <Calls.Remarks>Screen jitters</Calls.Remarks> </CALL>
If the partner cannot deliver or in the worst-case cannot handle XML-contents, the effort will increase.
For inbound transactions, XML-content should be preferred. Through XSLT-scripts, external namespaces can be easily transformed into SD namespaces.
- Easy transformable.
- Deep structures possible.
- Simply calculations at inbound time could be handled.
- Special characters have to be substituded.
- Difficult to read.
Another standard input format is the name= Value-Pair (NVP) format. The namespace is the same as used for the XML format.
- Easy to create for partners.
- Better readablity.
- No structured content could be used.
- ServiceGrid namespace is obligatory.
- Only few fields can handle multiple line content.
Other formats need special handling with individually programmed inbound converters.
With the use of outbound-XSLT transformation, nearly every outbound format can be created.
For more details about syntax and XML, go to: Content structure and syntax
Standard transport protocols
Cisco ServiceGrid provides the following six standard communication types for transaction based communications (used by Cisco ServiceGrid call/bridge):
- HTTPS SOAP
- HTTPS POST
- FAX (only ServiceGrid outbound)
The interactive HTML communication used by the online interface Cisco ServiceGrid call is not part of this document.
Push and Pull Methods
Depending on the transport protocol used, two different methods are available:
- Push or Pull
- Push or Push
Push or Pull
- A service is published by Cisco ServiceGrid for use by the communication partner.
- The communication partner pushes transactions to the server process and pulls transactions actively and periodically from the Cisco ServiceGrid server process.
- In this case, the service partner will be the active part, Cisco ServiceGrid will be the passive part.
- There is no service running on the side of the communication partner.
- This method is typically used with FTP, HTTPS SOAP, and HTTPS POST.
Push or Push
- Both sides, Cisco ServiceGrid and the communication partner, provide a service which is pushed from a client the other side.
- In this case, both sides will be active.
- This method is always used with SMTP and SMS.
- The method may be used with FTP, HTTPS SOAP, and HTTPS POST.
For more details about transport protocols, go to Transport Protocols document.
For more details about the network layer, go to the Network Layer document.
For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.