Can web services replace Trading Networks functionality because of its ease of implementation in the integration world? Or will Trading Networks support web services?

Srinivas,

TN and web services are two different concepts.none of them can replace the other.with TN, you execute the services which inturn can call the web services.TN is basically used for routing the transactions.

just my 2 cents.

ramesh.

Srinivas,

WebServices are globalized way of standards to talk with any resource hosted universally UDDI…and if you are talking about webMethods Trading Networks component this is used as a hub (enterprise)and spokes (trading partners/customers/suppliers/internal transactation purposes)for ease of monitoring the transactions.

Bottom line is nothing replacement of webServices vs TN each have its own individual concepts.

HTH,
RMG

Srinivas,

Trading Networks is targeted toward managing large numbers of trading partners who need to exchange documents with each other or with the “hub”. These documents can be in many different formats and may be exchanged using many different protocols. The documents may be in XML format, flat files or various EDI transaction sets.

Web services can be used to exchange documents among many partners, but doing so without some sort of hub in the middle would require many point-to-point B2B integrations driving up implementation and maintenance costs.

The proliferation of web services support among trading partners does not replace the need for TN. Those partners who support web services can use them to route messages to or receive messages from partners through the TN hub.

TN’s document-centric approach is best suited to allowing multiple partners exchange business documents. It is not necessarily the best fit for allowing one trading partner to invoke services exposed by another.

Mark

Thanks much for your response Mark and others too. It clearly clarifies the need for Trading Networks. In version 6.0.1, is it possible to invoke a web service that a partner provides through TN? If so, please provide an outline of how it can be accomplished?  
For Example, can we send a SOAP RPC request over http protocol? How do we encapsulate the SOAP request and response within Trading Networks? In short, how do we route messages to or receive messages from partners who use web services through the TN hub at out end?

I’m not sure about TN 6.0.1, so Rob or other TN gurus may need to confirm this response.

If you can define a custom delivery service, that service can invoke pub.client:soapHTTP to send the soap message to your partner. The service should use the TN delivery service specification and should access the partner’s TN profile to obtain the soap endpoint address.

To easily see what parameters should be passed to your soap rpc message, generate a Web Services Connector from the WSDL provided by your partner.

Mark

Mark’s response is right on. Create a custom delivery service (instructions are in the wM docs) to handle SOPA. It is quite easy to do.

SOPA. Is that the South American version of the SOAP protocol?

Thank you both for direction on writing custom delivery service for the above purpose. Also when implementing a hub using trading networks, under what circumstances does the partner ‘must’ have a partner server installed?
Any ideas on dealing with partners who do not want partner server installed at their sites within their network? Can we still use Trading Networks at our hub to monitor and exchange transactions with partners who do not use partner server(and just use a web service to interact with the hub)?

SOPA. Durned fat fingers.

Srinivas wrote:
“…under what circumstances does the partner ‘must’ have a partner server installed?”

There are no cases where a partner must have a partner server installed. In fact, it is the usual case for a partner to not have partner server–communicating with a partner using http or SOAP or ftp where they have their own system (IIS, Apache, WLS, etc.) is the norm.

Does the payload exchanged with a Trading Networks have to be a bizdoc? Does the partner have to always envelope the payload in a bizdoc format for the receiving Trading Networks server to recognize? If so, how does a partner who does not have partner server installed at their site, communicate with the trading networks at the hub? Thanks in advance for clarification.

Hello,

Yemi Bedu

srinivas wrote:
“Does the payload exchanged with a Trading Networks have to be a bizdoc?”

No. wm.tn:receive accepts a node object, which is automatically created by IS content handlers when documents of the appropriate type are posted (e.g. an XML doc can be posted directly to wm.tn:receive by any HTTP capable client).

srinivas wrote:
"Does the partner have to always envelope the payload in a bizdoc format for the receiving Trading Networks server to recognize?:

No. Unless they are using IS/TN, they will not able to do so. Plus, a bizdoc object isn’t really suitable for transport. It’s pretty much a construct that is local to IS/TN.

Yemi wrote:
“So you can have your partner call a normal service you expose and inside that service you can call wm.tn.doc:recognize setting up the xmldata or edidata as needed.”

Yes, this is a good practice. It is normally a good idea to not have partners invoke wm.tn services directly. Rather, have them call your gateway service instead. Then just pass the doc to wm.tn:receive–no need to do wm.tn.doc:recognize first unless you have some need to manipulate the bizdoc directly after recognition, which is normally not the case.

Thanks much. That is great information.

I don’t think this would work, because the soapRequestData parameter is an object containing the soap message. I’m not sure what your document type contains, but in most cases you would need a custom delivery service to convert the content of your document to a node, create an empty soapData object and add the node as the body element.

After creating the soap message you would then use pub.client:soapHTTP to send the message perhaps after first querying the partner’s profile to determine the endpoint URL.

Mark