Standards and Best Practices On Process Server and WID

NYSDOL Standards and Best Practices
Standards and Best Practices on Process Server and WID
Prepared by
Srikanth Metlakunta and Vijai Singh
Standards and Best Practices on Process Server and WID Page 1 of 36

Version: 1.0 Last Modified: 2/10/2009
Control Page:
Revision History:
Version No Revised Date Author Comments
1.0
Acknowledgements:
Name of the person, team.

Table of Contents:
1 Introduction: ............................................................................................................................ 5
1.1 Purpose: ......................................................................................................................... 5
2 General Guidelines: ................................................................................................................ 5
2.1 Process Selection:.......................................................................................................... 5
2.2 Guidelines to Process Implementation .......................................................................... 7
2.3 Guidelines to Service Design ......................................................................................... 7
3 WID Standards:....................................................................................................................... 7
3.1 Type of Activities ............................................................................................................ 7
3.2 Data Handling................................................................................................................. 7
3.3 Correlation Set ............................................................................................................... 8
3.4 Compensation Handler .................................................................................................. 8
3.5 Dynamicity...................................................................................................................... 8
3.6 Business Rules............................................................................................................... 9
3.7 Selector ........................................................................................................................ 11
3.8 State Machine .............................................................................................................. 12
3.9 Business Processes..................................................................................................... 12
3.10 How to choose between a Business Process and a State Machine............................ 13
3.11 Business Objects.......................................................................................................... 13
3.12 Business Object Map ................................................................................................... 14
3.13 Libraries........................................................................................................................ 15
3.14 Changing Dependency without the Editor.................................................................... 15
3.15 Module Isolation with Intermediate Module.................................................................. 15
3.16 Uninstall from workspace after testing ......................................................................... 16
3.17 Clean Server Startup.................................................................................................... 16
3.18 Review XSD File for Error ............................................................................................ 17
3.19 Data Handling............................................................................................................... 18
3.20 Check for WPS and WID Update ................................................................................. 18
3.21 Use Capabilities and Perspectives............................................................................... 19
3.22 Working with Java Code .............................................................................................. 20
3.23 Change Management................................................................................................... 20
3.24 Project Interchange Files ............................................................................................. 20
3.25 Business Objects for Imports and Exports................................................................... 20
3.26 Import ........................................................................................................................... 21
3.27 Export ........................................................................................................................... 21
3.28 BPEL (Business Process Execution Language) .......................................................... 22
3.29 Process Debuggers...................................................................................................... 22
3.30 Rapid Development with WID ...................................................................................... 22
3.31 Common Event Infrastructure ...................................................................................... 23
3.32 Local History................................................................................................................. 23
3.33 Performance Best Practices......................................................................................... 23
3.34 Mediation Module ......................................................................................................... 24
3.35 Interface Maps.............................................................................................................. 24
3.36 Reference Partner ........................................................................................................ 25
3.37 Human Tasks ............................................................................................................... 25
3.38 Variables ...................................................................................................................... 26
3.39 Snippets ....................................................................................................................... 26
3.40 Remove Emulators....................................................................................................... 27
4 Tips and Techniques:............................................................................................................ 27
5 Appendix: .............................................................................................................................. 28
5.1 SOA Life Cycle and IBM Products: .............................................................................. 28
5.2 Overview of Process Integration Model: ...................................................................... 29

5.2.1 Data Level: .......................................................................................................... 29

5.2.2 Invocation Level................................................................................................... 29
5.2.3 Composition Level ............................................................................................... 30
5.3 Process Server Architecture: ....................................................................................... 30
5.3.1 SOA Core Layer: ................................................................................................. 30
5.3.2 Supporting Services ............................................................................................ 31
5.3.3 Service Components ........................................................................................... 31
5.4 SCA Details: ................................................................................................................. 32
5.4.1 SCA Interface: ..................................................................................................... 32
5.4.2 SCA Implementation............................................................................................ 32
5.4.3 SCA References.................................................................................................. 33
5.4.4 Selectors.............................................................................................................. 33
5.5 Typical Development Process:..................................................................................... 33
5.6 Abbreviations Used: ..................................................................................................... 34
5.7 Acronyms Used: ........................................................................................................... 35
6 References:........................................................................................................................... 35
6.1 Bibliography:................................................................................................................. 35

1 Introduction:
In the DOL P&T SOA development environment, SDLC standards documents are developed
collaboratively by all parties impacted by and involved in the software development process. The
Architecture Group (EPAS) coordinates the process to develop the standards, and then publishes
the standards on their page of the P&T website. It is understood that given the ever-changing
environment of software development, these standards are to be viewed as living documents. In
addition, as experience evolves our best practices, it is expected that these standards documents
will evolve as well.
SDLC staff may initiate a change request to any of these standards documents by contacting (in
the form of an email), the manager of the Architecture Group.
1.1 Purpose:
This document details the standard artifacts (documents) that will be used by Business Analysts,
Enterprise Architects, Solution Architects and others in the process of defining and designing
business processes, models, and services.
It is expected that the process of service definition begins with the examination of service
candidates produced by the Business Analysts in the modeling phase using the WebSphere
Business Modeling (WBM) tool (See WebSphere Business Modeling Standards and WBM
Standards(integrationToWID)). Once the models are integrated into the Process Server
environment via WID (Websphere Integration Developer), architects and developers can then use
the very powerful tools in Process Server to assist in converting the business rules and business
processes into the runtime services and processes that function as the core of DOL’s SOA
environment.
2 General Guidelines:
2.1 Process Selection:
A business process is any system or procedure that an organization uses to achieve a larger
business goal. When you break it down, you see that a business process is actually a series of
individual tasks, and each task is executed in a specific order.
A microflow is a process that is contained within a single transaction. This is ideal for situations
where the user is expecting an immediate response. A long running process executes over an
extended period of time, and is much more flexible and resilient than a micro flow.
Long-running processes
A long-running process executes over an extended period of time and is asynchronous in nature.
It is used most commonly with services that might not respond immediately, in particular
human tasks. Interruptible business processes and asynchronous business processes are
examples of long running processes. When a business process is interruptible, it is long running,
and execution stops at specific activities and does not continue until an appropriate action takes
place.
Typically, components that are implemented as long running processes are called
asynchronous, which means that a client calls them and then proceeds to do other work
while waiting for a reply.
When a process is paused, it is waiting. You decide what it waits for. For example, you might
decide that the process needs instruction from a human before continuing, or you might decide
that it cannot proceed until it has specific input from a partner.

Long Running Processes are also much more resource intensive than microflows, and their
runtime cost is a major architectural consideration. “Resource intensive” includes not just higher
execution time to transition a process, but the transactional overhead and issues with the
database; for a high-volume Long Running Process, database tuning is a major production
consideration. Interruptible business processes and asynchronous business processes are
examples of long running processes.
Microflows
A microflow is a non-interruptible business process and runs within a single transaction. Because
it runs automatically from start to finish, it is ideal for situations where the user is expecting an
immediate response and does not require the use of a human task. Microflows are an IBM
extension to BPEL.
A microflow has the following characteristics:
Runs in one transaction or activity session
Normally runs for a short time
Is in a transient state and, therefore, is not stored in the runtime database
Typically invokes services synchronously
Can have only non-interruptible child processes
Cannot contain:
– Human tasks
– Wait activities
– Non-initiating receive activities or pick activities
Microflows are faster than long-running processes. Thus, you need to use them
when possible. For example, you can attempt to decompose a long-running
process into multiple processes using microflows when possible.
Choosing between long running processes and microflows:
Followings are the guidelines to decide when to choose long running process and when to
choose micro flow.
1. A micro flow is based on a single transaction while long running process is multi
transactional and runs for a long time.
2. When using a human task, you should use long running process.
3. If the process is waiting for an external input like an event or human task, implement it as
a long running process.
4. If there are short steps in the model and you want to implement it quickly in the runtime
environment, use micro flow. By default the process is a micro flow process.
5. If you are using a single transaction in your process, use a micro flow process. Micro flow
offers great performance compare to long running process.
Naming Business Processes:

