Technical Overview of

WebSphere Process Server,

WebSphere Integration Developer and

Best Practices

Presented by:
MIRACLE SOFTWARE SYSTEMS, INC.
February 16, 2007

Proprietary and Confidential

The content within is the property of Miracle Software Systems , Inc.

UNAUTHORIZED REDISTRIBUTION IS PROHIBITED

 Revision History

Author Description
01/20/07 Sandeep Document Consolidated
Gugloth

Statement of Confidentiality
This document contains information that is proprietary. As a result, this document shall not be
duplicated, in whole or in part, for any purpose other than to evaluate Miracle Software Systems, Inc.
This restriction does not limit the rights of the recipient to use information contained in the data if it is
rightfully obtained from another source without restriction.

Copyright  1994 - 2007 Miracle Software Systems, Inc. All rights reserved.
 Table of contents
1.Overview of On-Demand Business:----------------------------------------------------------------------------------------------4

2.Key business attributes:-------------------------------------------------------------------------------------------------------------4

3.Key technology attributes :---------------------------------------------------------------------------------------------------------5

4.WebSphere Process Integration programming model and Components-------------------------------------------8

5.WebSphere Process Server / WebSphere Integration Developer Components-----------------------------------9

6.WebSphere Process Server Best Practices and Naming Convention----------------------------------------------11

7.WebSphere Process Server and Integration Developer Performance Tuning-----------------------------------13

7.3Move the default messaging provider data stores to a high performance DBMS-----------------------------15

7.4Disable validation in CEI Emitter----------------------------------------------------------------------------------------------15

8.WebSphere Process Server Best practices---------------------------------------------------------------------------------16

8.1Use Micro flows instead of Macroflows if possible------------------------------------------------------------16

8.2 Avoid over-using the process engine.-------------------------------------------------------------------------------------16

8.3 Set “Transactional Behavior” to “Participate” when possible-----------------------------------------------------16

8.4 Implement intelligent (query avoiding) task claim algorithms-----------------------------------------------------17

9 Reference:-----------------------------------------------------------------------------------------------------------------------------19

WebSphere Process Server Best Practices Page 3 of 21

 1. Overview of On-Demand Business:
The vision of On Demand Business is to enable customers to succeed in an environment with an unprecedented rate of
change. Businesses want to focus on core competencies, reduce spending, and reuse existing information in new ways
without a major overhaul of their existing infrastructures. There exists a constant pressure to juggle the often conflicting
demands to provide flexibility, cost savings, and efficiency. The sections that follow outline the key business and
technical attributes that provide the basis for the on demand message.
Figure 1-1 identifies the key components of On Demand Business.

2. Key business attributes:

From a business perspective, On Demand Business is about providing a way for companies to realign their business and
technology environments to match the request for reusable business functionality. Business drivers can be summarized
with the following key elements:
Focused
The enterprise can focus on their core competencies: what makes them successful and what makes them unique.
Strategic alliances are formed to provide needs external to these core competencies.

Responsive
The business can respond with agility to customer demands, market opportunities, or external threats. These decisions
are guided through insight-driven decision management features.

WebSphere Process Server Best Practices Page 4 of 21

Variable
The enterprise can achieve operational and business process flexibility and adapt variable cost structures (fixed to
variable) to provide a high level of operational efficiency.

Resilient
The business can respond robustly to changes in both business and technical environments, managing changes and
threats with predictable outcomes. Companies can achieve these business imperatives by exploiting current
technological developments while drawing on experiences that have been learned from past architectural builds.

3. Key technology attributes :

The business drivers of On Demand Business must be supported by a well-defined technical infrastructure. The following
key technological attributes deliver the flexibility, responsiveness, and efficiency that organizations require:

• Integration
• Virtualization
• Automation
• Open standards

Figure 1-2 provides a high-level overview of the range of each On Demand Business attribute.

WebSphere Process Server Best Practices Page 5 of 21

