IDL/XMM generation not recognizing response parameters

, ,
1

I have an SR open for this, but if there is something wrong with the service definition, I thought perhaps you’d be able to spot it.

The service WSDL has in it a Request xsd and a Response xsd. The Request xsd parms are all included in the IDL and XMM files generated from the WSDL, but the Response xsd parameter is not.

The service definitions include:

<plnk:partnerLinkType name="PublishSalesOrderEntirexReqABCSImplV1">
   <plnk:role name="PublishSalesOrderEntirexReqABCSImplV1Requester">
      <plnk:portType name="client:PublishSalesOrderEntirexReqABCSImplV1Callback"/>
   </plnk:role>
   <plnk:role name="PublishSalesOrderEntirexReqABCSImplV1Provider">
      <plnk:portType name="client:PublishSalesOrderEntirexReqABCSImplV1"/>
   </plnk:role>
</plnk:partnerLinkType>


<wsdl:types>
   <schema>
      <import namespace="http://xmlns.oracle.com/PublishOrdersRequest" schemaLocation="xsd/PublishOrdersRequest.xsd"/>
   </schema>
   <schema>
      <import namespace="http://xmlns.oracle.com/PublishOrdersResponse" schemaLocation="xsd/PublishOrdersResponse.xsd"/>
   </schema>
</wsdl:types>


<wsdl:message name="PublishSalesOrderEntirexReqABCSImplV1RequestMessage">
   <wsdl:part name="payload" element="ns1:PublishOrdersRequest"/>
</wsdl:message>
<wsdl:message name="PublishSalesOrderEntirexReqABCSImplV1ResponseMessage">
   <wsdl:part name="payload" element="ns2:PublishOrdersResponse"/>
</wsdl:message>

<wsdl:portType name="PublishSalesOrderEntirexReqABCSImplV1">
   <wsdl:operation name="process">
      <wsdl:input message="client:PublishSalesOrderEntirexReqABCSImplV1RequestMessage"/>
   </wsdl:operation>
</wsdl:portType>

<wsdl:portType name="PublishSalesOrderEntirexReqABCSImplV1Callback">
   <wsdl:operation name="processResponse">
      <wsdl:input message="client:PublishSalesOrderEntirexReqABCSImplV1ResponseMessage"/>
   </wsdl:operation>
</wsdl:portType>

<wsdl:binding name="PublishSalesOrderEntirexReqABCSImplV1Binding" type="client:PublishSalesOrderEntirexReqABCSImplV1">
   <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
   <wsp:PolicyReference URI="#wss_username_token_service_policy" wsdl:required="false"/>
   <wsp:PolicyReference URI="#wsaddr_policy" wsdl:required="false"/>
   <wsdl:operation name="process">
      <soap:operation style="document" soapAction="process"/>
      <wsdl:input>
         <soap:body use="literal" namespace="http://xmlns.oracle.com/DOOComponents/PublishSalesOrderEntirexReqABCSImpl/PublishSalesOrderEntirexReqABCSImplV1"/>
      </wsdl:input>
   </wsdl:operation>
</wsdl:binding>

<wsdl:binding name="PublishSalesOrderEntirexReqABCSImplV1CallbackBinding" type="client:PublishSalesOrderEntirexReqABCSImplV1Callback">
   <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/>
   <wsp:PolicyReference URI="#aia_wss10_saml_token_client_policy_OPT_ON" wsdl:required="false"/>
   <wsdl:operation name="processResponse">
      <soap:operation style="document" soapAction="processResponse"/>
      <wsdl:input>
         <soap:body use="literal" namespace="http://xmlns.oracle.com/DOOComponents/PublishSalesOrderEntirexReqABCSImpl/PublishSalesOrderEntirexReqABCSImplV1"/>
      </wsdl:input>
   </wsdl:operation>
</wsdl:binding>

<wsdl:service name="publishsalesorderentirexreqabcsimplv1_client_ep">
   <wsdl:port name="PublishSalesOrderEntirexReqABCSImplV1_pt" binding="client:PublishSalesOrderEntirexReqABCSImplV1Binding">
      <soap:address location="http://eesf-dev.tcc.etn.com:8001/soa-infra/services/default/PublishSalesOrderEntirexReqABCSImpl/publishsalesorderentirexreqabcsimplv1_client_ep"/>
   </wsdl:port>
</wsdl:service>

The Request xsd all gets included in the IDL:

<xsd:schema targetNamespace="http://xmlns.oracle.com/PublishOrdersRequest" elementFormDefault="unqualified">
   <xsd:element name="PublishOrdersRequest">
      <xsd:complexType>
         <xsd:sequence>
            <xsd:element name="MSG-Data">
               <xsd:complexType><xsd:sequence>
                  <xsd:element name="MSG-Reference-id">
                     <xsd:simpleType>
                        <xsd:restriction base="xsd:string">
                           <xsd:maxLength value="25"/>
                        </xsd:restriction>
                     </xsd:simpleType>
                  </xsd:element>
                  <xsd:element name="HDR-Data">
                     <xsd:complexType>
                        <xsd:sequence>
                           <xsd:element name="Sender-Id" minOccurs="0">
                              <xsd:simpleType>
                                 <xsd:restriction base="xsd:string">
                                   <xsd:maxLength value="10"/>
                                 </xsd:restriction>
                              </xsd:simpleType>
                           </xsd:element>
                          <xsd:element name="Source-Order-Number" minOccurs="0">