• Mixed case with a capital first letter
• Internal words start with capital letters
• Names should be meaningful
• Should be mnemonic- indicate the intent of its use
• It may be a good idea to suffix the Process with “Process”
• Example: GetNewsArticlesProcess, PortfolioEvaluatorProcess etc.
• Namespace:http://www.labor.state.ny.us/bca/process etc.
• Folder/package: gov.nysdol.bca.process, etc.

2.2 Guidelines to Process Implementation
1. A process can be invoked in two ways – a synchronous invocation or an asynchronous

invocation.
2. Synchronous Invocation of a process- response is received only after the completion of
the process. Synchronous invocation should be chosen when the process is short
running and user is expecting the response without a delay
3. Asynchronous invocation of a process means that the process responds immediately at
the invocation and the response may take time.
2.3 Guidelines to Service Design
1. Our approach of design is top-down, not bottom-up.

2. Services should be defined by explicit, implementation-independent interfaces.
3. Services design should be loosely bound and protocols independent.
4. Service Virtualization-Services should be oblivious to consumers in terms of
implementation details, location and platforms etc.
3 WID Standards:
3.1 Type of Activities
There are two types of activities:
Basic activities-
1. receive
2. reply
3. invoke
4. assign
5. throw
6. wait
7. empty
8. terminate
Structured Activities-
9. Sequence, switch and while

10. Flow
11. Pick or multiple receive
3.2 Data Handling
Data at the Process Server can be handled in various ways:
1. Variables

2. Expressions to control behavior

3. assignment to update state
Variables should be use to hold messages that are received from the partners. It can be global or
local.
3.3 Correlation Set
The Correlation set is effectively the primary key for a business process instance. Business
process conversation involves stateful conversation among various processes. It should be used
to identify the correct instance of the process by the Process Server.
3.4 Compensation Handler
In situations where one or more of the the data sources participating in a coordinated data update
process might not be WS-AT compliant, the use of a compensation handler is recommeneded.
These are the points you should consider while designing the compensation handler.
1) Compensation services should exist as a pair, one as primary service and other as
compensation service.
2) The primary service should be invoked when the process runs and the compensation
service should be invoked when a fault occurs.
3) The compensation service should not be invoked without the primary service’s
completion. The compensation service cannot be invoked alone.
4) The compensation service is like any other service and it has its own WSDL.It contains a
service interface with a port type, operation, and message. The following factors dictate
the definition of the compensation service's input message:
• If the compensation service requires only the input data of the primary service, the input
message type for the compensation operation should be the same as the input message
type for the primary operation.
• If the compensation service requires only the output data of the primary service, the input
message type for the compensation operation should be the same as the output
message type for the primary operation.
• If the compensation service requires both the input and output data of the primary
service, a new message type should be defined. The new message type should contain
the parts found in the input and output message types for the primary operation.
3.5 Dynamicity
In DOL’s complex SOA environment, business processes are modeled and orchestrated using
sophisticated tools like WBM and WID, and multiple systems are used to implement the end-to-
end business process flow in runtime. Therefore, any changes in either application logic or third
party services require that strong governance and contingency plans be in place. Dynamicity
refers to an organization’s ability to take effective or dynamic action in response to changes in
their environment. When changes to business logic are frequent, implementation of this logic
through "selector" or "business rules" provided by the process server is recommended, as it

avoids the rigorous cycle changing code, testing and rebooting the application.
In general, external services can change and some mechanism needs to be defined to deal with
this. For example, what happens if a service (this service being well external to the process)
changes at a semantic level (e.g., something that can’t be hidden); it requires a change to the
process and we don’t want to implement the change right away for whatever reason. Obviously,
long-lived long running processes are a subset of this case. In this case, you need a way to
maintain both the old and new version of the services.
1. One of the solutions provided by WebSphere Process Server/WID is the selector. This is
a component that can choose the target of an invocation dynamically at runtime based on
simple logic. Crucially, the choice of targets – and the definition of when they are active –
can be modified at runtime. This means that you can respond to the problems outlined
above without even having to reboot your application. It is an SCA component. It chooses
which implementation of an interface to invoke based on simple logic. It can invoke
implementations both inside a module and in other SCA modules. It can be reconfigured,
at runtime, without having to redeploy the host module.
WebSphere Process Server/WID provides business rules. These are runtime and the
development artifacts that let developers graphically describe business decisions and
parameters. Solutions can call the appropriate business rule group to obtain the current
value (or invoke the correct computation) as the process runs. Importantly, developers
can parameterize these rules and expose them in a runtime GUI to appropriately
authorized business users to change the settings as the application runs. DOL uses
ILOG JRule to run rule services. It is planned that DOL will manage version control and
maintain these rules with the help of ILOG’sTeam Server.
3.6 Business Rules
Business Rules can be defined as a rule set/rule group, decision table, decision graphs and these
rules should be exposed as a service. Business rules externalize business policies, conditions,
and values that are used to affect the operation of a business process. These policies, conditions,
and values might change over time. They should not be embedded in code, which makes them
difficult to change. Business rules make business process applications more flexible to respond
quickly to changing business conditions.
1. Using ILOG’s Team Server, business rules values can be published through a web based
administration tool and can be changed by the business analysts/policy makers directly in
the live running application without interference from the IT team. However, until sufficient
technical analytical expertise is developed at DOL, the IT will need to direct the use of
this tool.
2. No code changes or any extra code development are needed when business rules
change.
3. Live applications can continue to run while their business rules are redeployed.
4. Business rule changes can be managed independently without going through the
rigorous cycle of release management.
5. There are differences between rule sets and decision tables. A rule set captures
decision-making business logic in the form of a series of if-then statements. A decision
table captures multi-conditional decision-making business logic in tabular format. The
main difference being that, in a decision table, the action is decided by more than one
condition. The conditional logic is represented as a table where the rows and columns
intersect to determine the appropriate action. At DOL, the business analysts use a Rule

Set document to create the business rules during the modeling phase. Please refer to
this document to learn more about how this process works.
6. DOL uses the external rule engine ILOG JRule to run the rules outside of the Process
Server. From the manageability and the maintainability perspective, ILOG offers a better
solution with the help of Team Server. When many business analysts are working on the
same rule set and changes occur frequently, Team Server’s benefits are maximized.
There is a separate standards document, Rules Engine Usage Standards.doc) which
explains the factors that should be considered when choosing between the ILOG JRules
and the Process Server rule engines.
Security for Business Rule Manager
If business rules are installed on the system, security should be enabled prior to installing
the Business Rule Manager. The level of security for the Business Rule manager is tied
to J2EE role settings on the Business Rule Manager. To enable security, configure J2EE
security on the Web project, which represents the Business Rule Manager. Otherwise,
anyone will be able to change business rules.
Naming Rule Groups:

• Should be mnemonic - indicate the intent of its use
• It may be a good idea to suffix the Rule Group with “RuleGroup or RG”
• Example: DiscountRuleGroup, HolidayDiscountRG, etc.
Naming Rule Sets:

