JDBC connection properties:

You can set the Minimum pool size to ‘0’ which will avoid stale connection being
held. But if you have lot of communication that happens with db continuously, you
can have minimum as ‘1’ which will reduce the burden of creation of conn object…
Maximum pools should be based on the maximum volume of transaction that can
hit your environment, and usage of db…
Enable connection pooling “True”
Min pool size is 1
Max pool size is 10 in our organisation
Block time out 1000msec
refers to how much time the IS should wait to get connection from connection pool before throwing
exception.
Expire timeout 1000msec
refers to how much time the free connection stay as it is before it expires.

Startup backoff timeout 10sec

Stateless: server removes the client session immediately after service executions
completed
Cache results: server store the service result in a local cache for the time period
specified in the cache expire property
Cache expire: The server maintains results in cache for the period of time you
specify in the Cache expire property on the Properties panel. The expiration timer
begins when the server initially caches a result, and it expires when the time you
specify elapses. (The server does not reset the expiration timer each time it satisfies a
service request with a cached result.) The minimum cache expiration time is one
minute

Block timeout: refers to how much time the IS should wait to get
connection from connection pool before throwing exception.

Expire Timeout: refers to how much time the free connection stay as it
is before it expires.

PUBLIC
 The time-to-live value for a publishable document type determines how
long instances of that document type remain on the Broker. The time-to-
live commences when the Broker receives a document from a
publishing Integration Server. If the time-to-live expires before the
Broker delivers the document and receives an acknowledgement of
document receipt, the Broker discards the document. This happens for
volatile as well as guaranteed documents.

JDBC Adapter

The webMethods JDBC Adapter is an add‐on to the webMethods

Integration Server that enables you to exchange data with relational
databases through the use of a JDBC driver. The adapter provides
seamless and real‐time communication with the database without
requiring changes to your existing application infrastructure. Using
the JDBC Adapter, webMethods Integration Server clients can create
and run services that execute transactions to retrieve data from, and
insert and update data in, relational databases. For example, you can
use the JDBC Adapter to add a customer to an Oracle database based on
data from another system connected to the Integration Server. Or you
can use the JDBC Adapter to poll a Microsoft SQL Server database for
customers that have been added to the database, and to send that data
to the Integration Server to be inserted into another resource.
The JDBC Adapter supports the following databases:
DB2 for AS/400
DB2 for OS/390
DB2 Universal Database (UDB)
IBM Informix
Microsoft SQL Server
Oracle
Sybase
Teradata
In addition to the JDBC Adapter, webMethods also provides the WmDB
package that you can use to connect to databases.

The JDBC Adapter enables you to configure the following components:

Adapter connections: Enable the Integration Server to connect to
database systems at run time. You must configure an adapter
connection before you can configure adapter services or adapter
notifications.
Adapter services: Enable the Integration Server to initiate and
perform database operations on a database. For example, an adapter
service could enable a trading partner to query your inventory
database to determine whether a particular item is currently in
stock. You configure adapter services using adapter services
templates, which are provided with the JDBC Adapter.
Adapter notifications: Monitor a database and notify the Integration
Server when an action (not initiated by the Integration Server) has

PUBLIC
 occurred on a particular database table. For example, an adapter
notification could notify the Integration Server when an update
operation was performed on a particular database table

JDBC Adapter connections support the following transaction types:

When you define a connection, the transaction type that you choose
determines the type of transaction management that the connection’s
operations use implicitly. Implicit transactions, which include the
transactions types in the preceding table, are managed by the
Integration Server transaction manager. You can also explicitly
manage transactions using built‐in services. See Appendix B,
“Built‐In Transaction Management Services”, for information about,
and examples of, explicitly managing transactions. NO_TRANSACTION The
connection provides no transaction control over the operations being
performed. That is, the connection automatically commits (Auto
Commit) all operations.
Local_TRANSACTION: With this transaction type, all of the operations
on the same connection in one transaction boundary will be committed
or rolled back together. A transaction boundary means the scope of
the transaction, from the beginning to the end of a transaction. It
can be in one adapter service, one flow service, one Java service, or
several steps in a flow service.
XA_TRANSACTION This transaction type allows the connection to support
two‐phase transactions executed across multiple databases. In one
transaction boundary, all of the operations on multiple connections
will be committed or rolled back together. A transaction boundary
means the scope of the transaction, from the beginning to the end of
a transaction. It can be in one adapter service, one flow service,
one Java service, or several steps in a flow service.

Note: Insert Notifications, Update Notifications, Delete

Notifications and Ordered Notifications support LOCAL_TRANSACTION
mode only.

The JDBC Adapter provides the following adapter service templates:

AdapterServiceType Description
SelectSQL Retrieves specified information from a database
table.
InsertSQL Inserts new information into a database table.
UpdateSQL Updates existing information in a database table and
includes a mapping for an output field that stores the number of
affected rows.
BatchInsertSQL Inserts new information into a database table. Use
this service when you will be inserting a large volume of data into a
single table. The data source for the service can be from a flat file
or from other services that generate an Integration Server document
list.
BatchUpdateSQL Updates information in a database table when
dealing with a large volume of data. Use this service when you will

PUBLIC
 be updating a large volume of data in a single table. The data source
for the service can be from a flat file or from other services that
generate an Integration Server document list.
DeleteSQL Deletes rows from a table and includes a mapping for an
output field that stores the number of affected rows.
CustomSQL Defines and executes custom SQL to perform database
operations. You can execute almost any SQL statement required by
integrations, such as data management statements.
DynamicSQL Defines and executes a SQL statement, part of which
you set at run time through the input field.
StoredProcedure Calls a stored procedure to perform database
operations.

 In Custom SQL, you can pass inputs to your SQL query at runtime.
With DynamicSQL, you can pass your entire SQL statement, or part
of your SQL statement can be passed at runtime; along with inputs
to it. So basically you can build your SQL dynamically at runtime.
 You use Custom SQL when SQL query is fixed with input variable
that are passed to the custom adapter service. You use dynamic
SQL, if SQL query changes during the runtime; in this cases you
prepare the sql query and pass it to dynamic adapter service in the
runtime.
 Custom SQL and Dynamic SQL we have to write the queries
explicitly. The main difference between Custom SQL and Dynamic
SQL is; in Custom SQL we can give the input values at design time.
In Dynamic SQL we can give the input values at run time.
 Custom SQL is faster than the Dynamic SQL because Custom SQL
is pre-compiled (at design time) but dynamic SQL is not pre-
compiled (compiled at runtime).
 Dynamic SQL is more versatile than the Custom SQL.

The adapter service performs a SQL operation against the database.

For SelectSQL, InsertSQL, UpdateSQL, DeleteSQL, CustomSQL, and

DynamicSQL services, the adapter service executes a SQL statement
against the database.

For BatchInsertSQL and BatchUpdateSQL services, the adapter service

executes batch SQL statements against the database. The adapter
service will continue to loop through the document list that is used
as input, set the fields to the parameters of the SQL statement and
then add that command set to the batch. Upon completion, the adapter
sends the entire batch to the database resource for execution.

PUBLIC
 For StoredProcedure services, the adapter service executes a stored
procedure against the database.

The JDBC Adapter provides the following adapter notification

templates:

Notification Template Description

InsertNotification Publishes notification of insert operations on
a database table.
UpdateNotification Publishes notification of update operations on
a database table.
DeleteNotification Publishes notification of delete operations on
a database table.
BasicNotification Polls a database table for data using a SQL
Select operation.
StoredProcedureNotification Publishes notification data by calling
a stored procedure inside of a database.
OrderedNotification Publishes notification data for multiple
insert, update, or delete operations on multiple tables for a given
database.

What are Join Types?

Answer:

The join type that you specify for a join condition determines whether
the Integration Server needs to receive all, any, or only one of the
documents to execute the trigger service. The following table describes
the join types that you can specify for a condition.

Join Type Description

All (AND) The Integration Server invokes the associated trigger service
when the server receives an instance of each specified publishable
document type within the join time-out period. The instance documents
must have the same activation ID. This is the default join type.For
example, suppose that a join condition specifies document types A and
B and C. Instances of all the document types must be received to
satisfy the join condition. Additionally, all documents must have the
same activation ID and must be received before the specified join time-
out elapses.

PUBLIC
 For my reference: All documents should have same activation id and all
should publish then only it will work. If publish one document and
another is not published it trigger will not execute.

Any (OR) The Integration Server invokes the associated trigger service
when it receives an instance of any one of the specified publishable
document types.

For example, suppose that the join condition specifies document types
A or B or C. Only one of these documents is required to satisfy the join
condition. The Integration Server invokes the associated trigger service
every time it receives a document of type A, B, or C. The activation ID
does not matter. No time-out is necessary.

Only one (XOR) The Integration Server invokes the associated trigger
service when it receives an instance of any of the specified document
types. For the duration of the join time-out period, the Integration Server
discards (blocks) any instances of the specified publishable document
types with the same activation ID. For example, suppose that the join
condition specifies document types A or B or C. Only one of these
documents is required to satisfy the join condition. It does not matter
which one. The Integration Server invokes the associated trigger
service after it receives an instance of one of the specified document
types. The integration Server continues to discards of any qualified
document types with the same activation ID until the specified join time-
out elapses.

Only one document type is executed not all. Only one document with
different activation is’s also work but it will not execute if send 2nd
document type

PUBLIC