Integration
The fundamental component of an infrastructure designed for On Demand Business is integration. “An enterprise whose
business processes, integrated end-to-end with key partners, suppliers, and customers, can rapidly respond to any
customer demand, market opportunity, or external threat.”
Integration can occur at various levels:
People
To function at an operating level that is suitable for On Demand Business, human-to-human and human-to-process
interaction requires integration throughout the various levels that is not limited to those who use the finished products.
Business partners, customers, and employees are all important resources for the value chain provided by On Demand
Business. For example, integration can occur for developers through open tooling paradigms that are based on open
standards, for business partners through the creation of horizontal processes, and for employees through collaboration.
Process
Recurring elements (security, service level, monitoring, and so on) can be shared by applications to provide horizontal
services for decoupling these reusable application components. The use of SOA and Web services to implement these
processes, including the emerging Business Process Execution Language for Web Services (BPEL4WS), is likely to
facilitate more rapid changes in these processes so that the business can respond with agility to changing market
conditions.
Applications
Organizations have invested enormous resources and capital into custom designed and off-the shelf applications. The
application integration goal is to leverage, rather than replace, these assets by providing ways of connecting, routing,
and transforming the data that is stored or shared among them. Applications sit on disparate systems in an enterprise or
are installed throughout many enterprises.
Systems
Systems manage, process, and deliver data to the people and applications in the solution environment. An On Demand
Business Operating Environment requires the system to be invisible to the elements that interact with it.
Data
Data is the primary business element of a system. The data is the source of the information and can more easily be
shared through the adoption of standards specifications.
Virtualization
Various areas of technology in our lives exploit virtualization concepts, including cell phones, personal digital assistants,
wireless connectivity, printers, and so forth. Aspects of virtualization draw on widely adopted architectural concepts,
including object oriented design and development, Web services, and XML.

There is a spectrum of virtualization that begins with independent stand-alone systems on one side (a large mainframe
system, perhaps) and grid computing on the other. In the middle are varying degrees of client-server implementations.
A grid paradigm, an absolute example of on demand virtualization, is a collection of distributed computing resources that
are available over a local or wide area network and that appear to a user or application as one large virtual computing
system.
The Internet, the most widely recognized example of virtualization, provides a virtual network that supplies access to
content and applications.

The vision is to create virtual dynamic organizations with secure, coordinated resource-sharing between individuals,
institutions, and resources. Grid computing is an approach to distributed computing that spans locations,organizations,
machine architectures, and software boundaries.

WebSphere Process Server Best Practices Page 6 of 21

 Figure 1-1 depicts virtualization as a set of virtualized resource pools based on:

Servers
This might include partitioning, hyper visors, VM OS, emulators, I/O virtualization, virtual Ethernet, and so forth.

Storage
Here, the focus is on the addition of intelligence and value in the network.

Distributed systems
This includes Web services, scheduling, provisioning, workload management, billing and metering, and transaction
management. The goal of grid computing, and thus on demand virtualization, is to provide unlimited power, collaboration,
and information access to everyone connected to a grid.
Automation
Autonomic computing addresses the need of an organization to limit the amount of time and cost that occurs as a result
of: Over provisioning, New applications and highly skilled labor, Disparate technology platforms even within one
organization, Focus on maintenance, not problem resolution, Complexities in operating heterogeneous systems
So how can organizations begin to address these common concerns by using On Demand Business? This is where
autonomic computing comes in. Autonomic computing can be summarized by four key components:

• Self-healing
For a system to keep functioning, it must detect, prevent, and recover from disruptions with minimal or no
human intervention. This requirement is directly proportional to increased business dependence on
technology
• Self-configuring
The system can adapt dynamically to changing environments, add and remove components to and from
the systems, and change the environment to adapt to variable workloads.
• Self-optimization
Configuration that maximizes operational efficiency, including resource tuning and workload
management, alleviates the constant drain on resources to perform routine tasks. The goal is to tune
systems to respond to the workload changes. Systems must monitor and self-tune continuously,
adapting and learning from the environment around them.
• Self-protecting
Security is one of the inhibitors of the adoption of SOAs as organizations prepare themselves to share
data externally. Self-protection requires the system to provide safe alternatives for securing information and
data. Self-protecting automation works by anticipating, detecting, identifying, and protecting systems from
external or internal threats.