• It may be a good idea to suffix the Rule Set with “RuleSet or RS”
• Example: DiscountRuleSet, HolidayDiscountRS, etc.
Rules are part of the Rule Set and they can be If-then or action rules. The naming can be a very
simple such as Rule1, Rule2 etc, or they can be descriptive names like DiscountIfThenRule,
ChristmasActionRule etc.
The rule set also contains templates. Use a rule set template to define the implementation and
parameters for an if-then or action rule. This template can then be used to create new instances
of the same rule using different parameters. Simple names like Template1 or Template2 can be
used or they can be descriptive names like DiscountIfThenTemplate or HolidayActionTemplate.
Naming Decision Tables:


• It may be a good idea to suffix the Decision Table with “DecisionTable or DT”
• Example: DiscountDecisionTable, HolidayDiscountDT, etc.
The Decision Table also contains templates. You may want to retain the default naming
suggested by WID or change it to a more meaningful name as explained for the Rule Set above.
3.7 Selector
1. In a typical selector, the routing algorithm uses the date and time settings to determine
which component to route an operation to for implementation. In a situation where you
have a single interface with three individual operations, you could use a selector as a
delegation tool to route the operations to the appropriate destinations. To do this, you
would implement the interface with a selector, and then implement an interface for each
destination that contains an operation that is defined in the original interface.
2. If there is only one destination for the operation, it is recommended that you select it in
the default destination, and leave the destination table empty. If there are two
destinations which represent the current and future behavior for an operation, it is
recommended that you create two destination rows in the table and leave the default
destination empty. If there is some standard behavior for the operation, which is
occasionally overridden for short durations, it is recommended that you use the default
destination for the standard behavior and create a destination row for each short term
behavior.
3. Selector invokes the target components dynamically using the SCA late-binding
mechanism.
4. Use selectors if –
• You know or anticipate that service being invoked will need to change in the
future.
• The target service must be changed dynamically without redeploying the client
program.
5. Package your selector client component in one module.
6. Define the selection targets in another module.
Naming Selectors:
• It may be a good idea to suffix the Selector with “Selector”
• Example: BCAProcessSelector, BankSelector, BrokerageSelector, NewsSelector,
CreditAgencySelector etc.

3.8 State Machine
You can model service-oriented applications using either the process editor or the state machine
editor. Following is some guidance on how to decide which one to use.
On the surface, both the process and state machine editors can be used to visually compose
service-oriented applications, but it is the manner in which they use Web services that
differentiate one editor from the other. Both editors model a programming language where
individual nodes are executed in a specific order. In business processes, the services are
executed from the nodes themselves, while in state machines, the services are executed either
when entering, exiting, or moving between nodes.
In a state machine, the nodes are called states, and they tend to be organized in a "spaghetti-
like" manner. As control moves from one state to another in the diagram, Web services can be
invoked when entering, exiting, or moving between states. Once in that state, execution stops
and waits for an appropriate incoming event, which typically arrive in larger numbers, and in an
unpredictable order. For instance, a request is passed to the state machine, it does something,
and then it waits for another request. The path of execution in a state machine is not necessarily
a direct one, and the business logic will often cycle back on itself.
Naming Business State Machines:

• It may be a good idea to suffix the Business State Machine with “BusinessStateMachine
or StateMachine or BSM”
• Example: PurchaseBusinessStateMachine, SalesOrderTransactionStateMachine,
VendingMachineBSM etc.
3.9 Business Processes
Business processes can only be deployed to the WebSphere Process Server. In a business
process, the nodes are called activities, and they tend to be ordered in a sequential and
algorithmic manner. There are a small number of incoming events and they arrive in a predictable
order. For instance, in the following example, a request is passed to the process; the process
calls out to another service, waits for a response, and then sends a response back to the caller.
Scattered throughout the process are a few activities which use web services to calculate some
data, or loop.

Figure 6– Business Process
3.10 How to choose between a Business Process and a State Machine
Think of a business process as a series of sequential actions (as described above), and the state
machine as a series of loosely related stages that are acted upon. If your application is very
linear, then use a business process; if it is primarily event-driven and/or contains cyclical patterns,
then use a state machine. Both editors, and the languages they model, are equally valid, and it is
up to you to determine which one best suit your application design.
3.11 Business Objects
Use the following standards to design and create XSD’S with the help of WID.
• You can rename business objects and attributes in the business object editor when you
initially create them. Once you have built the business objects into an application, you
should always use refactoring to ensure that you do not break any dependencies.
• WebSphere® Integration Developer's business object editor uses the first definition, top-
level complex types in the XML schema. It uses the following best practices:
o Define elements using named types. Try not to use anonymous types in
schemas. When possible, do not use the second definition.
o Do not use elements and complex type definitions in the WSDL file.

o Define complex types in XML Schema files, not WSDL definitions, to create a
type library concept.
o Build element definitions as necessary to reference a single complex type
definition.
o Use element definitions with the same target namespace as their complex type
definition.
These XSD’s will be available in WSRR. During the WID assembly phase, you should import the
XSD with the help of the WSRR plug-in.
Note: Please reference the XSD Standards document for more details concerning the best
methodologies to create, manage and promote various types of XSD’s (base schema, common
schema, applications specific schema and transaction schemas etc).
3.12 Business Object Map
Business object maps support 1-to-n, m-to-1 and m-to-n mappings among business objects.
This includes mapping the business data and the aspects associated with the business object,
such as the verb. Since the goal of having a business object map is to assign values to the target
business objects based on the values in the source business objects, the mapping information is
associated to each attribute inside a target business object. Using WebSphere Integration
Developer, you can create and edit business objects using the business object mapping editor.
Business object maps can only be used in modules for business services and not for mediation
services.
The business object map editor supports mappings between large business objects that may
have hundreds of attributes. You can sort attributes and filter unnecessary attributes when
creating maps between large business objects that have many attributes. This only applies to the
target business objects. It is recommended that the size of business objects be contained.
The business object map editor does not have the concept of cardinality, except indicating in the
UI that some attribute is an array. If you need to put extra logics in assigning values from one
array to another array (other than Move), you can use Submap or Custom. The business object
mapping editor does not allow mapping between attributes inside an array type.
Naming Business Object Maps:

• Example: <Source>To<Destination> (Source and Destination need not be BO names as
in GenericCustomerToSpecificCustomer), BcaBOToTaxBO etc.
• Namespace: http://www.labor.state.ny.us/bca/map, etc.
• folder/package: gov.nysdol.bca.map

3.13 Libraries
Add libraries with the dependency editor to avoid errors. Using WebSphere Integration Developer
libraries is almost always a good idea so you can reuse business objects and WSDL interfaces.
Otherwise, problems surrounding libraries that produce errors similar to the following will be
common:
CWSCA8025E: The WSDL PortType defined in the interface is invalid.
CWSCA8011E: Operation checkPetition cannot be resolved.
These errors indicate that a WSDL interface can’t be found. A common cause for this is an
undefined library dependency for a module. Libraries should be added by right-clicking the
module and selecting Dependency Editor.
After deployment, if shared resources change in the library, modules using the resources have to
be updated. For example, when two modules share some resources in a library, and the
applications are deployed, one of the modules has to be updated resulting in changes to some of
the shared resources in the library. In this case, the second module also needs to be updated to
reflect the changes in the shared resources.
3.14 Changing Dependency without the Editor
You should avoid modifying module dependencies outside of the dependency editor.
When you add a dependency on a library, Java project, or J2EE project, changes are made to the
module's properties. That is, the module's properties are changed, as follows:
• The Java Build Path would have the library or project added to its build path.
• The Project References determines which J2EE projects or utility JARs are to be
included in the resulting EAR file for the module. If in the dependency editor, the library or
project is also selected to be Deploy with the Module, then the Project References will
have the library or project selected so that it will be added to the EAR file for deployment.
Use the dependency editor to manage project dependencies for your modules and libraries
instead of editing their properties. There are important Java assumptions set in the properties of
modules and libraries, so you should not modify the Java properties, for example, to change their
source and output folders
3.15 Module Isolation with Intermediate Module
When you are designing a system or developing modules, you sometimes gain advantages by
placing an intermediary module between a module and an external service that it is invoking. You
can only use the approach described here if you are using SCA bindings. One advantage of using
an intermediary module is that you can then change the external service or application that your
application is invoking without interruption.
For example, a module (A) with an import invokes a remote service through a direct connection. If
you wanted module A to invoke a different remote service, you would need to update the logic.
You would then need to stop the old version of the module and uninstall it from the server. The
new version of the module could then be installed and started. During this process, there is an
interruption of service for module A.

