This content has been marked as final. Show 12 replies
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.
Thank you so much for your reply.
It is really very helpful hint that you have given.
We will try it out and let you know.
Sincerely appreciate your response.
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.
And what's the version of tuxedo and SALT, what's the platform?
Maybe some bug fixing changes the behaviors of WSDLCVT.
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
CCE engineer is investigating on why and how the behavior is changed after 10gR3 GA. And he/she will reply you.
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.