We are trying to make an external webservice call through GWWS.
The (soap) request contains an element which looks like:
+<Request Version="1.0" RequestID="11111111" TypeOfRequest="type1" Echo="false">+
We had created this soap request based on the WSDL provided to us by the webservice host.
We used a tool (like soapui) to generate the the above request.
To be able to make a service call to this webserive, we used the wsdlcvt to generate the fml32 field headers as: wsdlcvt -i <provided wsdl> -o <baseoutput name>
However we could not find a way to pack in the the information related to the attributes.
In vain, we tried to use the option [-m] with wsdlcvt.
Since there are no field headers generated by the wsdlcvt for the attributes, we do not know how do we put values of "Version", "RequestID", "TypeofRequest", "Echo" attributes of the "Request" element in the webservice request.
Are we missing something here?
How can we populate/put information in the attributes of an element in a request?
Currently, SALT will map the whole request into FLD_MBSTRING if there are any elments which has attribute. For your sample, the Request will map to an field of FML32 whose type is mbstring. When you issue wsdlcvt you will find the corresponding FML32 definition. Below are the steps to send required request:
1. Compose slimilar XML data (you can prepare a XML file and then read it)
2. Set it into MBSTRING buffer
3. Add MBSTRING into FML32 buffer.
4. tpcall with FML32 buffer.
We have a simple test wsdl as follows
+<?xml version="1.0" encoding="UTF-8"?>+
+<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://new.webservice.namespace" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://new.webservice.namespace">+
+<xsd:schema targetNamespace="http://new.webservice.namespace" xmlns="http://new.webservice.namespace" elementFormDefault="unqualified" attributeFormDefault="unqualified">+
+<xsd:element name="DateTime" type="xs:dateTime" nillable="true">+
+<xsd:element name="UUID" type="xs:string" nillable="true">+
+<xsd:element name="Status" nillable="true" minOccurs="0" maxOccurs="unbounded">+
+<xs:element name="StatusDesc" type="xs:string">+
+<xsd:attribute name="StatusTyp" type="xs:string" use="required">+
+<xsd:attribute name="Version" type="xs:string" use="required">+
+<xsd:attribute name="Name" type="xs:string" use="required">+
+<wsdl:part name="ServiceReq" type="tns:Service_Type"/>+
+<wsdl:part name="ServiceRes" type="tns:Service_Type"/>+
+<wsdl:binding name="ServiceBinding" type="tns:ServicePortType">+
+<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>+
+<wsdl:port name="getService" binding="tns:ServiceBinding">+
+<soap:address location="No Target Adress"/>+
When we create a soap request (Using soapiu) from the above wsdl we get:
+<ServiceReq Version="?" Name="?">+
+<!--Zero or more repetitions:-->+
As you can see that ServiceReq has attributes Version and Name
However, wsdlcvt (with -m) creates the following fml32 headers DateTime 1 string - fullname=DateTime, schema=xs:dateTime ServiceReq 2 fml32 - fullname=ServiceReq, schema=tns:Service_Type ServiceRes 3 fml32 - fullname=ServiceRes, schema=tns:Service_Type Status 4 fml32 - fullname=Status, schema=tns:Status StatusDesc 5 mbstring - fullname=StatusDesc, schema=xs:string UUID 6 mbstring - fullname=UUID, schema=xs:string
The points that we did not understand:
1. You mentioned: "SALT will map the *whole* request to FLD_MBSTRING
It is not so in this case.
Did we miss something?
2. Going by your suggestion in your last reply how do we create the FML32 buffer (specifically for the "ServiceReq" element, with attributes) for the sample we have?
Please ensure the WSDL you posted is correct. WSDLCVT report below WARN and no FML32 generated in my testing:
WSDLCVT:10:WARNING: No supported binding found in the WSDL document.
Please send me a new one, then I will investigate it.
For some reason, when I pasted the whole wsdl in the post, the html converted the value of soap:binding style= to ""
This is line 42 in the wsdl in my post above (we can see it as soap:binding style="").
I cannot get it to show up correct in the post.
Would you be able to update the "" with the following and try again?
I tested it at my end, it seems to work after changing it.
Thank you again for trying this out.
We have the following versions on SunOS 5.10 Generic_142900-13 sun4u sparc SUNW,Sun-Fire-V245:
+$ wsadmin -v+ INFO: Oracle SALT, Version 10.3.0.0, 32-bit, Patch Level 015 INFO: Oracle Tuxedo, Version 10.3.0.0, 32-bit, Patch Level 044
Actually the behavior you see now is an imcomplete enhancement solution, which interprete the elements of the sequence defined in the complexType into actual FML32 field.
But the attribute values defined in the complextType are missing now.
To pack the attribute values into the soap request, you can roll back your SALT to GA version. Then as described in the SALT E-doc, the whole complexType, including the sequence and attribute values, will be converted into MBSTRING. You can retrive the attribute values from the MBSTRING.
If you still want to convert the attribute values into FML32 fields, you may file a enhancement request to us. Then we can evaluate the effort and decide how to come out a complete solution for dealing with the complexType.
Thanks & regards,
Thank you so much for your time and replies, Wei and Xu.
We will rollback to SALT GA and test it out. Will update this post with what we find out.
The more I read your response I think to myself:
Do you mean:
1. Roll back SALT to GA (or have a separate TUXEDO Environment with GA SALT)
2. Run wsdlcvt to get the complexTypes as MBSTRING
3. We can use the resulting files (.mif, .wsdf, .fml32) in the patched environment!?
Thanks and Regards,
If it is required to roll back the SALT PATCH:
Another requirement ( [Custom information in HTTP Header in an outgoing GWWS Request|https://forums.oracle.com/forums/thread.jspa?threadID=2378055&tstart=0] )
Responses in that post suggests that we would have to install patches for that.
I wonder how can we have a GA version and also have a patch installed at the same time!
And also the reason we have a patch installed, it is for BUG11884561 salt 10.3 gwws server dies often in production
So I am not sure if we would able to rollback to GA at all.
Unfortunately you cannot use the files generated by wsdlcvt of SALT10gR3 GA on the patched envrionment.
To solve this issue, you may file a request to ask for a complete enhancement to convert XSD:complextType into Tuxedo field types.
Thank you so much for your reply Irene.
As it would require a lot more time and effort to get a fix or an enhancement in place for SALT to work for our requirement and in our environment, we have decided to take an alternate mature approach.
Thank you all for your replies and support.
Thanks and Regards
As a note of comment: Features like "dealing with complex types" and "inclusion of custom information in the header" should be standard features and not "enhancements/fixes" for a product that is a "Gateway" to web services!
Actually, you can select GA+customized soap header patch if you can accept the mapping from XSD with attribute to FLD_MBSTRING , and file a request for this, I do not think it need more time.