Open standards

WebSphere Process Server Best Practices Page 7 of 21

Open standards affect the On Demand Business Operating Environment across the previously defined levels, including
automation, integration, and virtualization. Each of these elements leverage open standards specifications to achieve
their objectives. Open standards are the key element of flexibility and interoperability throughout heterogeneous
systems. The global adoption of a standard specification enables the disparate systems to interact with each other. The
underlying platforms might be completely different and independent, but open standards enable processes to be built
despite (or because of) these differences. Open standards provide the On Demand Business Operating Environment
with a standard, open mechanism to invoke system services.

4. WebSphere Process Integration programming model and Components

The Key to Business Flexibility

“The flexibility to treat elements of business process and the underlying IT infrastructure as standardized
components (services) that can be reused and combined to address the changing business priorities.“

The basis of Service Oriented Architecture starts with business processes. A service is a business task that provides
some business function through a well defined interface. The use of the service is independent of the IT infrastructure
needed to accomplish the task. Each service then becomes a building block that, when combined with other services can
provides a flexible solution to real business problem, allowing the creation of new and modified processes easily. A key
to this is the strong link between the uses of services and how those services make use of the underlying IT
infrastructure. The use of the standards based technologies; including Web Services, help to make the SOA vision a
reality.
Programming Model today
WebSphere Process Integration introduces a new programming model. It is extremely important to understand this
fundamental change in how applications are developed in order to understand the functionality provided in
WebSphere Process Server and WebSphere Integration Developer. The figure depicts the programming model as it
exists without WebSphere Process Integration. Manipulation and handling of data is the core purpose and reason
for all business processes.

There are currently various ways that data can be represented, including a JDBC row set from a relational database, a
JMS message, JCA data coming in from an external application, a JAXB object, or an EJB entity bean.

WebSphere Process Server Best Practices Page 8 of 21

Multiple ways of representing data require multiple ways of interacting with data. Invocation is the way in which a
request is made from one piece of code to another. There are a variety of ways to invoke processes to obtain and work
with data.
Current methods of invocation include EJB stateless session beans, JAX-RPC, JDBC for communicating with databases,
JCA for adapters, and JMS for messaging.
To build a solution you must be able to put together multiple invocations for data access and the processing that acts
upon that data. Composition defines how to assemble a series of invocations that work on data to construct a complete
process.
This can also be done in a variety of ways, including using Java with either a Java Bean or a stateless session bean,
WebSphere Interchange Server collaborations, Flow Definition Language, and Business Process Execution Language.
All business process solutions are a composition of invocations that operate on data. With so many different
mechanisms for doing this there is a need for many different kinds of skills to develop business processes. Also, the form
data takes can dictate the form of invocation and composition that might not always yield the optimal approach.
Programming Model – Simplification

The programming model used with WebSphere Process Integration also involves building business possesses by
composing a series of invocations that act on data. However, with WebSphere Process Integration there is a simplified
style in which this is done.

Data is defined using Service Data Objects (SDO). SDO provides an abstraction that can be used over various types of
data, providing a common mechanism for accessing data. SDO are extended to provide additional functionality needed
for process integration scenarios and are referred to as Business Objects.

Invocation is done using Service Component Architecture. SCA provides a standardized way to define and invoke
services. The services are associated with different kinds of bindings so that the underlying invocations can be done with
various invocation models, such as JMS or Web Services.

Composition is done using Business Process Execution Language (BPEL), which is used to define the overall business
process. When the business process accesses data, it does so by making calls to SCA services passing Business
Objects.

5. WebSphere Process Server / WebSphere Integration Developer Components

WebSphere Process Server Best Practices Page 9 of 21

 This following figure provides an overview of the components that make up the WebSphere Process Server and are
enabled by the WebSphere Integration Developer. The WebSphere Process Server is built on WebSphere
Application Server Version 6, providing a robust J2EE application server runtime with capabilities that the process
server implementation can exploit such as JMS messaging and enterprise beans. It can also make use of the
application server qualities of service such as transactions, security and clustering. Overall, this provides a well
proven runtime environment for WebSphere Process Server.