If you use an intermediary module in your application and connect it to module A with an SCA
binding, you have more flexibility. Module A can have an import that is wired to the export of an
intermediary module or mediation module, module B. The modules must have matching
interfaces. Module B invokes the service. Module B is a facade; module A contains the real
business logic.
When a new module is ready to be deployed, you can use the WebSphere Process Server
administrative console to point the SCA import in module A from the old target module (module B)
to the SCA export in the new one (say, module C), creating a seamless transition to the updated
service. This method allows you to update an application without causing any interruption in
service.
3.16 Uninstall from workspace after testing
Check the administration console for installed applications from various projects/workspaces.
WebSphere Integration Developer business integration applications make heavy use of the
WebSphere Application Server SIBus (system integration bus). The root cause of some of the
problems can be due to many versions of the same application installed on the test server and
the SIBus destinations (or JMS plumbing used by WebSphere Process Server and ESB
assemblies) started to conflict. The user may not even know that more than one application is
deployed on the server. The server view in Eclipse-based development environments only shows
the projects deployed on the server that are in the current workspace.
It is usually a good idea to use multiple workspaces and you may want to create completely new
workspaces for each project. When faced with a debugging problem, you can create a new
workspace and try things in a different way. Each time, you may leave a module deployed on the
server from the previous workspace. The best way to determine what is deployed in your test
environment is to use the WebSphere Application Server administration console which can be
accessed with a Web browser at the default address: http://localhost:9060/admin (use your port
number!). Remove unneeded applications, and the server will start cleanly and without any SIBus
conflicts.
3.17 Clean Server Startup
It’s important that the server starts clean so that runtime errors are not included with application
errors. The application error stack trace may not include any of the code in the workspace (e.g.: it
was a runtime exception by the business process container). The WebSphere Process Server
test server itself may be causing these errors, so ensure that it is patched and running normally.
The runtime errors may include SIBus errors, so when you run into a WebSphere Process Server
or ESB runtime exception while testing your applications, restart the server and make sure that it
comes up clean. It is important to distinguish a problem with your application from a server
runtime problem. This can be a testing practice and should be treated as exit criteria at some
appropriate place in the application promotion process (you can’t exit integration test if it doesn’t
start clean).

Figure 7– Clean Server Start Console
3.18 Review XSD File for Error
Become familiar with the XML representation of components by paying attention to the underlying
XML representations of WSDL interfaces, business process components, and business objects.
All of these components use XML standards such as XML Schema Definitions (XSD) for business
objects, Business Process Execution Language (BPEL) for business processes, and Web
Services Definition Language (WSDL) for interfaces.
Errors like the one below can be resolved by reviewing the XSD documents.
cvc-attribute.3: The value 'myObject:Report' of attribute 'type' on element 'xsd:element'
is not valid with respect to its type, 'QName'.

First, find out what file in the workspace is causing the error. This is usually quite obvious in an
Eclipse IDE, because little Xs mark the spot. The culprit is an interface called SimpleInterface.
After double-clicking on the file we get the interface editor, the interface editor provides no way to
debug the problem. To really get to the root cause, you need to look at the underlying XML
representation of the interface which is a *.wsdl XML document. You can edit the XML by right-
clicking the interface and selecting “Open With => XML Source Page Editor.”
The error example given mentions "myObject:Report". Report is a complex XML Schema type
which is defined in another file (probably called Resport.xsd). In order to reference external
complex types, a namespace identifier is used. The namespace identifier is myObject. However,
the namespace was declared as myObjects with an extra letter "s". Changing either of them so
that they are consistent resolves the error.
Even better, enforce a requirement that nothing enter an integration build with errors, especially
flags on XSD files for schema validation. The XSD representations of business objects are
fundamental – they describe the serialization rules and how they interface to just about
everything. If they’re wrong, the Business Object probably can’t be represented correctly in WPS
and certainly won’t ever get out.
3.19 Data Handling
Make sure that the installation path for WID is small or modify the installation path. There is a 259
character limit for Windows path lengths. If WebSphere Integration Developer is installed under
Program Files, errors such as the following can occur:
[7/23/08 11:11:24:600 EDT] 0000009f WorkSpaceMast E The URI length is
greater than the Windows limit of 259 characters. Unable to create or
update file: C:\Program Files\IBM\WebSphere\ID\6.1\pf\wps\wstemp\10a8a2bc4da\
workspace\cells\widCell\applications\PetitionProcessApp.ear\deployments\
PetitionProcessApp\PetitionProcessEJB.jar\META-INF\wsdl\com\ibm\extremeblue\
petiton\process\outageprocess\PetitonProcess.wsdl
The solution is to use a shorter install path such as C:\WID or D:\IBM\WID, rather than the full
product name. As a temporary fix, you can also use shorter business integration module names.
3.20 Check for WPS and WID Update
WebSphere Integration Developer is one of the newest development environments by IBM, so

new updates are introduced frequently. However, at DOL, our standard is that upgrades will be
introduced to all developers at the same time with assistance from the Tech Services Unit.
Individuals must NEVER accept any updates for WID by selecting the “Help/Software
Updates” option. It is imperative that Process Servers in the development, testing, staging and
production environments are in sync with developers’ machines - there must be no version
mismatches. If a mandatory patch is required for development reasons, inform the Architecture
Group (EPAS) who will work with your unit and Tech Services to decide what steps to take. To
determine your server version, open the administration console with a browser, and go to servers/

Run Administrative Console. The initial screen shows the version number of WebSphere Process
Server.
Figure 8– WPS Version Detail
3.21 Use Capabilities and Perspectives
Through Eclipse, WebSphere Integration Developer provides a filtering function known as

capabilities. With capabilities, you can choose to hide tools not used during business integration
application development; at any time, you can choose to show those tools again. In the
Preferences settings, the product's functions and tools are categorized into capabilities. You can
choose to enable and disable categories of capabilities or the subset functions of any category.
Various perspectives can also be used to filter information. The Business Integration perspective
provides simple, uncluttered views of essential resources so you can model and build business
solutions. Unnecessary details and unused tools are hidden. By default, when you launch the
product, the Business Integration perspective is opened.

