Clustered WPS Start - Stop procedure

Many a times i came across a scenario where in the developers working on clustered WPS env on dev/test/SIT etc didn't knew how to gracefully stop or start the servers in the env. There is a specific sequence that needs to be followed to either Start or Stop the servers : 

(Developers mostly prefer to grep and kill !! This is not a right way !!)

(1) Steps to Stop the servers in WPS clustered env:- (Assuming the WPS clustering has been done using the Golden topology)

(A) Stop the Deployement Env from the Admin console (This would stop all the messaging, support and application servers)

(B)  Stop the Node Agents : 

go to the : WPS/profile//bin/ and fire a "stopNode.sh" command.

You need to do the same for all the node agents in your env one by one.

(C) Stop the Deployment Manager:

DM/profiles//bin/ and fire a "stopManger.sh" command.

(2) Steps to Start the servers in WPS clustered env:-

(A) Start the Deployment Manager

(B) Start the Node Agents

(C) Start Servers in these Node agents

REPLICATING ADAPTER WORKSPACES – WPS

We often come across a scenario during our Telecom application’s development cycles where we develop an adapter for a given circle and then we need to replicate it for another circle where the table structure etc are same and only the names etc may vary. This can again be achieved using 2 approaches. Either we create the respective adapter again or we can follow the replication approach. In the replication approach we can copy the adapter inbound/outbound into destination module.

 This replication process involves copying of the import/export file and then changing the database URL in the corresponding export/import. This approach does have a limitation that it works only for scenarios where the schema and table structures are same and the only difference is in the URL of the database.

 In such a case we do not need to copy or replicate the activation spec or anything similar. Just copying the import /export file and changing the URL will suffice the requirement.

MERGING WORKSPACES FOR ADAPTERS – WPS

AIM:- We often come across a scenario during JCA JDBC adapter development where we create one adapter and all the associated components and then suddenly some new requirement pops up where we are supposed to add some more operations in our Inbound adapter, in lay man terms, the requirement is to add some more tables to the inbound adapter.

Process:-

To actualize the above mentioned scenario, we create one module with an Inbound adapter linked to one table. Now say for instance another requirement comes where in we need to add 1 more table to the inbound adapter. Now, we have 2 approaches that can be followed, either scrap the existing module and create a fresh one or create a new module with an adapter linked to new table and then merge both old and new modules so that the existing adapter can support both tables. In this document I will take you through the second approach.

What To Do?

Create 2 modules, both with 1 inbound adapter each and an operation based on the corresponding table name. Then as per new requirement we need to merge both modules in such a way that the previous adapter itself would support both operations without re-running the external service wizard.

 In short say for instance we have already created one inbound adapter with 20 tables. Now if 2 more tables need to be added then we won't have to recreate the already created adapter and instead can be merged in the following way:-

 

These are the bare minimum tried and tested steps. If we are dealing with Outbound adapters then the steps may be modified accordingly.

NOTE:-

Apart from these we may have to carry out some more changes based on the complexity of the modules to be merged. These can be handled by respective owners at development/ deployment time.

Multiple Activation Specs - WPS

Introduction:-
Activation Spec specifies the database connection properties for an Inbound JDBC adapter, in the same way as the Outbound JDBC adapter uses the managed connection factory.


“Managed connection factory properties are used by the adapter at run time to create an outbound connection instance with the database. Similarly it uses the Activation spec for configuring any Inbound database operation viz. event polling.”


Problem Statement:-
In the present scenario we want to connect to at least 4 databases at the same time and poll for events using the Inbound JCA-JDBC Adapter using Multiple Activation Specs.


Solution:-
The above scenario can be realized using WPS, by creating as many exports for an inbound JDBC adapter (by running the external service wizard that many times) as many database connections are required. Every export is associated with a specific activation spec and hence for 4 exports, 4 activation specs get created, in turn fulfilling the requirement for Multiple Activation Specs. These specs get created when we are configuring the inbound adapters.


WHAT TO DO & HOW TO DO?
Our sole objective is to create multiple Inbound JDBC Adapters in a module such that they use mutually exclusive Activation Specs to connect to respective databases. Activation Specs as I mentioned earlier also is a collection of connection specific properties used by the Inbound adapters to connect to the database. Create a fresh module and run the external service wizard for 4 times (say for instance we want to connect to 4 different databases). Every time we run the wizard, we need to specify the connection properties, these properties are nothing but activation spec properties.

In figure 1 below, I have created 4 exports for an Inbound JDBC adapter and have connected them to a Java component based on a fictitious requirement. We can do what ever we want to with the events delivered by the Inbound adapters.

FIGURE 1

The JDBC inbound adapter allows us to modify the activation spec properties even after the adapter has been created by clicking on the corresponding SCA component and checking its properties. Refer to the next figure for the same.

The connection properties that we specify are actually the activation spec properties and are visible in the export’s properties tab:-

FIGURE 2

Some of the other Activation Spec properties are:-

FIGURE 3

Conclusion:-

Multiple activation specs can be created for inbound JDBC adapters by creating as many exports as the number of databases we want to connect to. This would internally create specific Activation specs for every associated export.