i m not able to understand the example shown in pages 69 and 70 of
Wm trading networks concepts guide…
1.i think in the examplle, three trading partners are dealt with…
2.the original sender,IS(TN) and the last(third) receiver…
3.so, how many senders & receivers r there in this scenario…
4.whose DUNS(REceiver id) si looked at in this example?
5.how can the first-level senders doc have RECEIVER Id of the Third-level one,which looks so in this example…
btw, i m referring to levels just to make my point clear…
Hi Greatwhite,
In this scenario, IS/TN is the Hub which works as a transport to receive doc from sender and deliver the document to receiver. Of course, sender has to specify in the doc who will be the recepient of that doc. A sender can send 1st doc to IS/TN Hub and specify receiver1 as recipient. Same sender can send 2nd doc to IS/TN Hub and specify receiver2 as recipient. IS/TN Hub will have the profiles for sender, receiver1 and receiver2 with all the connection info.
Hi Greatwhite,
There are many companies which do just that. They call themselves Online Exchanges. They host IS/TN Hub.
There are buyers and suppliers who pay annual fee to this Online Exchange company as customers and in turn this Online Exchange company transports the PO from a buyer to supplier(s), POA from a supplier(s) to buyer etc… using its IS/TN Hub.
Some of the real world online trading exchanges(a.k.a HUB’s and Marketplaces) the (Buyer/Seller) scenarios as mentioned by Bhawesh, among them few companies are Covisint,Elemica,TradeRanger,RubberNetwork, Liaison,Converge,WWT,Agentrics,GHX,Emergis,
Exostar etc… built on wM IS/TN (Hub & spokes) Integration capabilities.
hi all,
i have a new question…i hear thes being used very often and interchangeably and loosely in TN and Broker scenarios.i need some clear answers and similarities/duifferences and explanations involving examples.
1.Reliable delivery
2.Guaranteed transactions
3.Guaranteed delivery
4.Guaranteed storage
and how each of these are taken care of in webMethods…
All these have been mixed up for a long time in my mind, so i would really appreciate some patient answers…
Associated with TN. With the retry facilities and document logging, document delivery is “reliable” but not guaranteed. Reference: Trading Networks Concepts Guide.
Relatedly, there is a reliable execution feature called service execution task of TN that attempts to re-execute a failed service up to a user-defined maximum number of times.
Guaranteed transactions.
Guaranteed delivery.
There are subtle distinctions made between a “guaranteed delivery” and a “guaranteed transaction” but within IS but they are more or less equivlent–a guaranteed transaction is conducted within the context of a guaranteed delivery.
Guaranteed delivery is a facility of Integration Server that ensures guaranteed, one-time execution of services. This is useful for IS to IS communication or IS API client to IS communication. It is not usable in any other context–e.g. it cannot be used to guarantee delivery from IS to any arbitrary HTTP/FTP server. References: Guaranteed Delivery Developer’s Guide; Integration Server Built-in Service Reference, Remote Folder.
For all intents and purposes, “guaranteed” and “reliable” are the same thing–they both try to execute a service up to a limited number of times and then quit. “Guaranteed” really isn’t–it’s more like “very likely.”
Guaranteed storage: Associated with Broker. It is "a highly reliable storage mechanism" that uses two-phase commit to write documents to disk. Keep in mind that “guaranteed” refers to the storage mechanism only and only for document delivery to and from the Broker. When the Broker tells a client “got it” it really does. When a client retrieves a doc and tells the Broker “got it” it really does and must take care not to drop it in the bit bucket by mistake. Reference: Broker Administration Guide.
Keep in mind that Broker doesn’t do anything else “special” for guaranteed documents. If there are no subscriptions at the time the document arrives, it is tossed in the bit bucket. Guaranteed documents aren’t automatically logged somewhere for review or resubmission–you have to set that up yourself (using the logging utility or modeler or other mechanism–there are many choices) if you want that. Once retrieved by the subscribers, they are gone from the Broker. I believe some of the IS storage stuff exhibits these same characteristics but they are not referred to as “guaranteed storage.”
1.that clears alot of questions.btw,could u explain when a transaction begins and ends in the context of webMethods?what can be a shortest/simple transaction on one hand and what could be a long/complex transaction using a realtime example…
2.btw,u have not gone deep into those subtle differences between delevery and transactions.could u please…
3.if guarantted storage is on hard disk as u said,is that temporary or permanent?am i correct in my conclusion that,even though u have
guarantted storage configured,that still is not good enough to avoid
a document from going into that bit bucket.
Meanwhile,i would be doing my own homework.
Thank u for the detailed reply.
Greatwhite
There is no such thing as “the context of webMethods.” webMethods is a company, not product.
Within the context of Integration Server the shortest “transaction” is the execution of any service. Within the context of Trading Networks, the shortest “transaction” might be the delivery of a document to a partner, which inolves the use of many services.
A long-running “transaction” is one where there are multiple interactions between your system and another in which you keep the “state” of the interaction. For example, consider a purchasing process which might consist of these high-level interactions:
Partner sends a PO.
You send a PO ack, indicating changes.
Partner sends a PO change.
You send a PO ack, accepting all items.
You send a ship notice.
You send an invoice.
Partner sends a remittance advice, indicating payment.
You can implement each of these as independent “transactions” where what came before (or didn’t come before) doesn’t matter to the integration layer (the end-point appliation might care though). You simply pass things from point A to point B.
You can also implement this in the integration layer as a single process. If you receive a PO change without ever having received a matching PO, then you might indicate a “state error” and fail the entire transaction.
Refer to the Developer User’s Guide on pages 385-386 for a description of the difference in terms of events. It’s basically a meaningless difference from our viewpoint. A “guaranteed delivery transaction” is all we need to worry about. But since the applicability of this facility applies only to server to server communication, or to IS clients that us the TContext class, this facility isn’t used much. In fact, I’ve never seen it used anywhere.
There are volatile and guaranteed storage types.
Broker client (adapter, IS, custom code) publishes a doc to the Broker.
If there are subscribers, the doc is placed on each subscriber queue. If there are no subscribers, the document is tossed regardless of storage type.
When a subscriber retrieves a document AND acknowledges receipt, the document is removed from the queue (regardless of storage type). Once all subscribers have retrieved their copies of the document, the document is completely gone from the Broker.
If the Broker is stopped or crashes, volatile documents are lost as they are only kept in memory. Guaranteed documents are preserved as they are written to disk.
The most likely place for a document to be lost inadvertently is in custom services within IS. One needs to configure things properly and write services such that document loss cannot occur.
Hi reamon,
That explanation with example puts lots of important questions to rest and thnks once again.so,one more Q
1.on any given broker,can it have both volatile and guaranteed storage types at the same time.if yes,can they be configured differently for different subscribers…
2.on any given broker,these queues we are talking about,can these be shared by multiple subscribers or is it exclusive?
3.btw,i know this for sure,that a subscriber can have mutiple queues on the same broker in principle.am i right?
4.is it possible to have saparate queues based on doc types?
5.lastly,there is no concept of scheduling(publish/subscribe) as such in the broker scenario.am i right?its all as and when documents arrive on the
broker if i am right…
It can be either. Normally, IS establishes “shared state” clients where multiple clients can connect to the same queue. Keep in mind that only one of the clients will get each message that is queued, not all. If you need multiple clients to each get a message, they must use different queues. This is easily achieved on IS by defining multiple triggers.
Correct. Not only in theory, but in normal practice. IS has one queue for every trigger.
Queues are defined for a given client. That client can use its queues in any way it likes. One queue per doc type, for example. Or it can have one queue with subscriptions for multiple doc types. Typically, an IS trigger establishes one queue and just one document type subscription but it can subscribe to multiple doc types.
Correct, the Broker itself does not provide for firing an event at a scheduled time. But IS can. Set up a scheduled task and have the service publish the document of interest. The Broker queues documents as soon as they arrive. It does not hold them for later delivery.
hi reamon,
Thank u for the detail(content and clarity) u have gone into with each of these topics and i also think this material deserves a place in the future WMdocs.
1.) Each and every doc type on any given queue at any given time can be associated with only one of these two storage types(volatile/guaranteed) in theory and practice…is that so?
Thanks for the feedback. Actually, all this information is in the wM docs. That’s how I’ve learned all this stuff! From time to time I reread sections of the docs, and couple that with observations from hands-on activities, to make sure I understand.
Essentially, yes. Both the doc type and the queue (“client” in wM Broker parlance) have a storage type attribute. A document’s storage type can be overridden by the storage type of a client’s queue. Review "Client Queue Storage Versus Document Type Storage" on page 85 in the Broker Administrator’s Guide v6.1 for details.
Reamon,
u have given me excellent insight into how broker/TN and other delivery and storage types in detail.Thanks u very much for your support of this
community.i will be reviewing wMdocs from time to time to gain new insights the way u do.