3.22 Working with Java Code
If you need to develop Java applications or import JAR files that will be used in a business
integration module, you should create a Java project for the code and add a dependency on the
Java project to the module that will be using the Java code. The Java properties of the business
integration library or module should not be altered because this may cause problems in
deployment code generation. As a result, it is not recommend that you develop complex Java
applications or import JAR files into a library or module in order to use them. Also, when
generating Java implementations for components in an assembly diagram, the generated Java
implementations should be used as a launch point to call other Java classes. Note that the
Business Integration view only shows Java implementations and interfaces that are used in an
assembly diagram. They are listed under the module that uses them. If you need to work with
Java projects, you can switch to work in the Java perspective.
3.23 Change Management
DOL uses IBM’s Rational ClearCase product to keep track of changes and allow developers to
collaborate on integration and development projects. ClearCase allows you to check code in and
out, lock, merge, and synchronize code, coordinate development collaboration, etc.
3.24 Project Interchange Files
Another way to backup your workspace is by exporting a Project Interchange File (.zip), which
could be exchanged with other WID users. To create a Project Interchange File, use the File |
Export… command and choose Project Interchange from the Export dialog. There is a
corresponding File | Import… Project Interchange command that lets you import the project
interchange file into your workspace. It is recommended that you always import a project
interchange file into a new workspace.
For each build that is deployed on to production/staging servers, take a copy of the PI file that
was used and name it as follows.
ProjectName_ModuleName_TimeStamp_Version#
E.g.: - BCA_Operation_12_11_2008_1330_V1.zip
Copy this zip file to a common shared location in ClearCase or on a DOL shared common hard
drive. Please note that this feature is not a replacement for a version control system, but rather an
audit for the projects being deployed on the production servers.
3.25 Business Objects for Imports and Exports
If you plan to use imports and exports in assembly diagrams, it is a good practice to put the
business objects and interfaces that are used by the import and exports into a library so that they
can be shared. Then, add a dependency on the library to all of the modules that use these
common resources. Avoid copying the same business objects and interfaces into different
modules to use them.

3.26 Import
An import allows you to use functions that are not a part the module that you are assembling.
Imports can be from components in other modules or non-SCA components such as stateless
session Enterprise JavaBeans™ (EJBs) and Web services. Available function (or business logic)
implemented in remote systems is modeled as an “imported service”. Imports have interfaces that
are the same as, or a subset of, the interfaces of the remote service that they are associated with
so that those remote services can be called. To share the interfaces between modules, put the
interfaces into a library. Then, for both modules, add a dependency on the library to use its
resources.
Naming Imports:
• It may be a good idea to suffix the Import with “Import”
• The convention is to use a name that is similar (inline) with the related export or service
being called
• Example: ExperienceRatingAccountImport, BankImport, BrokerageImport, NewsImport,
StockPortfolioImport, CreditRatingImport etc.
3.27 Export
An export is a published interface from a component or import to offer its business service to the
outside world, for example, as a Web service. Exports have interfaces that are the same as or a
subset of the interfaces of the component or import that they are associated with so that the
published service can be called. An export dragged from another module into an assembly
diagram will automatically create an import. To share the interfaces between modules, put the
interfaces into a library. Then, for both modules, add a dependency on the library to use its
resources. See related tasks for more information on dependencies. Exports that are shown
under the module assembly in the Business Integration view can be used to create imports in
other modules. If an export in a module assembly does not have any binding, when deployed,
SCA binding is assumed.
Naming Exports:
• It may be a good idea to suffix the Export with “Export”
• The convention is to use a name that is similar (inline) with the related import or service
being exported
• Example: BCAProcessExport, BankExport, BrokerageExport, CreditRatingExport etc.

3.28 BPEL (Business Process Execution Language)
DOL is using the Business Process Modeler for the modeling of the business process.
Websphere Integration Developer will create the basic BPEL skeleton from the imported business
process model.
Following are the standards for BPEL.
• Use an invoke activity prior to the flow or switch activity.

• Wire the invoke activity to a business rule component.
• In the business rule, define the appropriate logic and for the result return a value.
• Use the value in the links or switch to determine navigation.
• This allows a certain amount of logic to be easily modified without having to redeploy the
business process.
• Use XPath rather than Java for the condition logic for:
1. Really complex, data driven expressions.
2. Standards-compliance, as the java extensions are IBM specific.
• Use XPath in the assign statement when and expression is required.
Note: Many more details about integrating WBM models into WID can be found in the
standards document, “WBM Standards for Implementation.doc.”
3.29 Process Debuggers
• Start the server in debug mode before you use the integration test client:
1. The debugger requires a couple of seconds to connect to the server and install
the breakpoints.
2. Since the integration test client framework does not wait for this to occur, it is
fairly easy to run a process before debug initialization has finished.
• Ensure the debugger has properly connected to the server:

1. Once all breakpoints have been installed, you will see this line in the Console:
2. “10/21/08 14:58:56:481 EDT] 00000060 SystemOut O Server is ready for
debugging BPEL”
3. Debuggers do not work when security is enabled.
3.30 Rapid Development with WID
1) Save often. Many of the visual development steps performed in WebSphere Integration
Developer translate to various generated artifacts. Pressing Ctrl-S periodically to save
can enhance development, ensuring that only a few artifacts are created at a time.
2) Clean often. It is often beneficial to select Clean... from the Projects menu. This cleans
all the project's build artifacts and then automatically performs a rebuild. A clean before
deploying to the server or before testing a component is recommended.

3) Test often. WebSphere Integration Developer includes a test component wizard that can
be used to test SCA components individually. After a component is implemented, right-
click the component in the assembly diagram and select Test Component. Define the
inputs to the component and select Continue to unit test the component. Once you are
finished with the test wizard, be sure to select the Stop button at the top-right (
4) One project at a time. When possible, keep only one project deployed on the integrated
WebSphere Process Server. This enables faster server startup and mitigates the risk of
conflicting artifacts. This is especially important when developing under different
workspaces, because the server only shows the projects deployed in a given workspace.
Thus, if projects are not removed from the server before switching to another workspace,
they can be forgotten and cause conflicts later
5) Watch for the progress bar. Keep a lookout for the conveyor belt icon at the bottom
right of WID with a progress percentage. This means WebSphere Integration Developer
is executing a resource intensive task. It is best to wait until the task is complete rather
than adding concurrent tasks to its workload.
3.31 Common Event Infrastructure
WebSphere Integration Developer and WebSphere Process Server introduced Common Event
Infrastructure (CEI) as a way of providing basic event management services. CEI processes
Common Base Events (CBEs) as defined by the CBE specifications. CEI provides a standard
XML-based format for events, which enables generic mechanisms to both log and query events.
Built-in support for CEI in WebSphere Integration Developer generates CBE events.
The CEI is an embeddable component, incorporated in several IBM products, that supports
reporting, persistence, distribution, and interpretation of event data based on the Common Base
Event format.
CEI is not a product, but rather an IBM component used in several IBM products that provide a
programming model to report, persist, and consume Common Base Events, and facilitates the
sharing of event information. We have to explore the integration of it with IBM monitoring tools.
3.32 Local History
WID keeps its own repository of changes to business objects, interfaces, and maps, allowing you
to easily return to previous versions of these artifacts. You can right-click on one of these artifacts
and choose Replace With | Local History… This will open a window that lists the current and all
previous versions of the code with dates and timestamps. From there, you can graphically
compare versions and replace the current version with a previous one. Please note that this
feature is not a replacement for a version control system.
3.33 Performance Best Practices
• Reduce the number of SCA modules whenever possible

• Use the simplest component type possible. For example, do not use a business rule
where a simple Java condition would do)
• Aim for the coarsest granularity to minimize the overhead of service invocation. Don’t
necessarily make “everything” a service or even a component. If something does not
have specific business significance, consider either making it a Java Snippet, a Plain Old
Java Object (POJO) or an Enterprise Java Bean (EJB).

• Use non-interruptible synchronous invocations wherever possible, especially when target