...
...
...
                  </xsd:sequence>
               </xsd:complexType>
            </xsd:element>
         </xsd:sequence>
      </xsd:complexType>
   </xsd:element>
</xsd:schema>

The Response xsd elements are not included in the IDL/XMM:

<xsd:schema targetNamespace="http://xmlns.oracle.com/PublishOrdersResponse" elementFormDefault="unqualified">
   <xsd:element name="PublishOrdersResponse">
      <xsd:complexType> 
         <xsd:sequence>
            <xsd:element name="MSG-DATAOUT">
               <xsd:complexType>
                  <xsd:sequence>
                     <xsd:element name="Success-Message">
                        <xsd:simpleType>
                          <xsd:restriction base="xsd:string">
                             <xsd:maxLength value="10"/>
                          </xsd:restriction>
                       </xsd:simpleType>
                     </xsd:element>
                  </xsd:sequence>
               </xsd:complexType>
            </xsd:element>
         </xsd:sequence>
      </xsd:complexType>
   </xsd:element>
</xsd:schema>

The IDL (partial) looks like this:

/* Generated by Software AG, IDL Extractor for WSDL (8.2.2.17.41) on 2012-05-09 at 12:03:28
/* URI=http://eesf-dev.tcc.etn.com:8001/soa-infra/services/default/PublishSalesOrderEntirexReqABCSImpl/publishsalesorderentirexreqabcsimplv1_client_ep (binding for SOAP 1.1)
library 'publishsalesorderentirexreqabcsimplv1_client_ep' is
	program 'process' is
		define data parameter
		1 MSG-Data 		In
			2 MSG-Reference-id 	  (AV25)
			2 HDR-Data 	
				3 Sender-Id 	  (AV10)
...
...
...
					4 Itm-City 	  (AV25)
					4 Itm-State 	  (AV20)
					4 Itm-Postal-Code 	  (AV10)
					4 Itm-County 	  (AV25)
					4 Itm-Country-Code 	  (AV2)
		end-define


** End of file

Please advise… based on what I showed you here, should Designer be including the Response xsd element in the IDL and XMM, or is there some reason it isn’t caring about it?

Thanks,

2

Brian
It seems as problem to import.
Please submit files of wsdl, xsds - fulls files.
As bypass - try to import from same directory of the wsdl - instead inside /xsd directory.
I presume you use the Renovated extractor - included for example in 8.2.2.fix8
Shmuel

3

Hi Shmuel,

I am attaching the files.

I am using hotfix 17 which isn’t even available publicly yet, but has the fixes to build accurate namespaces (with “renovated” extractor).

Regds,

PublishOrdersRequest.xsd (48.6 KB)
PublishOrdersResponse.xsd (1.02 KB)
PublishSalesOrderEntirexReqABCSImplV1.wsdl (7.06 KB)

4

Brian, as far as my parsing goes - your wsdl:operation lacks output.
That may be the reason for processing only Request.

Here is an example:





All wsdls I inspected for you - have input and output in wsdl:operation

regards, Shmuel

5

Shmuel and all,

My understanding of what the web service developer was doing has evolved. He did not intend for the service to change from being asynchronous to being synchronous, and therefore, it is actually correct that the IDL not contain the parameter I thought should be there. What he did here was to introduce this callback binding so as to not affect the main conversation binding. Hence, there is no WSDL output operation on the main binding.

His attempt here was to provide EntireX with information to not be shared with the calling program so that EntireX can maintain persistence of the request payload until the service is available and accepts the message, but still to allow the client program to carry on and not wait.

With this said, is this kind of service construct supported by EntireX? Better question, with what I am trying to do here, is there a recommended way to guarantee message persistence on an asynchronous Reliable RPC call to a web service that has no response payload and may or may not be available?

How do I accomplish what I am looking to achieve here? And if this not possible, is my only option to have the web service developer change his service to be synchronous and send the acknowledgement back to the client program as a WSDL output operation?

Please advise.

Regds,

6

Hi Brian, your most practical course is to work syncronously request/reply (your last paragraph, WSDL out)

To have relability/persistence from EntireX outbound - there is a standard WSRM - Web Services Reliable Messaging which is complex, not supported by EntireX, and not sure how much industry acceptance it gained, not sure your external Web Services server supports it.

As Background of the discussion - we support similar-to-your-dream scenario with EntireX WebSphere MQ Brdge RPC server:

The MQ Bridge manages 2 Queues; EntireX client puts the messages in Q1 with Reply-to-Q2 attribute.
Then the same client goes to read from Q2 (blocked with timeout until reply arrives).
Just to say again - the persistence/reliability in your scenario is delivered outside EntireX,
and NOT a case for Reliable RPC (reliability which provisions case of RPC server down).

Regards, Shmuel