Adapter Notification Usage

Does anyone know any reasons why you would use an adapter notification over a service to publish documents to the broker?

I have a scenario where I need to have something happen when a row is inserted into a table, a doc needs to be published and then the row needs to be written to an archive table and deleted from the source table…
Any thoughts on which way to use or is it more a preference thing not neccessarily a Best Practices thing?

Adapter notification creates its own temporary tables, database triggers. So you need not worry about having a scheduler service, selecting a record based on timestamp or a field indicating that it’s new.
As in your case, how is it that it can be decided if it is a new record or not until and unless you have a separate criterion for that. Adapter notification makes it simple, it creates a db trigger which inserts new data into a temporary table. Data from temp table is selected and passed on to webmethods at the specified polling interval and is deleted. This is a clean way of doing it.
You can define your own db trigger, temp table and then use a scheduler service, to select the data and pass it over, but imagine all those extra components to be maintained. So i would generally prefer adapter notification in your case atleast



Adapter Notifications are one of the ways you notify Middleware to start of its process. Generally they are used on some event which middleware is looking for.
In your case : You have to initiate a process on a “row insert” hence you have to notify middleware of this event. To do so the adapter publishes an document.

This scenario helps when you have one publisher and more subscribers.



“Adapter notification makes it simple, it creates a db trigger which inserts new data into a temporary table.”

What do you mean by Adapter notification creates DB trigger which inserts data into temp table?

Adapter notification picks the data up (from the table it is set on) and publishes the document to the broker. (My understanding)

Thanks ,

Hi Ram,

When you create an adapter notification, suppose on a oracle database, (except for basic notification), it creates a oracle trigger, a temporary table. It does not select the data from main table and publishe it.
The trigger on the will get the data from the main table based on the conditions specified in the notification and inserts the data into a temp table, created by webMethods. The data from this table is selected at the polling interval u have mentioned in the adapter notification and publishes the document to broker or locally. That is what happens when you create an adapter notification



Forgot to mention, you can see the name of the trigger, temporary table and the sequence which webmethods creates on the adapter notifications properties tab. Just check that if you have not checked it



Thanks for the Prompt reply.

I have basic notification so i havent noticed it i guess and if i am not mistaken database (oracle,JDE etc…)doesnt matter the adapter notification concepts ( trigger and temp table).

Is a temp table be created for each Adapter notification or one for the IS server.

And what is the Sequence in the properties Tab.

I will go through the Pdf anyways.

Thanks again Pradeep,

Hi ram,

A separate trigger and table are created for each adapter notification


I would recommend using only Basic Notification. Having the adapter manage the trigger and buffer table definitions risks missing notifications because the adapter will drop the trigger and buffer table when the adapter notification is disabled–which is usually not what you want. Using Basic Notification, you manage those two elements yourself (which is usually trivial).

For each type of notification, you’ll want a unique buffer table.

I Agree with ROb.Managing Trigger and buffer table by adapter is not a good idea .As there is alwyas a risk of loosing consistancy over the interface …the trigger and buffer table are dropped and creted everytime we disable the adapter the best idea is to

  1. create a trigger on the base table
  2. enter each record into the buffer table
  3. create a basic notification on the buffer table .