ServiceGrid Article - Step Guide Metro Pull

From DocWiki

Jump to: navigation, search

Contents

Overview

Pulling valid SOAP messages

Pulling data in the SOAP message format can be used, if the connection partner provides a web service that can be called. It should be used if the connection partner is not able to push information updates immediately to ServiceGrid but provides messages in SOAP format.

Configure the Service Definition

Create a new Service Definition

You can find the "create new service definition" under SD.basicdata > MyCompany > Servicedefinitions > Create new Service Definition.

Insert the service definition's master data

  1. Insert the ShortName and the Name of the service definition. To follow the naming conventions to use unique names, give this service definition the short name 'SGdPullInbSd' and the name 'Setup Guide Pull Inbound Service Definition'.
  2. The service definition's type is 'WebServicePullSoap'.
  3. The field URL is optional in our current configuration. When having a value, it overrides the endpoint URL that is given in the WSDL code.
  4. UserName and Password can be entered to avoid unfolding secure passwords. How these values can be used will be described in the section specialties.
  5. As already mentioned, this type of communication is used when the connection partner provides a web service for pulling messages. In the text area "WsdlCode", we insert the connection partner's WSDL.
  6. WsPullMessage contains the message that is sent to the above stated URL for the request.
  7. Save the inserted data.


As a sample for the WsdlCode, we insert the wsdl of the Core Callservice here:

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/" name="CallServiceService" targetnamespace="urn:ws.solvedirect.com/webservices/custom" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="urn:ws.solvedirect.com/webservices/custom" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> 
<types>
  <xsd:schema>
      <xsd:import schemalocation="http://localhost:8080/ws/soap/custom/CallService?xsd=1" namespace="urn:ws.solvedirect.com/webservices/custom">
  </xsd:import></xsd:schema>
</types>
<message name="putCall">
  <part name="parameters" element="tns:putCall"></part>
</message>
<message name="putCallResponse">
  <part name="parameters" element="tns:putCallResponse"></part>
</message>
<message name="SDWebServiceException">
  <part name="fault" element="tns:SDWebServiceException"></part>
</message>
<message name="getCall">
  <part name="parameters" element="tns:getCall"></part>
</message>
<message name="getCallResponse">
  <part name="parameters" element="tns:getCallResponse"></part>
</message>
<porttype name="CallService">
  <operation name="putCall">
      <input type="text" wsam:action="urn:ws.solvedirect.com/webservices/custom:CallService:putCallRequest" message="tns:putCall">
      <output wsam:action="urn:ws.solvedirect.com/webservices/custom:CallService:putCallResponse" message="tns:putCallResponse">
      <fault name="SDWebServiceException" wsam:action="urn:ws.solvedirect.com/webservices/custom:CallService:putCall:Fault:SDWebServiceException" message="tns:SDWebServiceException">
  </fault></output></operation>
  <operation name="getCall">
      <input type="text" wsam:action="urn:ws.solvedirect.com/webservices/custom:CallService:getCallRequest" message="tns:getCall">
      <output wsam:action="urn:ws.solvedirect.com/webservices/custom:CallService:getCallResponse" message="tns:getCallResponse">
      <fault name="SDWebServiceException" wsam:action="urn:ws.solvedirect.com/webservices/custom:CallService:getCall:Fault:SDWebServiceException" message="tns:SDWebServiceException">
  </fault></output></operation>
</porttype>
<binding type="tns:CallService" name="CallServicePortBinding">
  <soap:binding transport="http://schemas.xmlsoap.org/soap/http">
  <operation name="putCall">
      <soap:operation soapaction=""></soap:operation>
      <input type="text">
          <soap:body use="literal"></soap:body>
       
      <output>
          <soap:body use="literal"></soap:body>
      </output>
      <fault name="SDWebServiceException">
          <soap:fault name="SDWebServiceException" use="literal"></soap:fault>
      </fault>
  </operation>
  <operation name="getCall">
      <soap:operation soapaction=""></soap:operation>
      <input type="text">
          <soap:body use="literal"></soap:body>
       
      <output>
          <soap:body use="literal"></soap:body>
      </output>
      <fault name="SDWebServiceException">
          <soap:fault name="SDWebServiceException" use="literal"></soap:fault>
      </fault>
  </operation>
</soap:binding></binding>
<service name="CallServiceService">
  <port name="CallServicePort" binding="tns:CallServicePortBinding">
      <soap:address location="https://ws.solvedirect.com/ws/soap/core/CallService">
  </soap:address></port>
</service>
</definitions>


The WsPullMessage must be a valid and well-formed SDSoapMessage to be used for WebServicePullSoap. A sample SDSoapMessage has the following format:


<sdsoapmessage>   
<servicename>CallServiceService</servicename>
<portname>CallServicePort</portname>
<servicenamespaceuri>CallServiceService</servicenamespaceuri>
<portnamespaceuri>CallServiceService</portnamespaceuri>
<soapaction>
  <uri>CallServiceService</uri>
</soapaction>
<soapoperation>
  <messagebody>
      <username>d3adm</username>
      <password>******</password>
  </messagebody>
  <name>getCall</name>
  <namespaceuri>urn:ws.solvedirect.com/broker</namespaceuri>
  <responseelementname>getCallResponse</responseelementname>
  <responseelementnamespaceuri>urn:ws.solvedirect.com/broker</responseelementnamespaceuri>
</soapoperation>
</sdsoapmessage>


When you take a look at the SDSoapMessage, you will see that a number of tags are already defined in the WSDL. SDSoapMessage gives the user the possibility to override the values from the WSDL code. This means that nearly all tags are optional. The tallest possible SDSoapMessage contains the mandatory tags SDSoapMessage, SOAPOperation, MessageBody and Name. SDSoapMessage and SOAPOperation are parent tags. Name contains the operation that will be actually called and MessageBody contains the content that will be pushed to the connection partner's web service. The minimal configuration for the above mentioned SDSoapMessage in combination with Core Callservice is


<sdsoapmessage>
<soapoperation>
  <name>getCall</name>
  <messagebody>
      <username>${servicedefinition.username}</username>
      <password>${servicedefinition.password}</password>
  </messagebody>
</soapoperation>
</sdsoapmessage>


Pulling HTTP messages

Pulling simple HTTP messages can be used, whenever the connection partner does not provide the structural exchange of messages using web services but only simple endpoints. For a more detailed information of what can be "pulled", again a service definition is used.


Configure the Service Definition

Create a new Service Definition

You can find the "create new service definition" under SD.basicdata > MyCompany > Servicedefinitions > Create new Service Definition

Insert the service definition's master data

  1. Insert the ShortName and the Name of the service definition. To follow the naming conventions to use unique names, give this service definition the short name 'SGdPullIbHSd' and the name 'Setup Guide Pull Inbound HTTP Service Definition'.
  2. The service definition's type is 'WebServicePullHttp'.
  3. The field URL is mandatory in our current configuration. In this sample, we are inserting the URL of the Direct Servlet, namely 'https://ws.solvedirect.com/ws/distinct/HTTPDirectServlet?action=getCalls'.
  4. UserName and Password can be entered to avoid unfolding secure passwords. How these values can be used will be described in the section specialties.
  5. WsPullMessage contains the message that is sent to the above stated URL for the request.
  6. Saved the inserted data.

A sample SDHttpMessage XML is detailed as follows. Due to technical difficulties, the case sensitive Message has lost the upper and lowercase information.

<sdhttpmessage> 
<charset>UTF-8</charset>                               
<headers>                                              
<parameter name="Connection">keep-alive</parameter>
</headers>
<message>                                          




<element1>Content1</element1>
<element2>Content2</element2>
</message>
</sdhttpmessage> 


Configure the Communication

Create a new Inbound Communication

  1. You can find the "New Communication" under SD.basicdata > MessageRules > All Communications > Create new inbound Communication.
  2. Select the converter and communication type.Converter can be "SD.xml 2.0-SDStandardXML 2.0" (depends on whether the connection partner provides the message in ServiceGrid namespace or not). CommunicationType is "WS.pull-WebService REST/SOAP pull".
  3. Click Next to go to the next screen.
  4. To finish the basic creation of the communication, enter the master data
  5. Give the  communication a ShortName and a Name. In this example, 'SGdPullInbCo' is given for the short name and 'Setup Guide Pull Inbound Communication' is given for the name .
  6. Click Save to finish the creation.


To connect the earlier created service definition with the communication,

  1. Click on the function "Add new sender" in the communication senders sections.

Enter the master data for the receiver.The type must be 'Make Request-WebService REST/SOAP pull'. For the ServiceDefinitionName, the application provides a list view, where you can select the desired service definition. In this example we select the before created service definition 'SGdPullInbSd'
Finally again we have to save the modification we've made


Connect Communication and Trigger

For a pull communication, you need an Inbound Trigger. How this trigger is created can be found here:

Response Filters

It is possible to set action to specific type of responses. A detailed description can be found at ResponseFilters.

Template Macros: Specialties for the template

Quite often, the customer has to face the requirement to ensure simple security standards like hiding passwords. For this, you will find a high potential that the service's requester must authenticate and the application provides two macros for support: ${servicedefinition.username} ${servicedefinition.password}.

These macros can be used before sending the message to the connection partner and the macros are replaced by the value from the ServiceDefinition that is used for the communication.

NOTE: Even if the macro is used and it is translated before sending the message, different screens providing a view of the message content will not show the translated value.

Basic Authentication

For each service definition, a username and a password can be entered. These values are used for basic authentication. This works for SDSoapMessage as well as for SDHttpMessage. This means that there is an automatically added header with the name Authorization to the request. If there is already a header defined by the tagHeaders (only in SDHttpMessage), it will not be overridden.

Restrictions

URL for SDHttpMessage: The URL that is given in the ServiceDefinition for SDHttpMessages must start with "http" ("https" is also a valid URL). Customer needs certificate(s) for secure communication. Whenever the user needs any certificates or handshakes for a seamless communication over SSL, TOP has to be involved.




For a complete list of Cisco ServiceGrid Articles, go to the List of Articles page.



Rating: 0.0/5 (0 votes cast)

Personal tools