I have thought of several ways to run an event as a scheduled service. Before I implement this, I am curious what other folks have been doing and with what results.
If I want a service to run every day at 12:00 a.m., I can do the following:
Build some code into the adapter which calls the event at regular intervals and add it to the adapter as “Custom Code”.
Use the B2B Server (or another external client) to schedule a service for which an Enterprise adapter is a subscriber.
Use a separate scheduled Integration Component’s output canonical as a trigger for another Integration Component.
We have a consultant working with us. His opinion is as follows:
In my opinion the best way is probably to use the scheduler services in the B2B server to either publish an event that triggers whatever event that needs to be run in enterprise at the appropriate time. I think that the B2B server solution is the best solution overall because the B2B server’s administration utility can be used by non-developers that will support the given scheduled event in a production environment. They are not required to have intimate knowledge of custom coding in the adapter or integration component. They only have to know how to monitor scheduled services in the B2B Administrator
I thought webMethods had a utility for this. I think it was called Event Scheduler. Don’t know if this is still available. I think it was developed by Catapult Technology, the same crew that wrote Event Tracker. Whatever happened to them?
webMethods professional services has built a scheduler adapter that can be used for this functionality. Your local webMethods rep can probably get you a copy of it. From the documentation it looks pretty robust and useful.
To revisit this topic, I will share how I created a scheduled service using ILA. First, let me give the highlilghts of the integration:
PROBLEM: How to integrate a real-time data source with a data target that cannot handle the traffic of a real-time feed.
SOLUTION: Create a repository for the real-time data feed and publish the data at a regular interval to the Broker. The data target subscribes to this “snapshot” document.
There were two interesting discoveries in this project. The first was using an ILA as a service scheduler – the keeper of the snapshot timer. The second was creating a hashtable in local memory of an adapter to store the real-time data from the data source. I will discuss this approach in a future post.
Creating the Service Scheduler proved to be fairly simple. Here’s how to do it:
Create an ILA adapter instance on the same machine as the Enteprise Broker host. It is not imperative that the adapter be installed on this machine, but it will make the timer more accurate. The timer is triggered by document subscriptions so the fewer network hops, the better.
Using Enterprise Intregrator, create a component called “ServiceScheduler”.
Using EI, create a Document Type named “SleepDocument”. This document has no fields and no values.
Return to the component “ServiceScheduler” and double-click on the “Start Script” box.
Select the Document Type “SleepDocument” as the trigger for this component.
Add a Custom Code step directly after the “Start Script” step.
Double-click the Custom Code step and select the “Outputs” tab
Change “Return Type” to “void”
Select the “Script” tab and add the following code between the braces:
[begin code]
try {
// The value in () is the length of time for the scheduler in milliseconds
Thread.sleep(60000);
}
catch (InterruptedException e) {
e.printStackTrace();
}
[end code]
Add an Output Step to the component “ServiceScheduler”.
Set the output document type of this step to be the document type that is the trigger for your regularly scheduled component.
Set the output document type to “Publish” only (i.e. not to “Deliver” also).
In your regularly scheuled component, add an Output Step as the last step of the component.
Set the output document type to be “SleepDocument”.
In this example. a component has been built which runs every 60 seconds and after running, it publishes the document that causes 60 seconds to pass before its trigger document is again publishes.
It should be noted that Thread.sleep() is not an exact timer. The timer created in the steps above will sleep for at least 60 seconds. That is, the service scheduler will never run in less than 60 second intervals. For more information on Thread.sleep(), review a Java API.
My solution has been to built a completely new adapter for this purpose with various notification operations:
a notification that fires x number of seconds
a notification that fires x number of seconds except between duration X
We’ve found deficiencies in the basic notification operations in the Oracle and JDBC adapters so we use this adapter to initiate all scheduled tasked in enterprise server. It was a rather simple adapter to create and in my opinion much easier to maintain than intricate integration components.
We haven’t yet created an operation to fire just once per day but I believe it wouldn’t take much effort to do. The only problem to tackle would be how to let the operation know that if it’s after time X, that it has already fired.
I developed an adapter called scheduler for my company. It is the EAI version of the B2B scheduling service. It is pretty easy to write, but not as fancy as the B2B one.
I got a personal request to upload my component so I stripped it down and uploaded it to the Shareware section at [url=“wmusers.com”]wmusers.com.
The code is barebones (and hopefully it loads in your Broker…) but the idea is the same – a trigger document starts a “sleep” phase. When the sleep ends, a document is published to do some action. This is subscribed to by some other component.
After doing the action, this other component should publish the trigger document for the sleep component in the upload.