Communication between TIBCO iProcess Client and Engine.

• The Tibco iprocess engine uses a client/server model for communication. Here we have two way communication path between each iprocess client and iprocess engine.
• The communication protocol used for this communication is called Remote Procedure Call (RPC).
• Any information updated/modified in client needs to be passed to iprocess engine for processing.

Read more...

Physical architecture of TIBCO iProcess engine

The TIBCO iProcess engine can be installed in two ways.

1. Installing the engine on  one server
2. Installing the engine on  multiple servers.

Installing the engine on  one server:

• Installing the tibco iprocess engine on one server is know as Tibco  iprocess engine node  architecture.

Installing the engine on  multiple servers:

• Installing the tibco iprocess engine on multiple servers that all use the same database instance is known as “nodecluster”architecture.

Read more...

Iprocess engine architecture: IAPJMS (IAPJMS) and RPC Background (RPCBG)

IAPJMS  (IAPJMS):

• If activity monitoring is enabled on your TIBCO iProcess Engine, the BG process sends out a message when any of the TIBCO iProcess Engine activities that you have configured to monitor occur. This process is responsible for receiving messages from the BG process and routing these to the JMS topic or queue.

RPC Background  (RPCBG):

• This process handles synchronous RPC calls from the Jump To and Case Suspend features in the TIBCO iProcess Client.

To know the processes operate in the background ClickHere
To know the processes operate in the foreground ClickHere

Read more...

Iprocess engine architecture: Database Queue Daemon(DBQD) and Deadline Manager (DLMGR)

Database Queue Daemon  (DBQD):

• This process is only currently used on the DB2 version of the TIBCO iProcess Engine.
• This process  processes RPC requests from the BG and WISMBD processes to dequeue messages from the database queue tables.

Deadline Manager  (DLMGR):

• This single process manages the deadlines that have been defined in a procedure using the iProcess Modeler.
• At defined intervals, the Deadline Manager checks the outstanding_adresse table for expired deadlines. If deadlines have expired,the Deadline Manager sends an Mbox instruction to the background Mbox set. so that the case instruction process can process the deadlines for the case.

To know the processes operate in the background ClickHere.

Read more...

Iprocess engine architecture: About Background (BG) processes

• This process retrieves messages from the Mbox sets and then processes the case instructions in the messages. 
• The number of Background processes is controlled by the Process Sentinels.
• Each message contains the case instructions from which the Background can determine what actions to take. The Background interprets the business rules defined in the procedure  and routes work items to the necessary work queues or external applications.
• The process makes decisions based upon the Staffware data and procedure definition instructions as to what happens in the business process next.

To know the processes operate in the background ClickHere.

Read more...

Iprocess engine architecture: Case Prediction (BGPREDICT):

• This process  receives messages from the Staffware Background processes.
• When a case instruction that results in a change to a case has been processed, the Staffware Background processes notify the Case Prediction processes so that the prediction data (stored in the database) can be updated. There can be multiple case prediction processes running concurrently.
• Each message contains information about the case that has changed and the procedure and instruction that caused the change.
• The process will read messages from the queue(s) and update the predict table so that it contains the latest prediction information about the case that the queued message was for.

To know the processes operate in the background ClickHere.

Read more...

Iprocess engine architecture: Background Processes

Background processes are responsible for processing message instructions received from the clients such as releasing a step or forwarding a step.

 And also monitor and process any deadlines that have been set up in the procedure and manage case prediction.

processes operate in the background:-

1. Background  (BG)
2. Case Prediction  (BGPREDICT)
3. Database Queue Daemon  (DBQD)
4. Deadline Manager  (DLMGR)
5. IAPJMS  (IAPJMS)
6. RPC Background  (RPCBG)

For detailed information on foreground processes CLICK HERE

Read more...

LibraryBuilder: How to build and Import a Library file (.projlib) in TIBCO BW

Note: For Project Library (.projlib) uses and advantages Click Here.

How to build a Library file:

1. Drag and drop LibraryBuilder resource from palettes pane into design pane.

2. Select Resources tab and add resources by clicking binocular symbol located on the right side.

3. After selected all the files to include in library and then click on Build Library button located at below as shown in below screenshot 2.

How to Import a Library file:

1. Open BW project

2. click on the root folder (this reflects your bw projet name)

3.In the config pane you will see the following tabs configuration, project settings, Design Time libraries.

4. click on design time libraries.

5. click on + sign and apply.

                                      

                                                        1.Import a .Projlib

 

2. Building .projlib

Read more...

Project Library (.projlib) use and advantage in TIBCO BW

Note:To know how to build and Import a Library file (.projlib) Click here.

Project Library Usage:

Project Library is very useful when the common functionalities are shared across the project.  All the common processes or functionalities are grouped together to make the separate common BW project for .projlib usage.

we can reuse process developed by other teams if we build those processes as library file and then by importing into BW project in Tibco designer. This is a perfect approach when number of development teams working together on the same project.

Once we build the library file, We can only export and import into our development projects to make use of it but we can’t modify inner logic of the processes. Team who have build the library file can only edit or modify the processes inside of the library file and rebuild.

The imported processes of the Library builder looks in gray as you can see in the image below.

Advantage of .projlib: 

1. Reusable common process - Existing tested functionality will minimize the development effort.

2. Uniformity of the Common process & functions are used across all projects.

Read more...

What is the use of Sequencing Key in TIBCO BW and How to configure it ?

About Sequencing Key:

• The sequencing Key allows BW to read more than one message at the same time but keep the order for messages which have the same Key.
• Process instances can have sequencing keys that evaluate to different values, but only process instances with the same value for the sequencing key are executed sequentially. 
• Process instances with different sequencing key values can be executed concurrently.
Example:

Imagine the following messages in your queue:

message1 / key: client1

message2 / key: client2

message3 / key: client1

message4 / key: client1 

With three session configured (i.e. Max Job = 3), BW will pull the first three messages (message 1 to 3).

The message 1 and 2 will be execute concurrently while the message 3 will wait the end of the session of the message 1 (they have the same key). In other term, until you confirm the message 1 (or loose its session), the message 3 is in a wait status.

How to set Sequencing Key in TIBCO BW:

Sequencing Key can be specified on the “misc” tab of a process starter. For example, in below screenshot, a file poller activity is specified to sequence files based on their extensions (i.e. all ‘.txt’ will be processed sequentially; all ‘.pdf’ will be sequential etc.)

Read more...

What is the use of Critical Section Groups in BW ? what is the need of Synchronization for Shared Variables? Scope of Synchronization in CS Groups? How to use CS groups with no performance implications?

Critical section groups are used to synchronize process instances so that only one process instance executes the grouped activities at any given time as shown in below screenshot-1.

In general, concurrently running process instances does not wait for the completion of other instance as shown in below screenshot-2.

Any concurrently running process instances that contain a corresponding critical section group wait until the process instance that is currently executing the critical section group completes as shown below.

 Screenshot-1

How Synchronization works with Critical section groups:

Multiple process instances can potentially access and assign values to Shared Variable resources, the Lock shared configuration object(by referencing shared configuration in configuration tab of the group) and critical section group allow you to synchronize access to Shared Variable resources.

Scope of Synchronization:

Critical section groups can be used to synchronize all process instances for a particular process definition in a single process engine or multiple process definitions or across multiple process engines by selecting the scope as Single Group or Multiple Groups in configuration pane.

What is the need of Synchronization:

Without a mechanism for locking, a process instance could update the value of a variable while another process instance is attempting to read the value. This would result in an unpredictable value for the variable.

You should use critical section groups to contain the Set Shared Variable and Get Shared Variable activities.This ensures that only one process instance attempts to assign a value to the variable and ensures that no process assigns a value to the variable when the current process attempts to read the value.

Best practices to use Critical Section Groups: 

There may be performance implications when using these groups. In general, you should use the following guidelines when creating critical section groups:

• Keep the duration of a Critical Section group as short as possible. That is, put only a very few activities in a Critical Section group, and only use activities that execute very quickly.
• Do not include any activities that wait for incoming events or have long duration, such as Request/Reply activities, Wait For activities, Sleep activities, or activities that require a long time to execute.
• Avoid nesting Critical Section groups. If you must use nesting, ensure that Lock shared configuration resources are used in the same order in all process definitions.Deadlocks can occur if you do not specify the Lock resources in the same order in nested Critical Section groups for all process definitions.

                                                       Screenshot-2

Read more...

Iprocess engine architecture: Foreground Processes- Mbox Set

• The Mbox Sets are responsible for communicating information between the foreground and background processes. 
• The Mbox messaging system stores and processes messages from Tibco iProcess Client or Tibco iProcess Engine requests. 
• Mbox sets comprise of one or more message queues.

The messaging system used:-

In the UNIX Oracle and Windows Oracle versions, Oracle AQ. This is a transactional messaging system provided by the Oracle database.

In the UNIX DB2 and Windows SQL Server versions, Staff ware's own transactional messaging system, which uses database tables provided by the DB2 or Microsoft® SQL Server database.

For detailed information on other foreground processes CLICK HERE

Read more...

Iprocess engine architecture(contd): Responsibilities of Foreground Processes

Work queue server(WQS):

The WQS is responsible for providing a complete list of work queues on the system, along with the RPC addresses (RPC number and machine name) of the WIS that handles each queue.

It contains the list of all the users and groups and controls who has access to each queue WIS Mbox Daemon  (WISMBD) RPC listeners  (RPC_TCP_LI and RPC_UDP_LI) RPC pool server  (RPC_POOL).

Work Item Server(WIS):

The WIS processes cache the contents of the work queues and provide lists of work items to TIBCO iProcess Clients.

The WIS processes concurrently produce messages (under transaction control) to be placed in the background Mbox set.

Each WIS process receives messages from the WISMBD. These will be stored temporarily in an in-memory buffer (per physical work queue) for later retrieval when the WIS performs an update from the in memory box.

WIS Mbox Daemon  (WISMBD):

It is  responsible for dequeuing/reading the messages from the WIS Mbox sets and passing them to the appropriate WIS that is handling the item.

RPC listeners:

For each user that logs into Staffware using the TIBCO iProcess Client, a connection to a swrpcsvr pool process is  allocated by the listener.

RPC pool server  (RPC_POOL):

These manage and allocate the RPC connections. For each user that logs into Staffware using the TIBCO iProcess Client, a connection to a swrpcsvr pool process is allocated by the listener. Each pool process maintains a pool of connections.

To know about foreground processes CLICK HERE

Read more...

Iprocess engine architecture(contd): Foreground Processes

ForeGround processes are responsible for communicating with Tibco iProcess Clients and for passing any Tibco iProcess Client requests such as released work items to the background area for processing.

Processes that operate in the foreground:-    

• Work Queue Server ( WQS)
• Work Item Server(WIS)
• WIS Mbox Daemon  (WISMBD)
• RPC listeners  (RPC_TCP_LI and RPC_UDP_LI)
• RPC pool server  (RPC_POOL)

For detailed information on these foreground processes CLICK HERE

Read more...

Iprocess engine architecture: (Process Sentinels)

The iprocess engine can be split in to four major areas as shown below.

1. Process Sentinels.
2. Foreground.
3. Mbox set.
4. Background.

Process Sentinels:

• The Process Sentinels are responsible for controlling all the TIBCO iProcess Engine processes.
• Start processes during a Server start up or upon a system administrator request. It will control the order in which the processes are started. 
• Detect failed processes and restart them automatically. Shut down the processes when the system is shutdown or upon a system administrator request to stop the system 
• Monitor other Process Sentinels and restart them if they fail. Maintain the list of all active user logins.

Processes that are controlled by the Process Sentinels are listed below: 

                      1. Background (BG) 

                      2. Database Queue Daemon(DBQD) 

                      3. Deadline Manager(DLMGR) 

                      4. Introspection Activity Publication JMS (IAPJMS) 

                      5. Prediction (BGPREDICT) 

                      6. RPC Background  

                      7. RPC Pool Server(RPC_POOL) 

                      8. iProcess Objects Server 

                      9. WIS MBOX Daemon (WISMBD) 

                      10. Work Item Server (WIS) 

                      11. Work Queue Server (WQS)

For detailed information on these foreground processes CLICK HERE

Read more...

Features of TIBCO Collaborative Information Manager (TIBCO CIM)

Features of TIBCO Collaborative Information Manager (TIBCO CIM):-

Information Lifecycle Management: Consistent creation to consumption processes, Industry/domain specific

Extensible Referential Repository: Central or virtual store for reference, Cross indexing as required, Validation – data and contextual

Internal Alignment: Process integration for internal systems

External Alignment: B2B integration for trading partner synchronization

Read more...

Version Control Using TIBCO XML Canon™: Why Use XML Canon with BW?

XML Canon provides

• Design-time project repository
• Standards-based (WebDAV)
•  Revision control system (RCS)
•  Differencing engine

BusinessWorks project metadata is built in XML. TIBCO XML Canon™ stores, versions and analyzes XML instances, schemas (XSD, DTD, SOX, etc.), WSDL files, and BusinessWorks processes and resources.

XML Canon™ provides tools for storing, versioning and analyzing XML assets as they exist at any particular stage in the development lifecycle.

Why Use XML Canon with BW?

• XML-based version control
• Web-based desktop for managing SOA assets

XML Canon provides a web-based desktop for viewing and managing all the services, schemas, shared resources, etc. in its repository, dramatically improving reusability.

Fine-grained data services like database lookups may be independent. But as higher-level, composite business services such as "Hiring an employee" or "Processing a Loan" are implemented, inter-dependencies increase. XML Canon allows users to analyze the impact of an asset change, process-, project- or enterprise-wide.

Read more...