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.
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
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.
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.
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!