The Server Labs Blog Rotating Header Image


iProcess Server architecture

After my previous quick introduction to TIBCO iProcess Suite, I will take this opportunity to go through the main parts of the core component of iProcess, its Server.

Looking in more detail at the iProcess Server’s architecture we can see that its engines are organized into nodes, where a node is formed by 1 or N iProcess Engine servers sharing a database instance. If there is more than one engine for load balancing or fault tolerance, it’s called a node cluster. Engines use Remote Procedure Calls (RPC) to communicate with the clients and can be split into four parts:

  • Process Sentinels: which are responsible for making sure that the rest of the processes are running.
  • Foreground Processes: processes dealing with user interaction.
  • Background Processes: processes performing the “internal” tasks.
  • MBox Set: communication link between background and foreground processes

The Server comes with a client interface called Objects Server which provides an API to interact with the engine. It is available in two “flavors”:

  • Process Objects (TPO): a thick client implementation API for COM/C++/Java.
  • Server Objects (TSO): a thin client implementation API for EJB and .NET.

Using this APIs we can develop custom web-clients, web-services or integrate our J2EE or .NET applications with iProcess.

Business Processes executed by the iProcess Server can interact with external systems as well using EAI plugins. There are plug-ins for different systems, including BusinessWorks, Oracle, Java, SQL Server and scripts.

IProcess Server Architecture

IProcess Server Architecture

Quick introduction to TIBCO iProcess components

From observing material available on the internet and in discussions with our customers, it is clear that there is a fair amount of confusion as to which components are available in TIBCO iProcess suite and what they are used for. This article aims to clarify the components included and provides a brief description of each of them in order to give an overview of TIBCO iProcess. The second article of this series talks about iProcess Server internals.

TIBCO iProcess is a complete suite of products for Business Process Modelling and Execution. It is made up of the following components:

  • Server Engine: business process automation engine and workflow server, it is where the BPM activities are executed.
  • Business Studio: eclipse-based modeling tool that can be used both by business analysts and developers as a common tool to model, develop and test business processes. It can be downloaded for free from here: Supports well known standards like BPMN 1.1/1.2 and XPDL 2.1 and tools like ARIS or Visio. It has a built-in version control component called Business Studio Asset Central. It will eventually replace iProcess Modeler and, at some point, be the unique integrated development tool for the different TIBCO tools. In fact, tadalafil 20mg you can develop Business Works projects with Business Studio using the Designer Add-In.
  • Workspace: thick windows client used for administration (both of the server side and the client side), process modeling and to display work queues to end-users. iProcess Modeler is one of the components of the Workspace, it can be used to model business processes in a similar fashion to Business Studio. Personally, I would recommend you use Business Studio as, since version 3.0, it contains all the key features of iProcess Modeler.
  • Browser: thin client for end-users, includes a work queue and a work item manager to allow users to process the tasks assigned to them.
  • Decisions: business rule definition and management tool with a spreadsheet-like interface for business analysts.
  • Analytics: process performance monitoring tool, compares current and historical data allowing deviation detection.
  • Insight: business activity monitoring (BAM) for iProcess suite which gives business-related information in real time using dashboards.
  • Conductor: used to define execution plans that are based on process components and are represented as Gantt Charts.

I find Conductor particularly interesting. In theory, this tool allows business analysts to rearrange process components without affecting the whole business process. If, for example, at some point we wanted to parallelize two components that were originally defined as sequential, as long as there are no dependencies between them, this can easily be done using drag-and-drop. And, believe me, this is something business people love to have. I say in theory because this requires very careful analysis and design but, if you keep this in mind, the result is really worth it.

Moreover, Conductor’s ability to orchestrate process components makes it a perfect tool for scenarios like dynamic provisioning, as it facilitates runtime definition of specific product provisioning processes based on business rules. As an example, let’s consider a case I worked on a couple of years ago at a Telco. They were offering triple-play (phone, DSL and TV) so defining business processes for every possible combination of commercial offers would have meant creating a few hundred different processes (they had different types of networks, brands, etc.). The solution we found was to define business rules using iProcess Decisions and, based on them, instruct Conductor to dynamically build the project plan for each specific offer.

As you see, iProcess has quite a few of components, in following posts I will try to get more into the details of them.

We have just published the second post in this series here.