services respond quickly.
• As much as possible, keep Business Objects (BO’s) small.
• Make sure BO types follow the Java naming standards (avoid characters such as the “_”
since these are not allowed for Java classes and would require translation for the internal
data representation).
• Use as few variables as possible.
• Don’t use long running processes when a micro flow will do: there is a very large
difference in performance. Furthermore, the cost of long running processes is affected
by the size of the BPEDB: don’t keep long running processes longer than needed
3.34 Mediation Module
A mediation module is a WebSphere Business Integration project that is used for developing
mediation flows that intercept and modify messages between service consumers (exports) and
service providers (imports). These modules are deployed to the WebSphere Enterprise Service
Bus or the WebSphere Process Server.
If you need to use a WSDL file in a module, copy it to the module. Optionally, copy the WSDL file
to a library and, in the module, set a dependency on the library so that you can use the library's
resources.
You should avoid modifying module dependencies outside of the dependency editor.
Use a mediation module when:
• You want access or modify the header information of the SOAP message
• Locate web service end point using end point lookup mediation primitive in WSRR
Naming Modules:
• It may be a good idea to suffix the Mediation Module with “MediationModule”
• Syntax: <Project><Mediation>Module
• Examples: BCAMediationModule
3.35 Interface Maps
There is a fundamental requirement in an integrated development environment to enable, despite

disparities in their respective interfaces, the various pieces of the integration puzzle to be "glued"
together to form an integrated solution. Interface maps are created to resolve and reconcile
differences between interfaces of interacting components. Interface maps can only be used in
modules for business services and not for mediation services.
There are two levels of mapping:

• Operation mappings - in operation mappings, one operation "talks" to another
operation, referred to as calling and receiving operations. Basically, on a very simple
level, an operation in one interface is bound to an operation in another interface
• Parameter mappings - parameter mappings are essentially one lever deeper than
operation mappings. The calling operation may have different parameters than the

receiving operation and therefore needs an interface map to reconcile the parameters.
There are five types of parameter mappings: move, map, extract, Java, and assign.
Naming Interface Maps:

• It may be a good idea to suffix the Interface Mapping with “InterfaceMap” or
“InterfaceMapping” (if you use <source>To<Destination> format then there is no need of
suffix)
• Examples: BankInterfaceMapping, BorkerageInterfaceMapping,
StockPortfolioInterfaceMapping etc. or you can also use the convention:
<Source>To<Destination> (Source and Destination need not be interface names) as in
GetBCAServiceInterfaceToGetTaxServiceInterface etc.
• Namespace: http://www.labor.state.ny.us/bca/map/
• folder/package: gov.nysdol.bca.map etc.
3.36 Reference Partner
There are two kinds of partners:

• Interface partners : The interface partner is a direct link to the interface where the
partner is configured (See Interfaces)
• Reference partners : The reference partner is not an interface, but instead tells the
process where to find the needed interface.
A partner reference is required when one component uses another component; it is defined on
the component that wants to use another component. The partner reference (sometimes referred
to as a reference) specifies the interface that is used in the invocation of the other component.
The partner reference also contains wires that specify the target components that can be used.
Assembling the components for the application involves creating partner references, interfaces,
and the wiring of components in the module assembly. The result is an assembly diagram that
represents the modeled solution.
Reference Partner Naming:

• It may be a good idea to suffix the Partner with “Partner”
• The convention is: <InterfaceName>Partner
• Example: ExperienceRatingAccountPartner, BankInterfacePartner,
BrokerageInterfacePartner, CurrencyExchangePortTypePartner etc.
3.37 Human Tasks
A human task is, quite simply, a unit of work done by a human. Quite often, this task involves the
interaction with other services, and thus becomes a task within a larger business goal. If the task
is implemented within a business process, it is called an inline task. Otherwise, it is referred to as
a stand-alone task. An inline task is defined within an implementation of a business process. It
can either be implemented directly in the process using a staff activity, or as a property of an

invoke, pick, receive, event handler, or on message activity. A stand-alone task exists
independently of a business process, and implements human interaction as a service that can be
used in many of the different components of the WebSphere Integration Developer family of tools.
Types:
• Participating task: a service component assigns a task to a human
• Originating task: a human can assign a task to a service component/automated service
• Pure human task: a human may assign a task to another human
• Administrative task: grants a human administrative powers for a business process
Human tasks can only be deployed to the WebSphere Process Server.
Naming Human Tasks:

• It may be a good idea to suffix the Human Task with “HumanTask or HT”
• Example: ReviewBCARatingHT, DepositToBankHumanTask, CalculateBrokerageHT,
CalculateCreditRatingHT, etc.
3.38 Variables
Variables are used to prevent the same computation being performed several times as the
variable allows you to store the values so that it can be used later. This can be treated as a
normal attribute, that is, it can be a source or target of a transform. You can add variables to a
business object map using the business object mapping editor.
There are three variable types:

• Simple data
• Business object
• Java class
Variables Naming:
• Mixed case with a lower case first letter
• Names should be short yet meaningful
• Example: result, customerNumber, qtyOfShares etc.
• It is a good idea to differentiate the interface variables with the process variables.
Example: customerNumberVariable (for interface variable), customerNumber for the
process variable
3.39 Snippets
A snippet is a type of BPEL activity. It allows fragments of Java code to be embedded into a
business process.
Snippets are basically an escape hatch in BPEL; they are used when some other BPEL construct
is unable to meet the process implementer’s needs. Some common uses of BPEL include:
• Inserting tracing or diagnostic code.

• Manipulating process variables and transferring data between. Note that BPEL provides
an assign operator that uses XPath to describe variable manipulations.
• Snippets can sometimes be helpful for reducing the complexity of elaborate decision
making trees.
Snippet execution is usually very efficient. The snippet code is inlined into the generated
methods for the process.
A number of BPEL components can contain Java snippets. For example, a decision block can be
coded in Java.
Extensive use of snippets makes it more difficult to maintain processes. Note that the Web
Services standards that describe BPEL do not support snippets: they are specific to WPS. Code
that manipulates process variables has implicit knowledge of the SDOs that contain WPS
business objects.
Some functions shouldn’t be implemented in snippets.
• Snippet code is inlined with the BPEL engine and should behave appropriately.
• Snippets shouldn’t invoke services or act as activities. It is OK for a snippet to affect a
process variable but assign or other pure BPEL activities should be considered first.
• Printlns in snippets are very useful for debugging but should be removed before code is
submitted for integration.
• Snippets should only take actions that affect the process they’re part of.
• Snippets shouldn’t’ try to affect transactional or other J2EE or SCA context.
Transactional boundaries are determined by microflow boundaries, SCA components, the
“transactional” flags on activities in long running processes, and other declarative
indicators.
• Snippets are typically no more than 5-10 lines of code.
3.40 Remove Emulators
• Remove all the emulators when a component is tested. This is local to someone who is
unit testing in WID
• The configurations tab f the test component wizard shows the emulators.
• By Default, WID unit tests only the component which is selected to be tested and
emulates the others: it stubs out the interface associated with downstream components
and returns default values.
4 Tips and Techniques:

5 Appendix:
5.1 SOA Life Cycle and IBM Products:
Figure 1 – SOA Life Cycle and IBM Products at the DOL
At The DOL, we are using the IBM products for the SOA Life cycle of the services.
(1) WebSphere Business Process Modeler (BPM) - Modeling of the services is

done by WBM. It is creating the artifacts required for the Assemble phase of the
SOA.
(2) WebSphere Integration Developer (WID) - Assembly phase of the services is

done in the WID. Process Orchestration and services integration should be done
with the help of WID.
(3) WebSphere Process Server (WPS) - Deployment of the various processes and
human tasks are done in the WPS.
(4) WebSphere Business Monitor (ITCAM for SOA) - This is the only tool not
available at the DOL right now. Hopefully IBM will provide this too soon.