The Service Oriented Architecture (SOA) Core is the foundation in WebSphere Process Server. The main components of
the SOA Core are the Service Component Architecture (SCA), Business Objects (BOs) and the Common Event
Infrastructure (CEI). SCA is the uniform programming and invocation model for business services that publish or
operate on business data. This is one of the key components of the new programming model discussed on the previous
slide. Business Objects (BOs) represent the data that is passed within that framework. Business objects are extensions
to Service Data Objects (SDOs), which carry additional information needed for some integration scenarios. SDOs in the
form of Business Objects are another of the key components of the new programming model. The Common Event
Infrastructure (CEI) provides the foundation architecture for the management and handling of events produced by
business processes. This is essential for enabling the monitoring of business processes with products such as the
WebSphere Business Monitor.

On top of the SOA Core are a set of Supporting Services, which provide the transformation primitives required by
integration scenarios built using Service Component Architecture and Business Objects. Interface maps are used to
enable components making use of a particular interface to make calls to a component that provides a semantically
similar but syntactically different interface. Business object maps enable the transformation of business data between
fields of Business Objects representing the same business entity but of differing types. Relationships enable the
correlation and synchronization of data representing the same business entity stored in multiple back end systems.
Selectors provide for a dynamic invocation of a target component based on a date and time criteria.

Business Processes are a fundamental part of the programming model, providing the composition aspect of the
programming model. In WebSphere Process Server, the business processes are defined using BPEL.Business
processes provide an implementation of a process model that describes the logical order in which the different activities
of the process are being executed, making calls out to the individual SCA services that implement the specific activities.
As a result, a business process is the set of business-related activities, rules and conditions that are invoked in a defined
sequence to achieve a business goal.

WebSphere Process Server Best Practices Page 10 of 21

Human Tasks are enabled by the Human Task Manager and provide the human task capabilities for WebSphere
Process Server. Human Tasks allow people to participate in a business process in a machine-to-human scenario, a
human-to-machine scenario and in a human-to-human scenario. In the machine-to-human scenario an automated
process creates tasks for people who participate in the execution of a business process, whereas the human-to-machine
scenario allows a person to create a task that is executed by an automated service. The human-to-human scenario
allows a task to be created by a person for another person. Human tasks can be integrated directly into the BPEL for a
business process or can be packaged as an SCA component for use by any client that can invoke an SCA component.

Business State Machines are another way of modeling a business process. There are some processes that are highly
event driven and are well suited to being thought of in terms of a state transition diagram. For example, a business
process for order processing has to deal with the fact that an order can be canceled at any time during the order process
up until the order is actually shipped. It can be difficult to model these kinds of processes in a business process. The
Business State Machine component allows you to model the business process using similar constructs as UML 2.0 state
machine support, and then generates BPEL for the implementation.

Business rules are a means of implementing and enforcing business policy through externalization of business function.
Externalization enables the business rules to be managed independently from other aspects of an application. This
independence allows for dynamic updating capabilities of the business rules to provide for a more agile business. There
are two styles of business rules, if then rule sets and decision tables. A Web client is provided where the parameters of
business rules can be changed by a business user using a natural language specification of these rules rather than
requiring an application developer or integration developer to change the application.

Adapters in Process Integrations

Adapters are used within process integration for doing enterprise integration of various applications and back end
systems that are external to the WebSphere Process Server. Adapters are integrated into the system using a service
oriented approach and are fully compatible with the service component architecture. The functionality of an enterprise
system is encapsulated by an adapter and business objects are used to pass data back and forth between the process
server and the enterprise system. The use of business objects and service component architecture allow adapters to fit
perfectly into the new programming model for the process server. The use of adapters provides a consistent framework
for accessing backend systems and a consistent way to configure, deploy, and administer the adapters. Adapters can
be categorized as application adapters or technology adapters. Application adapters are used for connecting to specific
applications such as PeopleSoft, SAP or Siebel whereas technology adapters are used for using a specific technology
for interfacing with a backend system. For example, a JDBC adapter could be used for interacting with DB2 or with
Oracle databases. In addition to how adapters can be categorized, there are two major types or styles of adapters that
can be used with the WebSphere Process Server. The WBI Adapters are the existing adapters that are used today with
the WebSphere Interchange Server and other brokers. The WebSphere Adapters are new as part of WebSphere
Process Integration and are compliant with the Java Connector Architecture (JCA) 1.5 specifications.

