I am planning to use filepolling for invoking a service that will processes an incoming xml file.
Does anyone know what will happen to the xml file in working directory if the IS goes down. will it be moved to error directory?
No, it will not. Nothing will happen to it. It will not have its processing resumed automatically.
You’ll want to have a monitoring facility to see if files are “stuck” in the work directory. You’ll also want to monitor the error directory.
What action you take to recover will depend on the integration itself and if the file was successfully processed but failed to be moved (IS died after successful processing but before the file was renamed).
Thanks…the information was really helpful for me.
What I am trying to do is develop a service that’s invoked by filepolling will publish a document locally. So that I can use max attempts and retry interval in trigger which is listening to the local document, to make the retry logic less complicated.
The trigger then invokes a service which does a file transfer and also an http call.
when I am trying to publish a document I am getting a Dispatcher not Initialized error. Can anyone help me in solving this problem or give me some other suggestions for retry.
Not a bad approach, but keep in mind you may have some timing issues with the triggering of your processing service and the location of the document.
While your file polling service is running, the file is in the work directory. When your file polling service returns, the file is moved to the done directory (on success) or to the error directory (if your file polling service throws an exception).
When your file polling service publishes the document, it will be done asynchronously. So by the time the subscribing service gets the published doc, the file may have been moved (it’s a race condition).
If you do pub and wait, then I believe that may mess up the retry approach you’re trying to use.
Coupling file polling and a pub/sub approach for retry may be more complex than it appears at first blush.
Well the idea is the service which is invoked by trigger will pick the xml file from done directory and then do a transfer. If it fails to transfer the file (file not moved to done directory or delay in moving the file) then the service will throw a service Exception which will cause it to retry for a specified number of times with a delay. If the retry exceeds the max count then an email can be sent for some manual intervention.
Ah, good point. Depending on a number of factors, the file may not be in the done directory by the time the subscribing service gets the published document. The file may still be in the work directory. BUT, since the subscribing service will retry, the file should eventually show up even if it wasn’t there on the first or second attempt by the subscribing service to read the file.
Personally, I think that using the Broker just for the sake of simplifying retry logic is a bit much. Nevertheless, if you so choose to proceed with this approach, consider setting delayUntilServiceSuccess to true when invoking pub.publish:publish. This should make it a lot more likely (if not certain) that by the time the trigger receives the document, the file has already been moved to the done directory. Plus, if an error were to occur after the publish (ie. causing the file to be moved to the error directory instead), the IS wouldn’t even publish the document, meaning you wouldn’t waste time executing a trigger that would never find the file to begin with.
- Percio
Thanks Percio…
I am publishing the document locally and getting a “ISS.0098.9013U” Dispatcher not Initialized error. I looked for this error code in from error message reference 6.5 and 6.5.1 which asked me to look in Chapter 5 of “Building Integration Solutions Using Publication” to setup the configuration correctly.
I am unable to find any information about initializing dispatcher in the publication. Can anyone help me how to start the dispatcher?
The IS was never connected to a Broker before. Can this be a cause for not able to start a dispatcher on an IS?
I’m sorry. I missed that detail when reading through the thread. In my humble opinion though, even if you’re doing local publish, I think using a trigger just for the sake of its retry capabilities is more overhead than it’s worth it.
As far as the dispatcher error goes, I’ve never seen it myself. I haven’t worked on IS 6.5 though (only 4.0.1 through 6.1.) Hopefully someone else can help.
Good luck.
- Percio
There is nothing you can do to control the dispatcher directly. I think the explanation of the error code in the message reference is indicating that something is wrong with the installation/configuration in general. You might go through Chapter 5 and confirm that everything is configured as indicated.