Skip to main content

Uniface 9: WSDL for complex data output.

  • November 19, 2018
  • 3 replies
  • 0 views
Jan Cees Boogaard

WSDL for complex data output.

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

I am trying to create a WSDL to pass 'complex' data (order header(s) and item lines) to a third party, and have included an xmlstream output parameter in the service. I have coded the DTD into the parameter (xmlstream [DTD:dtd.model] orders_out : OUT) but I can't see the structure in the resulting WSDL file. Is there some trick I should be doing (like exporting the DTD and including it in the wsdl folder in Tomcat)? Or do we just not get this level of utility from UNiface wsdls?  I can obviously send the third party the DTD as part of the documentation, but this is problematic if I want to generate public wsdls with structured data.  As ever, fellow coders, I plead for enlightenment as to tricks tips or missing bits of training on how this works...  regards,  Iain

3 replies

Jan Cees Boogaard

WSDL for complex data output.

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

I am trying to create a WSDL to pass 'complex' data (order header(s) and item lines) to a third party, and have included an xmlstream output parameter in the service. I have coded the DTD into the parameter (xmlstream [DTD:dtd.model] orders_out : OUT) but I can't see the structure in the resulting WSDL file. Is there some trick I should be doing (like exporting the DTD and including it in the wsdl folder in Tomcat)? Or do we just not get this level of utility from UNiface wsdls?  I can obviously send the third party the DTD as part of the documentation, but this is problematic if I want to generate public wsdls with structured data.  As ever, fellow coders, I plead for enlightenment as to tricks tips or missing bits of training on how this works...  regards,  Iain

Hi Iain, My gut reaction would be 'it is a hence no description is needed' but that's not really it... In the past, I added an extra input parameter to signal to my operation if the return data had to include the DTD or not.... Other than that I'd say - anyone else got any suggestions?? Regards, Knut


Author: Knut (knut.dybendahl@gmail.com)
Jan Cees Boogaard

WSDL for complex data output.

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

I am trying to create a WSDL to pass 'complex' data (order header(s) and item lines) to a third party, and have included an xmlstream output parameter in the service. I have coded the DTD into the parameter (xmlstream [DTD:dtd.model] orders_out : OUT) but I can't see the structure in the resulting WSDL file. Is there some trick I should be doing (like exporting the DTD and including it in the wsdl folder in Tomcat)? Or do we just not get this level of utility from UNiface wsdls?  I can obviously send the third party the DTD as part of the documentation, but this is problematic if I want to generate public wsdls with structured data.  As ever, fellow coders, I plead for enlightenment as to tricks tips or missing bits of training on how this works...  regards,  Iain

I was more thinking that if I point SoapUI or something else at a wsdl with a complex data parameter, it is capable of showing me the shape of the complex data.  I appreciate that Uniface then ignores this when importing the signature, but if someone writing in VB or similar was to import my WSDL to their application, there is no way for me to pass them the shape of the complex data other than sending them the DTD manually.  So, how would you write a public web service, such that the API was publishable via the WSDL using uniface. (I suspect the answer is probably, you wouldn't.)


Author: Iain Sharp (i.sharp@pcisystems.co.uk)
Jan Cees Boogaard

WSDL for complex data output.

Author: i.sharp@pcisystems.co.uk (Iain Sharp)

I am trying to create a WSDL to pass 'complex' data (order header(s) and item lines) to a third party, and have included an xmlstream output parameter in the service. I have coded the DTD into the parameter (xmlstream [DTD:dtd.model] orders_out : OUT) but I can't see the structure in the resulting WSDL file. Is there some trick I should be doing (like exporting the DTD and including it in the wsdl folder in Tomcat)? Or do we just not get this level of utility from UNiface wsdls?  I can obviously send the third party the DTD as part of the documentation, but this is problematic if I want to generate public wsdls with structured data.  As ever, fellow coders, I plead for enlightenment as to tricks tips or missing bits of training on how this works...  regards,  Iain

As far as I know it is not allowed to use nested complex data parameters for call-in. When it'd be implemented, just using occurrence and entity parameter types could generate nested xsd files. Nowadays, it is possible to use entity or occurrence parameter type to use complex data within webservices. But only outer entity is sent. 

operation MyWebService
params
   string driver_cd : in
   occurrence driver : out
endparams
...

/sto /mwr=ws MyWebService    Generates the WSDL referencing an, also generated, XSD. My approach would be to generate a DTD as you said and convert it to XSD. Then define this parameter as string and parse it using xmltostruct. And, send this XSD to your consumers. Probably, I'd try to generate the WSDL using occurrence parameter type (it generates an XSD and the WSDL referencing it). Then substitute the generated XSD by the XSD converted from DTD. Finally, change interface from occurrence to string and cross fingers. The interface (WSDL) will talk about a complex data type made of a nested structure (SOAPui will understand it). In the other side, the service with a more flexible interface: just a string that it will be parsed using xmltostruct and the nested XSD. I don't know if SOAP driver will moan because of the changes. But it is very quick to try this option. The con is to handle with a modified wsdl (you must to take into account every time you change the interface). I hope nested complex data for call-in will be available soon.


Author: luis.vila (luis.vila@uniface.es)

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement