Do any of you out there have any experience with creating and/or invoking a web service in a webMethods B2B Server 4.0.1 environment?

Please don’t laugh :), but I’m currently working on a project for which we’ll have to create a web service on the 4.0.1 platform. The web service is supposed to accept a document, convert it to an XML node, and pass it on to TN (also 4.0.1.) Another task of the project involves invoking a web service from the B2B Server.

I opened the B2B Integrator for the first time in my life today. I looked for familiar clues from the 6.x world, such as the pub.soap folder and the Tools → Generate WSDL… option, but as I expected, they weren’t there. I also did a quick search through the 4.0.1 docs, but nothing.

Anyway, I just wanted to know from you guys/girls if this is even possible (but reasonable :)). If not, we’ll start considering other options.

Thanks,
Percio

Ha Ha Ha Ha Ha Ha… Oh, sorry!

Well, since SOAP messages are, after all, just XML documents posted over HTTP or HTTPS, you could certainly write something that performs functions similar to the SOAP processors available in 4.6 SP1 or later.

You wouldn’t have a URL like [URL=“http://localhost:5555/soap/default”]http://localhost:5555/soap/default[/URL], but could have a Flow service that did most of what a custom soap processor does invoked on its own URL.

The soap processor would require a bit more work to write without the built-in utilities for extracting or populating the soap headers and body, but those are just elements in the XML doc and you can certainly use pub.xml:queryXMLNode to do that yourself.

Since your just passing the body of the soap message on to TN, you may be able to get away with only writing the custom soap processor service.

All in all, it’s probably not too bad.

Mark

Yeah, shouldn’t be real hard at all. The getBody/getBodies services simply do queryXMLNode calls under the covers.

Well, technically, I think those built-in services are calling convience methods in the underlying soap message objects, which also don’t exist yet in 4.0x. Those methods are, though, just for convenience and not really necessary.

Mark

From what I’ve seen, though I didn’t dig much beyond the first level, it really appeared to me to be just raw XML query calls.

Convenience methods for extracting header and body nodes from the SOAP message object can be found in com.wm.app.b2b.server.SOAPMessage.

Now, this doesn’t mean that the pub.soap.utils:* services actually call those methods, of course, but they are there.

One day when I convert my custom SOAP processor into all java, I plan make use of those methods.

Mark

Hi All,

I have a problem here. I have to access the webservices through the SOAP request and SUBMIT the data in XML format to the service.

I have gone through the Documentation for the webservices of IS6.1 and It also has a process and a service related to processing of SOAP message and receive the response.

But, here in SAPbc ( webMethods 4.x) It does not have the services related to processing of the SOAP messages.

Can somebody who has Idea as to what to be done in this scenario, Guide me? ( as to how to proceed further in this regard)

solution that come to me:

write a java service which would process the SOAP message as is required.

I just want to get the Information as to what should be done in this scenario.

Kindly guide me as I have never did any of the coding for the

Webservices(…Just going through the documentations )

Thanks & Regards,
Teja.

SOAP simply describes a protocol and a structure for sending XML payloads over HTTP/S. You can create document types representing the payload of your soap body or the SOAP envelope containing your payload.

If you populate the doc type, convert it to a node, convert the node to a string and then use pub.client:http with a content-type of “text/xml” to post it to the endpoint URL of the web service you are consuming, it will work.

You’ll have to process the response message returned from the web service using either pub.xml:queryXMLNode or pub.xml:xmlNodeToDocument.

More work, but just basic XML over HTTP.

Mark