5.2 Overview of Process Integration Model:
Figure 2 – SOA Programming Model
5.2.1 Data Level:
At the data level, WebSphere Process Server offers Service Data Objects (SDOs) as an
abstraction level. SDO and a number of extensions are used to implement business objects.
It is not uncommon for an enterprise application developer to need to know several data access
technologies such as: JDBC, JMS, castor etc. The goal of SDO is to provide a programming
model that will unify data representation across heterogeneous data sources and simplify
application development for developers. SDO provides this by offering a common API that can be
used regardless of the backend data store being accessed. The business Object framework in
WPS 6.1 is based on SDO v1.0 technology. Currently SDO V2.0 has been released and it will be
integrated in the next version of WPS. Concept of Data graph is added in SDO to include the
change summary information.
5.2.2 Invocation Level
At the invocation level, WebSphere Process Server offers Service Component Architecture
(SCA). SCA describes all integration artifacts as service components with well-defined interfaces.
SCA also introduces the concept of a module, which groups together service components and
provides further specification and encapsulation of services.
The concepts of SCA allow a developer to encapsulate integration logic within modules. This
means that a change to service components within a module does not impact any of the other
modules in the overall solution as long as the interface of the changed module stays the same.
This concept has been applied throughout WebSphere Process Server. All integration artifacts in
WebSphere Process Server (processes, business rules, human tasks, and so on) are
represented as SCA service components. This creates an environment with great flexibility. It is
possible, for example, to replace a human task for an approval with a business rule for automatic

approval simply by replacing the service components in the assembly diagram without changing
either a business process or the caller of the business process.
5.2.3 Composition Level
At the composition level, WebSphere Process Server offers business process execution
language for Web services (WS-BPEL), sometimes also referred to as BPEL4WS.
5.3 Process Server Architecture:
Figure 4- Process Server Architecture
WebSphere Process Server is built on a robust J2EE runtime provided by WebSphere

Application Server. The J2EE runtime offers Qualities of Service that WebSphere Process Server
exploits, such as clustering, failover, scalability, and security. The J2EE server also includes a
built-in messaging provider that can be configured to connect to an existing WebSphere MQ
network.
WPS has three main layers

(A)SOA Core layer (B) Supporting services (C) Service Component
5.3.1 SOA Core Layer:
WebSphere Process Server implements a layer called the SOA core. To do integration in an SOA
properly, you must have a single invocation model and a single data model. SOA is this
invocation model: every integration component is described using an interface. These services

can then be assembled in a component assembly editor; the result is a very flexible,
encapsulated solution. Business objects are the universal data description. They are being used
as data going in and out of services and are based on the SDO standards. SOA Core has the
following parts
(5) Service Component Architecture (SCA) - It has elements of the business

transactions, access to the web services and enterprise information System
service assets etc.
(6) Business Objects- contains the data flowing between SCA components. This
provides the abstraction of the data based on the technology called SDO (service
data objects).
(7) Common Event Infrastructure (CEI) - service components can emit events
than can be captured by business monitors such as Web Sphere business
monitor for the real-time monitoring of the business processes.
5.3.2 Supporting Services
Supporting Services are components that are needed in any integration solution, including data
transformation and synchronization services. It contains the following components-
(1) Web sphere enterprise service Bus provides the ESB functionality; with mediation
flows that can operate on messages to perform XML based data transformation, protocol
transformation between various transports and routing etc.
(2) Interface Maps - is used to invoke components.
(3) Business object maps – are used to translate one type of business object to another
type of business object.
(4) Selectors- for the dynamic selection and invocation of different services, which all share
the same interface. Work may be routed to different services based on the different
needs.
5.3.3 Service Components
(1) Business process -component implements a business process execution language

(BPEL) compliant process engine. Users will develop and deploy business processes
with support for long and short running business processes. WS-BPEL models will be
imported in WebSphere Integration Developer from a business model that has been
created in WebSphere Business Modeler.
(2) Human Tasks- are stand-alone components than can be used to assign work to
employees. Human tasks are the part of the long running process.
(3) Business State Machines- provide another way of modelling a business process. Some
processes are driven by events rather than a sequence and in this case, the business
state machine is a better fit for the modelling the process.
(4) Business Rules- are a means of implementing and enforcing business policy through
externalization of business function. These business rules values can be published
through a web based administration tool in the Process Server. These business rules can
be changed by the business analysts/policy makers directly in the live running application
without giving these changes back to the IT team.

5.4 SCA Details:
Figure 4- SCA Component
5.4.1 SCA Interface:
The place at which independent and often unrelated systems meet and communicate with each
other. Web Sphere Process Server currently supports a Java interface definition and an XML
definition (Web Services Description Language (WSDL) port type).The arguments described in an
XML schema are exposed to programmers as SDOs. The Web Sphere Integration Developer
tooling primarily generates interfaces using the WSDL representation.
5.4.2 SCA Implementation
Service components can be implemented as a -
--Java component
– Business process (BPEL process)
– State machines
– Business rules
– Selectors
– Human task
During the Modeling phase, implementation type of the tasks should be defined in the
process model.

5.4.3 SCA References
SCA references specify other SCA services that a component uses.
5.4.4 Selectors
Selectors are for the dynamic selection and invocation of different services, which all
share the same interface.
5.5 Typical Development Process:
In this section an overview is given for the development of the business process from the
beginning to the end. Ideally models will be imported into the WID and many artefacts will be
created during the modelling phase.
1) Create a new Business Integration module for the project- A module is a composite of
service components, imports and exports. The implementations and interfaces
referenced by module components can be contained in the module project or can be
stored in a library. Each module has a module assembly. The module assembly contains
a diagram, which is referred to as the assembly diagram that shows the components of
the module and how their interfaces and references are wired together.
2) Create business objects that describe how the components communicate with each
other. Business objects are containers for application data that represents business
functions or elements, such as petition or claimant data.
3) Create the interface for each component. The interface determines the data that can be
passed from one component to another. The interface consists of one or more
operations, with each operation defining the input and output to the component. An
operation can be a request-response operation or a one-way operation.
4) Create the service component. A service component can be implemented as one of the
following types:
– Java component
– Business process (BPEL process)
– State machines
– Business rules
– Selectors
– Human task
When you create the business process component, an inbound interface (interface
partner) is assigned to the component. You can create the interface when you create the
business process or select an existing interface. The process editor is used to build the
business process:
a. Create reference partners for the business process. Reference partners are outbound
interfaces of the business process.

b. Add activities to the business process. Activities are the individual business tasks
within the process that compose the larger business goal. Please refer to section 8.1 to
know more about various type of activities.
Consider the following examples:

• Add an Invoke activity for each call to a partner.
• Add a Human task activity to send a process-related task to a human for completion.
• Add a Choice activity to evaluate conditions and select a processing path.
5) Create exports and imports and bind them to a protocol. These components define a
module’s external interfaces or access points.
Imports identify services outside of a module, so that they can be called from within the
module. An import is created in the assembly diagram by adding the export or interface of
the external module to the assembly diagram.
Exports allow components to provide their services to external clients. An export

component is created in the assembly diagram for a component, so that its business
service can be used by other modules.
Imports and exports require binding information that defines the means of transporting
the data from the modules. You can change this binding later to use a different transport.
6) Test the business integration module in the integrated test environment.
7) Deploy the business module to Web Sphere Process Server.
When you deploy a module to the test environment or to WebSphere Process Server,
WebSphere Integration Developer packages the module as a J2EE enterprise archive
(EAR) file.
For any given module project, up to three J2EE staging projects are generated with
naming conventions that are based off of the module project’s name:
– An Enterprise Application project
– An Enterprise JavaBean (EJB™) project