6. WebSphere Process Server Best Practices and Naming Convention

Naming conventions make programs more understandable by making them easier to read. They can also give
information about the function of the identifier-for example, whether it's a constant, package, or class-which can be
helpful in understanding the code. Some of the naming conventions and best practices followed in WebSphere Process
Server are as follows.

WebSphere Process Server Best Practices Page 11 of 21

 COMPONENT NAME FormaT

Library {LB}{‘_’}{DESCRIPTIVE IDENTFIER}

Business Process {BP}[{‘_’}{Process main functionality}]

Module {MP|MA}{‘_’}[{Adapter Type}]{DESCRIPTIVE IDENTFIER}

DataType Generic Data: {DG}[{‘_’}{Generic Name}]

Application Specific Data: {DA}[{‘_’}{APP}{Application
Specific Name}]

Interfaces Interfaces: {IF}{‘_’}{Interface Name}

{IG}{‘_’}{Interface Name}
{IA}{‘_’}{Interface Name}

Business Object Maps {MD}{‘_’}{Source Data Type}_to_{ Dest Data Type}

Interface Maps {MI}{‘_’}{Source Interface}_to_{ Dest Interface}

Relationships {RE}{‘_’}{relationship functionality}

Adapters (Connectors) {AD}{‘_’}{Adapter Type}{‘_’}{SYSTEM_IDENTIFIER}

WebSphere Process Server Best Practices Page 12 of 21

 Human Tasks {HT}{‘_’}{Human Task main functionality}

7. WebSphere Process Server and Integration Developer Performance Tuning

In order to optimize performance it is usually necessary to configure the system differently than the default settings. This
section lists several areas to consider during system tuning. This includes both tuning the WPS, WID, and WA products,
and also other products in the system. As an example, WPS supports different database managers. The documentation
for each of these products contains a wealth of information regarding performance, capacity planning and configuration.
Assuming that all these issues have been addressed from the perspective of the actual product, additional levels of
performance implications are introduced at the interface between these products and the WPS or WebSphere Adapters.

7.1 Configure Threads for Messaging and in Work Managers

The Platform Messaging Component SPI Resource Adapter is created as part of an application install. It provides an
EIS with the ability to communicate with message driven beans configured on the server. Message processing for
an application uses properties defined under an activation specification for this resource adapter.
The maxConcurrency custom property under the J2C activation specification for the resource adapter is used to
specify the number of threads available to process messages by the application.
If a work manager is used, set the Maximum number of threads to a value high enough to prevent the thread pool
from running out of threads. This can be set in the administrative console under Asynchronous beans → work
managers.
One symptom of insufficient concurrency will be CPU idleness. Vary the concurrency to achieve maximum CPU
utilization and throughput.

7.2 Configure WebSphere Process Server for clustering

When tuning to achieve the best possible horizontal scalability through clustering, additional WebSphere Process
Server configuration is required.

Configure the activation specification properties

Each SCA module defines a message-driven bean (MDB) and its corresponding activation specification. The default
value for maxConcurrency of the SCA module MDB is 10, meaning only up to 10 asynchronous SCA requests in the
module can be processed concurrently. If the server CPU is not maxed out, it sometimes is caused by this setting
being too low; it needs to be increased.

• Open Resource Adapters → Platform Messaging Component SPI Resource Adapter → J2C activation
specification.
• Select the SCA module activation specification.
• Click on J2C activation specification custom properties.
• Change maxConcurrency to a higher value.

WebSphere Process Server Best Practices Page 13 of 21

 Configure the ORB thread pool

This configuration parameter is relevant if the cluster is driven by a driver node through the SCA synchronous
binding.
Due to the interaction between synchronous SCA, workload management (WLM), and the ORB, the ORB thread
pool size on the cluster nodes needs to be configured to maximize the clustering throughput. The rule of the thumb
is to use the same number of ORB threads on all application nodes, and have the total number of ORB threads
across all application nodes be the same as the number of driver threads on the driver node. For example, if the
driver uses 120 concurrent threads, the ORB thread pool size on each application node on a 6-node cluster should
be 20.
The default value of ORB thread is 50.
To set this value, navigate to Servers → Application servers → <server_name> →Container Services → ORB
Service → Thread Pool. Complete the Maximum Size field.

Configure relationship and BPE data source connection pools

The maximum connections property of the relationship data source should be large enough to allow concurrent
access to the database from all threads. For the clustered measurements in the test lab, this property was set to 2
times the largest value of the WebContainer, ORB, or the default thread pool size. The multiplier of 2 comes from
the fact that each transaction in the test run could contain two relationship database accesses. If your application
contains more or less relationship database access, you need to adjust the multiplier accordingly.
The maximum connections property of the BPE data source should be large enough to allow concurrent access to
the database from all threads. It should be larger than the largest value of the WebContainer, ORB, or the default
thread pool size.
To set maximum connections for a data source navigate to Resources → JDBC Providers → <JDBC provider
name> → Data sources → <Data source name> →Connection pool properties. Complete the Maximum connections
field.
To find the Web container thread pool size navigate to Servers → Application servers → <server_name> → Thread
Pools → WebContainer. The value is in the Maximum Size field.
The maximum connections for the ORB service can be found by navigating to Servers → Application servers →
<server_name> → Container Services → ORB Service → Thread Pool. The value is in the Maximum Size field.
To find the default thread pool size, navigate to Servers → Application servers → <server_name> → Thread Pools
→ Default. The value is in the Maximum Size field.

Configure IBM HTTP server

On the driver node, set the com.ibm.websphere.webservices.http.maxConnection system property to 200. The
default is 50. In the performance tests in a clustered environment, more than 50 driver threads were needed to max
out the CPU on six cluster members.

In httpd.conf for the IBM HTTP server, set MaxSpareThreads to 200 (default is 75). This enables more than 75
driver threads, which was needed for the clustered workload performance tests using Webservices to run without
errors.

Configure the JMSImport connection factory

WebSphere Process Server Best Practices Page 14 of 21

 The maximum connections property of the JMSImport Connection Factory (SAPAdpt.JMSImport_CF) connection
pool should be large enough to provide a connection for every driver thread. The default is 10.

7.3 Move the default messaging provider data stores to a high performance DBMS

The messaging engine data stores are automatically created during profile creation on Cloudscape without
allowing any user choice.
Create alternative data stores for the messaging engines on DB2.
For information on setting up the data store for a messaging engine see:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?
topic=/com.ibm.websphere.pmc.nd.doc/tasks/tjm0030_.html

7.4 Disable validation in CEI Emitter

The default behavior of CEI event emitters is to validate the events to ensure that all fields are correctly filled. This is
unnecessary for events generated by the WebSphere Process Server system.

To disable event validation, a custom property needs to be added to the emitter factory profile:
Navigate to Resources → CEI Infrastructure Provider (cell scope) → Emitter Factory Profile → Default Common
Event Infrastructure emitter → Custom Properties
Add a new property with name validateEvent with value set to false.

Tuning Checklist

WebSphere Process Server

• Do not run production server in “development mode”
• Disable Tracing and Monitoring
• Move databases off of the default Cloudscape
• Configure Threads for Messaging and in Work Managers
• Use an appropriate Java Heap size for Production Environments

WebSphere Adapters
• Disable Tracing and Monitoring
• Move databases off of the default Cloudscape
• Configure Polling Frequency and Quantity

Database (General)

• Use a production quality database (such as DB2)

WebSphere Process Server Best Practices Page 15 of 21

 • Place Database Table spaces on a Fast Disk Subsystem
