TIBCO Hawk Rulebase Standard Guidelines

Book Review: BPEL Cookbook: Best Practices for SOA-based integration and composite applications development

Book Review: BPEL Cookbook: Best Practices for SOA-based integration and composite applications development Edited by Harish Gaur and Markus Zirn: Publisher- Packt: ISBN- 1-904811-33-7

BPEL Cookbook is not about BPEL but for Oracle BPEL Process Manager. This book contains ten case studies which ranges from real implemented business scenarios to examples listed at Oracle web site.

The book starts with very simple case study but with each new chapter complex and difficult scenario unfolds.

The book is structured into three logical parts. Part one is talking about integration using Oracle BPEL Process manager. This part covers first three case studies. Part two covers usage of Oracle BPEL Process Manager in little more complex applications including product development. This part is covered in case study number four, five and six. The last part covers SOA techniques which spans from chapter seven to ten.

My favorite case studies from book are “Building Rich Internet Applications for Workflow and Process Monitoring”, “Building BPEL Process on the fly”, Making BPEL Process Dynamic”, and “Using WSIF for Integration”.

The book is good reminder of BPEL Process Manager capabilities. The best way to read this book is to start realizing the scenarios.


Disclaimer: I did not get paid to review this book, and I do not stand to gain anything if you buy the book. I have no relationship with the publisher or the author.

Further reading: A competing book is Effective Java by Joshua Bloch http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/0321356683

One can get more information about book and related topics from:

1. Book’s web presence http://www.oracle.com/technology/pub/articles/bpel_cookbook/index.html
2. Amazon: http://www.amazon.com/BPEL-Cookbook-integration-applications-orchestration/dp/1904811337
3. Publisher – Packt- http://www.packtpub.com/BPEL-SOA/book
4. Flipkart: http://www.flipkart.com/bpel-cookbook-stany-blanvalet-jeremy/8184042388-aw23foexoc

Standards & Guidelines for TIBCO Business Works

Now it the turn of TIBCO Business Works Standards and Guidelines. This document covers following topics:

2 TIBCO Business Works 5.2 Performance Architecture
2.1 Main TIBCO Business Works Performance Components
2.1.1 Engine Processing
2.1.2 Determining the Available Memory
2.1.3 Flow Control
2.1.4 Paging Jobs
2.1.5 Paging Waiting Jobs
2.1.6 Enabling Paging
3 Best Practices
3.1 TIBCO Business Works Engine Tuning Guidelines
3.1.1 Calculating MaxJobs or Flow Limit
3.1.2 Memory Management Issues
3.1.3 Tuning Engine
3.1.4 Fault Tolerance and Load Balancing
3.2 JVM Tuning Guidelines
3.2.1 Specifying JVM Heap Size
3.2.2 Setting JVM and Processor Affinity
3.2.3 JVM Garbage Collection
3.3 TIBCO Business Works Transport and Palette Guidelines
3.3.1 HTTP/S
3.3.2 SOAP
3.3.3 JMS
3.3.4 FTP
3.3.5 JDBC
3.3.6 Transactional Activities
3.3.7 General Activities
3.4 Process and Activity Design Guidelines
3.4.1 Data and Caching
3.4.2 Checkpoints
3.4.3 Grouping Activities
3.4.4 Testing BW Process Definitions
3.4.5 Tracing in BW
3.5 Message, Payload and Schema Guidelines
3.5.1 Data Representation Guidelines for Tibco Rv and JMS
3.5.2 TIBCO Business Works Mapper Performance
3.6 Processing Large Sets of Data
3.6.1 Iterating Through Large Sets of Data Using a Mapper Activity
3.6.2 Sorting and Grouping Data
3.6.3 Large Document/Record Use Cases
3.6.4 SOA Best Practices
4 Configurations
4.1 Configuring Persistent Connections
4.2 Configuring HTTP/JMS Servers
5 Global Variables
5.1 Grouping & Sub-grouping Rules
5.2 Naming Conventions
6 Logging
6.1 Logging Rules
6.2 Logging Parameters (Details, frequency etc.)

Here is the document

TIBCO Business Works - Standards & Guidelines V1

Guidelines and Standards for TIBCO EMS

One more doc from my old laptop. Guidelines and Standards for TIBCO EMS covers

• Messaging Models

• Integration with Client API’s

• Tibco EMS Messages

• Message Structure

• Message Persistence

• Persistence vs Non-Persistence

• Character Encoding and Message Compression

• Message Compression

• Undelivered Message Queue

• Configuration EMS Parameters

• Setting tuned parameters using tibemsd.conf files

• Using other configuration files

• Configuration Properties for Queues

• Configuration Properties for Topics

• Guidelines for creating queues and topics

• Queues vs Topics

• Authentication of Tibco EMS Server

• Users and Groups

• Permissions and access control

• Administrative Control

• SSL Support in Tibco EMS

• Monitoring of EMS Server

• Log File and Message Tracing

• Server Events Monitoring

• Fault Tolerance

• Configurating Shared State

• Configuring FT Server and EMS Clients

• Advanced Features

• Routing

• Load Balancing

• Bridges

• Advanced Parameters for Queues and Topics

• Queues – Fail Safe/Preserve

• Topics – Durable

• Asynchronous vs Synchronous Consumers

• Message Acknowledgment

• Avoid Multithreading

• Flow Control, Threads and Deadlocks

• Purging Temp Queues

• Dynamic Queues and Topic

Here is doc

TIBCO EMS - Guidelines and Standards v1

Publish at Scribd or explore others: Internet & Technolog Research integration EMS

TIBCO BW 5.x Deployment Process

While going through my old laptop, I discobvered few interesting documents. This document is one of them. It explains and depicts step by step deployment process for TIBCO BusinessWorks 5.x. I hope this document will be helpful for you.

TIBCO BW 5.x Deployment Process

Publish at Scribd or explore others: How-to-Guides & Manu businessworks TIBCO

Managing Deployment Parameters in BPEL Process Manager

In BPEL PM 10.1.3.4, concept of deployment plan is introduced. I found its documention quite fuzzy and without support of examples. I have developed the same for my team and clients. I hope you will also find the same useful.

Download the word file from scribd.com. This doc also contain one process which is zipped and embedded into it.

Oracle Fusion BPEL Process Manger’s Process as Product: Architecture & Design

Recently, I architected and designed few Oracle BPEL PM processes as product for a SAAS application and systems integrating with it. The processes were developed as products so SAAS provider can sell them repeatedly to its customers.

These processes were architected & designed under following business and technical constraints and conditions:

1. Use of Oracle Fusion Middleware is mandatory.
2. Minimize the software license cost for SAAS provider and its customers.
3. Minimize development cost for SAAS provider.
4. Minimize customization cost for SAAS provider’s customers.
5. Minimize product support cost for SAAS provider and its customers.
6. Customers must be able to customize the processes.
7. With the deployment of upgraded version of process (not the BPEL Fusion Middleware upgrade), customization of customers must be preserved. Manual intervention must be minimum.
8. Processes must be designed keeping Oracle Fusion Middleware road map in sync.

So the decision on selection of Oracle Fusion Middleware was already done.

Bust still lot of architectural and design decision were to be taken.

A. The first decision was to not to use AIA framework. This decision was based on following considerations:

a. Additional license cost of AIA
b. Skills need for AIA were not available in-house and even with independent service providers. Development of skill set or getting from outside was costly in-terms of time and money.
c. AIA is pretty new kid on the block.
d. There is no clear-cut road map for AIA.

B. For processes there were two choices: BPEL PM and ESB. BPEL PM was chosen over ESB for development of processes because of:

a. Processes were quite complex and involved lot of service orchestration. So BPEL was in and ESB was out.
b. Any BPEL PM process can be registered with ESB so even if processes were developed in BPEL PM, they can be registered with ESB if required in future without any changes required in process code.
c. To reduce license cost for SAAS provider and its customers.