This project contains the generated EJBs that represent the runtime artifacts that make
components into reality.
– A Dynamic Web project

This project contains artifacts that represent Web components, for example, servlets and
JavaServer™ Pages™ (JSPs). A dynamic Web project is generated when needed.
You are unable to see these projects in the Business Integration view. To view these
projects, change perspectives, for example, the Web perspective.
5.6 Abbreviations Used:

5.7 Acronyms Used:
WBM WebSphere Business Modeler

WID WebSphere Integration Developer
WSBPEL( Web Services Business Process Execution
BPEL) Language
WSDL Web Service Definition Language
RSA Rational Software Architect
NYSDOL New York State Dept of Labor
CEI Common Event Infrastructure
SCA Service Component Architecture
BRM Business Rule Manager
BPCE Business Process Choreographer Explorer
WPS WebSphere Process Server
WSRR WebSphere Service Registry and Repository
WBM WebSphere Business Modeler
SDO Service Data Object
6 References:
6.1 Bibliography:
IBMDeveloperWorks. Websphere Integration Developer. Copyright IBM Corporation 2005,

2006. Best practice: Choosing between a business process and a state machine. Date of
access: October 2008
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?topic=/com.ibm.wbit.hel
p.bpel.ui.doc/concepts/pvssm.html
IBMDeveloperWorks. Examining business objects in WebSphere Process Server

29 Mar 2006. Larry Tung. Date of access: October 2008.
http://www.ibm.com/developerworks/websphere/library/techarticles/0603_tung/0603_tung.ht
ml
Websphere Integration Developer. Best practices: Modules and packaging for business
services. Copyright IBM Corporation 2005, 2006. Date of access: October
2008.http://publib.boulder.ibm.com/infocenter/dmndhelp/v6rxmx/index.jsp?topic=/com.ibm.w
bit.help.6012.ui.doc/topics/rconsider.html
Websphere Integration Developer. Modules and libraries dependencies. Copyright IBM

Corporation 2005, 2006. Date of access: October 2008
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.wbit.61
2.help.basics.doc/topics/cdepend.html
IBMDeveloperWorks. Be more productive using WebSphere Integration Developer. Robert

Peterson. 26 Jul 2006. Date of access: October 2008
http://www.ibm.com/developerworks/websphere/techjournal/0607_col_peterson/0607_col_p
eterson.html

Websphere Integration Developer. Working with modules and libraries. Copyright IBM
Corporation 2005, 2006. Date of access: October 2008.
p.ui.doc/topics/cworksol.html
Websphere Integration Developer. Best practices: Mediation modules and packaging.

Copyright IBM Corporation 2005, 2006. Date of access: October 2008
p.ui.doc/topics/rsib_consider.html
Websphere Integration Developer. Business services: Components and modules. Copyright

IBM Corporation 2005, 2006. Websphere Integration Developer. Date of access: October
2008
p.wiring.ui.doc/topics/cwiring.html
IBMDeveloperWorks. IBM WebSphere Developer Technical Journal: Get started with

WebSphere Integration Developer. Robert Peterson. 07 Dec 2005, Date of access: October
2008.
http://www.ibm.com/developerworks/websphere/techjournal/0512_peterson/0512_peterson.
html
IBMDeveloperWorks. Common Base Event Best Practices. Copyright IBM Corporation 2005,
2006. Date of access: October 2008.
http://www.ibm.com/developerworks/wikis/display/CBEbestpractice/Common+Base+Event+
Best+Practices.html
23 authors. Websphere Business Integration V6.0.2 Performance Tuning. RedPaper.

IBM.com/redbooks. June 2007.. Date of access: October 2008
http://www.redbooks.ibm.com/redpapers/pdfs/redp4304.pdf
Websphere Integration Developer. Interface Maps.

p.mediation.ui.doc/topics/cmediation.html
Websphere Integration Developer. Interface Maps. Components and Mediation modules.

p.wiring.ui.doc/topicsib/csib_wiring.html
Websphere Integration Developer. Assigning Human Tasks. Copyright IBM Corporation

2005, 2006. Date of access: October 2008
p.tel.ui.doc/topics/humtask.html
Websphere Integration Developer. Mapping Business Objects. Copyright IBM

Corporation 2005, 2006. Date of access: October 2008
p.bo.ui.doc/topics/tbotransed.html
12 authors. SOA Approach to Enterprise Integration for Product Lifecycle Management.

RedPaper. IBM.com/redbooks. October 2008. Date of access: October 2008
http://www.redbooks.ibm.com/redbooks/pdfs/sg247593.pdf


Standards and Best Practices On Process Server and WID

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Standards and Best Practices On Process Server and WID

Uploaded by

Copyright:

Available Formats

NYSDOL Standards and Best Practices

Standards and Best Practices on Process Server and WID

Srikanth Metlakunta and Vijai Singh

Standards and Best Practices on Process Server and WID Page 1 of 36

Name of the person, team.

Standards and Best Practices on Process Server and WID Page 2 of 36

Standards and Best Practices on Process Server and WID Page 3 of 36

5.2.1 Data Level: .......................................................................................................... 29

Standards and Best Practices on Process Server and WID Page 4 of 36

2.1 Process Selection:

Standards and Best Practices on Process Server and WID Page 5 of 36

Choosing between long running processes and microflows:

Naming Business Processes:

Standards and Best Practices on Process Server and WID Page 6 of 36

2.2 Guidelines to Process Implementation

1. A process can be invoked in two ways – a synchronous invocation or an asynchronous

2.3 Guidelines to Service Design

1. Our approach of design is top-down, not bottom-up.

3.1 Type of Activities

There are two types of activities:

9. Sequence, switch and while

3.2 Data Handling

Data at the Process Server can be handled in various ways:

Standards and Best Practices on Process Server and WID Page 7 of 36

2. Expressions to control behavior

3.3 Correlation Set

3.4 Compensation Handler

Standards and Best Practices on Process Server and WID Page 8 of 36

3.6 Business Rules

Standards and Best Practices on Process Server and WID Page 9 of 36

Security for Business Rule Manager

Naming Rule Groups:

Naming Rule Sets:

Naming Decision Tables:

Standards and Best Practices on Process Server and WID Page 10 of 36

5. Package your selector client component in one module.

6. Define the selection targets in another module.

Standards and Best Practices on Process Server and WID Page 11 of 36

3.8 State Machine

Naming Business State Machines:

• Mixed case with a capital first letter

3.9 Business Processes

Standards and Best Practices on Process Server and WID Page 12 of 36

Figure 6– Business Process

3.10 How to choose between a Business Process and a State Machine

3.11 Business Objects

Standards and Best Practices on Process Server and WID Page 13 of 36

3.12 Business Object Map

Naming Business Object Maps:

Standards and Best Practices on Process Server and WID Page 14 of 36

CWSCA8025E: The WSDL PortType defined in the interface is invalid.

CWSCA8011E: Operation checkPetition cannot be resolved.

3.14 Changing Dependency without the Editor

3.15 Module Isolation with Intermediate Module

Standards and Best Practices on Process Server and WID Page 15 of 36

3.16 Uninstall from workspace after testing

3.17 Clean Server Startup

Standards and Best Practices on Process Server and WID Page 16 of 36

Figure 7– Clean Server Start Console

3.18 Review XSD File for Error

cvc-attribute.3: The value 'myObject:Report' of attribute 'type' on element 'xsd:element'

is not valid with respect to its type, 'QName'.

Standards and Best Practices on Process Server and WID Page 17 of 36