• Size Database Cross-Referencing Tables Correctly
• Place Logs on Separate Device from Table Spaces

Database (DB2 Specific)

• Maintain Current Indexes on Tables
• Update Catalog Statistics
• Set Buffer Pool Size Correctly

Java
• Set the Heap and Nursery Size (where applicable) To Handle Garbage Collection Efficiently
• Set AIX Threading Parameters
• Use Hotspot Server instead of Client (where applicable)
• Set Thread Stack Size if Using Many Threads
• Reduce or Increase Heap Size if java.lang.OutofMemory occurs

8. WebSphere Process Server Best practices

8.1 Use Micro flows instead of Macroflows if possible

Remember, micro flows can be 100x faster than macro flows.

If target applications respond “quickly”, use microflows and synchronous bindings to target applications.
Carefully plan macro flow use and consider impacts to capacity plan.
Call Micro flows as sub processes of a “human interaction” Macroflow parent process.

8.2 Avoid over-using the process engine.

A process and its individual steps should have “business significance”.

Use normal implementation techniques (servlets, beans, POJO) for “logic” that has no business
significance.

8.3 Set “Transactional Behavior” to “Participate” when possible

This setting allows the current activity to run in the transaction context of the previous activity.
The default setting for “Transactional Behavior” is “Commit After” which causes each activity to run in its own
transaction

WebSphere Process Server Best Practices Page 16 of 21

 8.4 Implement intelligent (query avoiding) task claim algorithms
Utilize a list of applicable claims instead of a single claim for cases where a claim may fail.
Claim a random task from a list of claims.
Limit the size of a work list by setting a size threshold.
Consider using client side caching of queries.
Consider custom query workarounds where process metadata is held separate from the process data (using
database query best practices).
Avoid using BPC Explorer in high load situations.

8.5 Minimize the number of Java Snippets by initializing as many variables as possible
with a single Snippet
Activities implemented as Java snippets are faster than other WPS components. Implement business processes
using Java snippets as appropriate.
Java snippets do not support raising faults.

8.6 Synchronous invocations are faster than asynchronous invocations since

asynchronous binding require queuing. Use Sync instead of Async if possible
Intra-module async calls are “queued”
Inter-module async calls encounter more “queues” than for intra-module async calls
At the import and at the target (export)

8.7 Use POJOs to isolate intra-module calls that must be asynchronous

Nature of interaction may be propagated downstream
Interface Maps force same interaction style on both sides. If an interface map is invoked async, async interaction is
forced to the component immediately downstream from map – no longer true in 6.0.1.1+

8.8 Do not use the default path to install WID, choose the shortest possible path
Also use the shortest possible path for server profile directory and workspace paths

8.9 Modules and Shared Libraries

After deployment, if shared resources change in the library, ALL modules using the resources have to be re-
deployed

8.10 Do not put any user logic into generated EJB and Web modules

Project > Clean action will delete them!

8.11 Perform a clean on the BI module project build before exporting as an EAR

WebSphere Process Server Best Practices Page 17 of 21

 It's always good to perform a clean build before exporting your application from WID to ensure that all the projects
are in sync

8.12 Minimize component name lengths

Having component with long names, results in deployment failure on Windows operating system due to exceeding
the path length limit.
Define your own naming conventions that make development and business sense.

8.13 When defining Interfaces, wrap primitives in business objects

Wrapping all arguments as business objects will result in the data types being handled correctly by SCA

8.14 Avoid concurrent modifications

Optimistic setting for Team Environment in not recommended unless users are very familiar with the artifact files at
the text level (for example, XSD for BOs).

8.15 Separate namespaces in business objects

If working with more than one business object, it is best to put each one in a separate namespace. If they are put in
the same namespace, then all of the business objects get loaded each time a namespace is called, and the overall
performance of the tool degrades.

8.16 Disable monitoring and tracing whenever possible

Monitoring and tracing is significant performance hit. The default configuration WebSphere Process Server has
performance critical logs switched off by default. However double check that tracing, debugging and performance
monitoring is switched off.