C. To manage Errors and Exceptions, error hospital of Oracle Fusion Middleware and especially BPEL PM. Errors & Exceptions were classified as:
a. Business
b. Application & Logic
i. Binding
ii. a
c. System
d. Miscellaneous

Retry mechanism of BPEL PM was employed to care of transient faults in IT assets like network, database, connecting systems, etc. Error & Exception Management was developed as separate collection of processes, which primarily catered to:

a. Handling of Errors & Exceptions
b. Logging of Errors & Exceptions
c. Notification of Errors & Exceptions

Individual business processes handled error & exception but Logging & Notification was completely outsourced to maximize the reuse of services across business processes.

To achieve replay of service remediation framework was developed. The options available to log and remediate errors and exceptions were:

a. JMS queue
b. Direct database store
c. Advance Queue

JMS queue was not able to win favor due to requirement of separate JMS server in enterprise, which was directly increasing investment and operational costs.

Direct database store was also not able to win positive note due to higher development & maintenance cost.

AQ was on high due to native support from Oracle Database and only one time operational cost – during first deployment: AQ enablement on database.

Compensatory services were also developed because of usage of Asynchronous processes and need to maintain transaction integrity.

D. From experience in similar products using TIBCO and SAP XI following learnings were noted:

a. Customers customize processes
b. Customers don’t like to override their customizations with introduction of newer version of processes by SAAS provider.
c. Lot of human intervention needed to preserve customization done by customers. This is error prone way.
d. Most of mapping is done in m aping where elements from source and target applications were mapped.
e. Interface definitions of source and target applications seldom changes during their lifetime. In simple language Schema of source and target message changes only when one of application changes which is rare.

To resolve these challenges two approached were evaluated:

a. Three processes based approach

To ease in handling customization by SAAS provider’s customers, each business process will be divided into three BPEL processes. For example a business process where Data flows from SAAS to Oracle eBusiness Suite, one BPEL Process will cover data fetch from and data submission to Oracle eBusiness Suite while other two will do the transformation & Mapping.






Here the idea is that in Process-2, data is mapped from SAAS Schema to eBusiness schema in the default way (SAAS Provider way). This process will deployed as separate process in BPEL Process Engine server.

The Process-3 also maps the data but it has some twist. In its mapper this process should have two input schemas (SAAS and eBusiness) and one output schema (eBusiness). The default mapping will be of one to one mapping (eBusiness to eBusiness) but client may modify as per their need.

Process -2 and Process-3 will be deployed separately and will communicate via XML. Process-2 will pass XML to process-3.

Now SAAS Provider releases second version of its product then it gives only process-1 & 2 as upgrade not the process-3. In this case client can choose not to update process-3 to preserve its customization. This approach assumes that only mapping changes from version to version not the schema.

This approach may have performance issue due to communication overhead.


b. Multiple Mapping files based approach





In this approach customer will be provided two sets of mapping. Customer will not modify Mapping-1 but Mapping-2 will be. With the new release of process, customer will retain XSL referring to Mapping-2, which will preserve his customization.


In both approaches only Mapping customizations are taken care not the changes in Schemas and upgrade in BPEL Process Manager.

The choice of approach will be decided with some performance test on the sample process.


E. Products were involving big EIS (Enterprise Information System) s and SAAS application which were serving complex business processes. Often to increase reliability and support business process are deployed different instances of EIS on the basis of geographies or business lines. So there were two possible cases:

a. n:1 scenario
b. 1:n scenario

a. n:1 scenario

In the scenario where data will be fetched from multiple Oracle eBusiness Suite and fed into single SAAS instance, multiple instances of a BPEL Process will be deployed with updated connection details for Oracle eBusiness Suite.



b. 1:n scenario

Content based routing will be achieved via switch case. To achieve 1:n (input:output systems) switch based approach is simpler and clean.



The other approach to achieve content based routing is ESB. But in ESB the targets are again defined at Design Time only. There is no way one can define target systems at deployment or run time. To reduce the number of systems involved, BPEL solution with switch case is preferred.

But option was left open to customer so if customer wishes, BPEL process can be registered at ESB and ESB based routing can be availed.