hello ,all.
I have several questions about wm trigger. We are using wm trigger to accept the documents sent from GXS enterprise with the enterprise adapter.
1 Is there any way that wm will store the received file on disk? Since i just found out there are some ‘TriggerStoredata0000000’ like file in DocumentStore folder. But i can’t read it. Am i supposed to read the trigger stored file? And how can i read it since i do wanna know exactly the processed file if an error occured.
2 could i clear the trigger document queue manually? When the servive called by trigger crashed, there are other documents waiting in the queue. If the queue is not cleared, after the server restart, all these waiting document will be processed, right?
Any suggentions are higtly appreciated!
nancy

Please review the “webMethods Integration Platform Logging and Monitoring Guide” and the “Publish-Subscribe Developer’s Guide” for information on these topics.

Thanks Rob. I’ve read the manual you mentioned.
But still get confused.
Since we don’t use Broker and Monitor and we havn’t configure the logging database. The Application works this way: IS trigger accepts the documents sent from GXS enterprise using enterprise adapter and we set the trigger properties to guarantneed delivery. But I don’t think the publish-subscribe is going to work in this situation since there is no logging in guarantneed delivery.
In Publish-subscribe manual, it is said the IS use the retry count to ensure the guarantneed delivery because we don’t use history database and broker. And the serviced called by trigger is a try catch service. In this way, the trigger will never get the service exception error , right? So the retry count would never be more than 1.
And for now, we store the logging in flatfile.And we don’t use WmMonitor, Does that mean there is no way for us to read the DocumentStore trigger document?
And how to kill a service when it is running? Since sometimes the service fired by trigger runs really slowly and there are documents waiting in the queue. We do want to kill the running service and clear the waiting documents. Though it is not the way to solve the problem but it is better than IS restarting.

Thanks and Regards.
Nancy

A couple of questions to help me understand:

1. “…using enterprise adapter.” Which adapter are you referring to? “Enterprise adapter” normally refers to an old-style adapter that connects directly to Broker.

2. If you’re not using Broker, why are you using publish-subscribe? I understand IS has local publish but does the solution really benefit in some way by using pub/sub?

AFAIK, there is no way to read the DocumentStore trigger document. It is not intended for end-user use. If you need retry/resubmit capabilities, then you’ll need to devise some scheme to store the documents somewhere and develop a facitility to allowing viewing/resubmission. Or you could use WmMonitor and associated facilities or you can use TN. All approaches would require some analysis and probably some solution rework. IMO, TN is probably the way to go for interacting with GXS.

Thanks Rob.
Before IS, we are using GXS’s product called Enterprise to do the EDI file routing. And GXS also has it’s own product for file translation called AI but it’s a little complex. So when we found webMethods IS, we mainly focus on IS. And then GXS and webMethods became partners. And they developed Enterprise Adapter for IS to accept documents sent from Enterprise with IS triggers. However, almost all the manuals say little about this kind of frame.
I don’t know whether it is the same Enterprise Adapter we are talking about. And they introduced TN several months before but we havn’t decided whether to use it.
Thanks again.
Nancy

Thanks for the info. I think the product is called “Enterprise Gateway” rather than “Enterprise Adapter.” I’ve tried to find additional tech info about it but have found only marketing babble.

To provide meaningful help, I’d need to know more about gateway and how/why it interacts with IS using triggers. Beyond that, a key thing to do is make sure your trigger services behave appropriately. You need to determine the root cause of why services sometimes “runs really slowly.” Killing a service/thread/document is the wrong point of attack, IMO. A service shouldn’t “crash”.

Placing a trigger service in a try/catch block is a good thing to do, as long as the catch block does something reasonable. For example, the “right” thing to do may be to throwExceptionForRetry.

In any case, using DocumentStore as a queue of sorts for your own process/doc delivery control is not really a viable option.

Thanks Rob.
Enterprise Gateway is the new name for GXS and webMethods products. Enterprise Adapter is an adapter for IS trigger to accept document sent from Enterprise which is the product already in use.
We configure sender, receiver and aprf in Enterprise and Enterprise mainly focus on document routing. And when Enterprise receives a document, it will send the document to IS using Enterprise Adapter. The IS trigger will get the document according to the trigger configuration which is sender, receiver and aprf.
A service shouldn’t crash, I also think so.
But huge file processing,large amount of documents waiting, network exception may happen sometimes, not often I mean. And we are tuning the services now and we do wanna know other ways to deal with these situation just in case.
Such as, when too many documents are waiting in the trigger queue, for some reason, I’d like to clear the waiting documents.
Since trigger processing is kind of invisible, I feel like it’s tough to get to know what it is exactly doing inside.
Anyway, thanks for your attention.
Nancy

Thanks for the clarification on the Enterprise Gateway/Adapter components.

It may still be appropriate to use Trading Networks in this case, though I’m not sure given the info so far.

Are you using clustering of any sort?

Another random thought: for other components that use triggers (interaction with the Broker, MQSeries adapter, etc.) it’s possible to configure the triggers such that the IS doesn’t get overwhelmed with too many messages at once. Perhaps there are some settings in the Enterprise Adapter that will help the situation?

We are not using Cluster.
Maybe the only thing we can do is reducing the trigger queue setting and tune the services.
And I’ll recommend using the Trade network.
Thanks Rob.

Nancy