8.17 Do not use cloudscape database for production environments

WebSphere Process Server uses cloudscape database by default. Using cloudscape database simplifies the
configuration however it is not designed for production environment where high availability and performance are
important.

8.18 Tune statement cache for long running processes

BPEL macro flows (long-running processes) make extensive use of the database for persisting data relevant to the
process. Persisting various data results in the usage of many different statements, far more than the default capacity
of the data source’s cache. This results in an excessive number of cache misses, making the caching ineffective.
This problem can be resolved by increasing the size of the cache.

8.19 Use an appropriate Java Heap size for Production Environments

Small Java heap size results in frequent garbage collection. High Java heap size results in long garbage collection
cycles. Refer to documentation of the used Java Virtual Machine (JVM) for more details.

8.20 Do not use the Unit Test Environment (UTE) for performance measurement

WebSphere Process Server Best Practices Page 18 of 21

 8.21 Do not run a production server in development mode

8.22 Setup repositories to avoid concurrent modification of files

8.23 Do not check in any generated artifacts into a team repository

8.24 Check-in/Check-out only the file in the Business Integration view

9 Reference:

1. Technical Overview of WebSphere Process Server and WebSphere Integration Developer

http://www.redbooks.ibm.com/abstracts/redp4041.html?Open
2. WebSphere Business Integration V6.0.2 Performance Tuning
http://www.redbooks.ibm.com/redpieces/abstracts/redp4304.html?Open
3. WebSphere Process Integration Version 6.0 information center
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp
4. WebSphere Application Server Performance URL
http://www.ibm.com/software/webservers/appserv/was/performance.html
5. WebSphere Business Integration Adapters: An Adapter Development and WebSphere
6. Business Integration Solution
http://www.redbooks.ibm.com/abstracts/sg246345.html?Open

WebSphere Process Server Best Practices Page 19 of 21

About the authors:

Prasad V Lokam
Prasad V Lokam is the Chief Architect at Miracle Software Systems, Inc. He has over 15 years of Systems Integration &
Business Integration consulting experience with some of the Fortune 500 companies which spans across Enterprise
Architecture, Business Integration Architectures, Definitions, Business Process Management & Optimization, Technology
Portfolio Management, Planning and Implementation.
Email: plokam@miraclesoft.com / 1-248-233-1187

Sai Kastury
Sai Kastury is the Enterprise Architect at Miracle Software Systems, Inc. He has over 10 years of Systems Integration &
Business Integration consulting experience with Business Integration Architectures and Business Process Management
& Optimization.
Email: vkastury@miraclesoft.com / 1-248-233-1169

Sandeep Gugloth
Sandeep gugloth is a WPS expert at Miracle Software Systems, Inc. His primary focus has been on the Process
Integration space. He has several years of experience helping various customers across Manufacturing and Healthcare
domains using IBM Process Integration Technologies.
Email: sgugloth@miraclesoft.com / 1-248-233-1173

Rajesh Garlanka
Rajesh Garlanka is an Integration Specialist at Miracle Software Systems, Inc. His primary focus has been on the
Business Integration space. He has several years of experience helping various customers across Telecom,
Manufacturing, and Retail domains using IBM Business Integration Technologies.

Email: rgarlanka@miraclesoft.com

Copyright 2007 © Miracle Software System, Inc.

Miracle acknowledges the proprietary rights of the trademarks and product name of the other companies mentioned in
this paper. The information provided in this document is intended for the sole use of the recipient and for educational
purposes only. Miracles make no express of implied warranties relating to the information contained in this document or
to any derived results obtained by the recipient from the use of the information in the document. Miracle further does not
guarantee the sequence, timeliness, accuracy or completeness of the Information and will not be liable in any way to the

WebSphere Process Server Best Practices Page 20 of 21

recipient for any delays, inaccuracies, errors in, or omissions of, any of the information of in the transmission thereof, of
for any damages arising there from. Opinions and forecasts constitute our judgment at the time of release and are
subject to change without notice. This document does not contain information provided to us in confidence by our clients

WebSphere Process Server Best Practices Page 21 of 21