Does any one have idea to send xml using soap webservice.

Question

Question

Vineeth Jagannathan · Oct 30, 2017

We are getting the input as xml in ftp inbound adapter and need to send the xml content to the soap webservice. I have to create a business operation to handle this operation

Discussion (2)0

Log in or sign up to continue

Mike.W · Nov 1, 2017

Amir's answer with option 2 is what we did. The XML we sent had to be converted to allow it to be sent, so our code looked a bit like this:

Method ImportEpisode(pRequest As EnsLib.EDI.XML.Document, Output pResponse As Ens.Response) As %Status
{
; Use format 8 bit regardless of cache default (else Base64Encode gives ILLEGAL VALUE error)
Set sendingXML = pRequest.OutputToString("C(utf-8)",.tSC)
If $$$ISERR(tSC) Quit tSC
$$$TRACE("Sending: "_sendingXML)
Set sending = $system.Encryption.Base64Encode(sendingXML)
Set tSC = ..Adapter.InvokeMethod("ImportEpisode",.result,sending,{plus some other id parameters})
If $$$ISERR(tSC) Quit tSC
Set resultXML = $system.Encryption.Base64Decode(result)

...etc.

I hope this is useful to you.

Mike

0 0

score 0 · Answer 1 · 2017-10-30T09:48:14-04:00

Hi!

I like to use EnsLib.EDI.XML.Document class to move XML around because it will show nicely on Visual Message Trace and I can use message routing and DTL to route and transform it since it is a virtual document like HL7, ASTM or EDIFACT. Try looking into the documentation here:

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=EXML_tools_classes

You will notice there are out of the box business services to grab a file on an FTP server and take it's XML content as EnsLib.EDI.XML.Document. If you can't use it directly you will, at least, have an example to start with and make one of your own.

That is the Business Service.

For your Business Operation, you have two options:

Use the SOAP Wizard to create a business operation for you based on your WSDL and use it without changes
Use the SOAP Wizard to only create the proxy to the web service and create your own Business Operation around it yourself

Option 2 is nice if you want to hide the intricacies and details of using that web service. Some times, a web service will ask for a username and password on the body of the message, for instance, and you don't want to do that. You would create a credential property on the business operation and use it instead. So you are hiding these details from the user of that business operation. Another reason for implementing the business operation yourself is to change the data types and name of properties. That is our case. Your web service probably expects to receive a XML string. We are dealing with an EnsLib.EDI.XML.Document. Obviously, that won't work out of the box.

So, I suggest you create a business operation that receives the EnsLib.EDI.XML.Document and calls the Web Service proxy underneath, by extracting the XML string from the EnsLib.EDI.XML.Document request. You can use the SOAP Wizard to create the first version of your Business Operation and use it as a starting point for creating your own. Make the appropriate changes on it to receive an EnsLib.EDI.XML.Document as a Request.

Kind regards,

AS