This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This feature allows users to expose their legacy SOAP backends as REST APIs through WSO2 API Manager. WSO2 API Manager supports WSDL 1.1 based SOAP backends.

The following instructions explain how to generate REST APIs in WSO2 API Manager for an existing SOAP backend.

Before you begin...

Make sure that you have a valid WSDL URL from the SOAP backend. It should belong to the WSDL 1.1 version. 

  1. Sign in to the API Publisher and click ADD NEW API, which is under the API menu.
  2. Select I Have a SOAP Endpoint. You see the following two options to create APIs for SOAP backend.
    • Pass Through – Create a pass through proxy for SOAP requests coming to the API Gateway.
    • Generate REST APIs – This option is used to generate REST API definitions from the given WSDL URL.

    Select WSDL URL to provide a URL for your API. Alternatively, you can upload a WSDL archive/file

  3. Select Generate REST APIs (The default option is Pass Through). Provide the WSDL URL given below for the SOAP backend and click Start Creating

    Sample WSDL URL
    http://ws.cdyne.com/phoneverify/phoneverify.asmx?wsdl


    The Pass Through and Generate REST APIs options that are shown in the following screenshot, which allow you to modify API resources are only available as a WUM update and is effective from 4th October 2018 (2018-10-04). For more information on updating WSO2 API Manager, see Updating WSO2 Products.

  4. Click on Edit Source to edit the Swagger specification of the API.

    The automatically generated REST resources of the API appears.
    You can describe your REST API better by modifying the Open API Specification that you see on this page. The following is a sample of how this particular API has been described.

  5. Optionally, update the Swagger definition of your API and click Apply Changes to save your API.
    Let's update the API by replacing the existing Swagger definition with the following Swagger definition.

     Expand to see the edited Swagger definition...
    swagger: "2.0"
    paths:
      /checkPhoneNumber:
        get:
          operationId: CheckPhoneNumber
          parameters:
            - in: query
              name: PhoneNumber
              required: true
              type: string
            - in: query
              name: LicenceKey
              required: true
              type: string
          responses:
            default:
              description: ""
              schema:
                $ref: "#/definitions/checkPhoneNumberOutput"
          x-wso2-soap:
            soap-action: "http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumber"
            soap-operation: CheckPhoneNumber
            namespace: "http://ws.cdyne.com/PhoneVerify/query"
            x-soap-version: "1.2"
      /checkPhoneNumbers:
        post:
          operationId: CheckPhoneNumbers
          parameters:
            - in: body
              name: Payload
              required: true
              schema:
                $ref: "#/definitions/checkPhoneNumbersInput"
          responses:
            default:
              description: ""
              schema:
                $ref: "#/definitions/checkPhoneNumbersOutput"
          x-wso2-soap:
            soap-action: "http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumbers"
            soap-operation: CheckPhoneNumbers
            namespace: "http://ws.cdyne.com/PhoneVerify/query"
            x-soap-version: "1.2"
    info:
      title: PhoneVerificationAPI
      version: 1.0.0
    definitions:
      checkPhoneNumberInput:
        type: object
        properties:
          CheckPhoneNumber:
            $ref: "#/definitions/CheckPhoneNumber"
      checkPhoneNumberOutput:
        type: object
        properties:
          CheckPhoneNumberResponse:
            $ref: "#/definitions/CheckPhoneNumberResponse"
      checkPhoneNumbersInput:
        type: object
        properties:
          CheckPhoneNumbers:
            $ref: "#/definitions/CheckPhoneNumbers"
      checkPhoneNumbersOutput:
        type: object
        properties:
          CheckPhoneNumbersResponse:
            $ref: "#/definitions/CheckPhoneNumbersResponse"
      StringArray:
        type: string
        properties:
          String:
            type: array
            items:
              type: string
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s
      CheckPhoneNumber:
        type: object
        properties:
          PhoneNumber:
            type: string
          LicenseKey:
            type: string
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s
      CheckPhoneNumbersResponse:
        type: object
        properties:
          CheckPhoneNumbersResult:
            $ref: "#/definitions/ArrayOfPhoneReturn"
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s
      ArrayOfString:
        type: object
        properties:
          string:
            type: array
            items:
              type: string
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s
      ArrayOfPhoneReturn:
        type: object
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s
      CheckPhoneNumbers:
        type: object
        properties:
          PhoneNumbers:
            $ref: "#/definitions/ArrayOfString"
          LicenseKey:
            type: string
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s
      PhoneReturn:
        type: object
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s
      CheckPhoneNumberResponse:
        type: object
        properties:
          CheckPhoneNumberResult:
            $ref: "#/definitions/PhoneReturn"
        xml:
          namespace: "http://www.w3.org/2001/XMLSchema"
          prefix: s

  6. The generated API definitions are added to the API as shown below.

    A REST API method is mapped with the corresponding SOAP operation through a Swagger, vendor-specific field - x-wso2-soap. Note that this should not be edited. A parameter without this field cannot be mapped with a SOAP backend operation.

    See the sample REST operation given below.

      /checkPhoneNumber:
        post:
          operationId: CheckPhoneNumber
          parameters:
        ...
          x-wso2-soap:
            soap-action: "http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumber"
            soap-operation: CheckPhoneNumber
            namespace: "http://ws.cdyne.com/PhoneVerify/query"
            x-soap-version: "1.2"

    The operationId parameter is used to map the REST resource with the corresponding SOAP operation.

  7. Edit the details of the API as shown below.

    FieldSample value
    NamePhoneVerification
    Context

    /phoneverify

    Version1.0.0
    Access ControlAll
    Visibility on StorePublic
    Tags

    phone

    For more information on the meanings of the latter mentioned fields, see Create and Publish an API.

  8. Go to the Implement tab. Click on Managed API. 
  9. Select the Endpoint Type as the HTTP/SOAP Endpoint. Enter the SOAP endpoint URL given below.

    SOAP Endpoint URL
    http://ws.cdyne.com/phoneverify/phoneverify.asmx

  10. Navigate to the SOAP to REST Mapping section. Click on a resource to view the In and Out sequences of the API.

    The following is a sample Synapse based XML configuration which reads some parameters from the request path and constructs the SOAP payload required for the backend (target) services.

    <header description="SOAPAction" name="SOAPAction" scope="transport" value="http://ws.cdyne.com/PhoneVerify/query/CheckPhoneNumber"/>
    <property name="REST_URL_POSTFIX" scope="axis2" action="remove"/>
    <property expression="$url:PhoneNumber" name="req.var.PhoneNumber"/>
    <property expression="$url:LicenceKey" name="req.var.LicenceKey"/>
    
    
    <payloadFactory description="transform" media-type="xml">
      <format>
      <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:web="http://ws.cdyne.com/PhoneVerify/query">
      <soapenv:Header/>
      <soapenv:Body>
      	<web:CheckPhoneNumber xmlns:web="http://ws.cdyne.com/PhoneVerify/query">
       <web:PhoneNumber>$1</web:PhoneNumber>
       <web:LicenceKey>$2</web:LicenceKey>
    </web:CheckPhoneNumber>
    
      </soapenv:Body>
      </soapenv:Envelope>
      </format>
      <args>
     	<arg evaluator="xml" expression="get-property('req.var.PhoneNumber')"/>
    <arg evaluator="xml" expression="get-property('req.var.LicenceKey')"/>
    
      </args>
    </payloadFactory>
    <property description="messageProperty" name="messageType" scope="axis2" type="STRING" value="application/soap+xml"/>

    The incoming JSON message parameters are stored using properties. The SOAP payload needed for the backend is generated using a payload factory mediator.

  11. Go to the Manage tab and select the throttling tiers for the API. Click Publish to publish the API to the API Store.
    For instructions, see Create and Publish an API.
  12. Navigate to the API Store and subscribe to an API.
    After generating the production and sandbox keys you receive a valid access token to access the API.

    https://localhost:9443/store

  13. Run the following HTTP request to invoke the API.
    You receive the actual backend response.

  • No labels