The iProcess Workspace Browser is a web-based front-end for iProcess. The Workspace Browser is nothing but a web-application which is available in both asp and servlet versions. It does not connect directly to the iProcess engine though. It sends all requests to the iProcess Action Processor which is also a web-application (again available in a servlet and asp version). The Action Processor forwards the request (via TCP/IP) to the iProcess Objects Server which works with the iProcess Engine and processes the request. This arrangement is shown below (with both the Workspace Browser and Action Processor deployed in the same web-server).

Now this setup is fine in an ideal scenario but in most organizations web-servers are isolated (‘fenced’) from the core infrastructure (such as databases and enterprise servers). Usually the access to the core infrastructure is through a single channel (e.g. through a messaging queue server) with direct TCP/IP connections and port 80 requests from outside blocked. In that case you will need to deploy the Action Processor inside the ‘fence’ with the core infrastructure and setup a proxy system to communicate with the Workspace Browser (which will be sitting outside the ‘fence’). The proxy system will transport the HTTP request over the allowed channel (JMS in this example) and return the response. An example is shown below using JMS.

To implement the above we need to create the following components:

1) Local Proxy – which will be the target for the Workspace Browser instead of the Action Processor which is sitting inside the ‘fence’ and therefore not accessible over HTTP.

2) Proxy for JMS – Proxy which puts the http request in a JMS message and gets the response back to the Local Proxy which returns it to the Workspace Browser.

3) JMS Queues – Queues to act like channels through the ‘fence’.

4) Service for JMS – Service to handle the requests sent over JMS inside the ‘fence’ and to send the response back over JMS.

You might ask why do we need a local proxy and why not call the BW Proxy directly. The reason is very simple. The BW Proxy and Service should be as uncluttered as possible, ideally their only task is to carry the request through the ‘fence’ and bring out the response. Any processing of the request and response should be done somewhere else (and as we shall see in the example there is a lot of processing required).

As we don’t want to fiddle with the internals of the iProcess Workspace Browser, we simply add a Local Proxy which does the processing of the request and response. Then we set the Workspace Browser to send all Action Processor requests to the Local Proxy. This means that the Local Proxy will ‘behave’ exactly like the Action Processor as far as the Workspace Browser is concerned.

To put it in one line: using a Local Proxy allows us to separate the ‘behavior’ of the Action Processor from the task of sending the message through the ‘fence’.

In the example to follow, we have:

1) JSP based Local Proxy (easy to code – no compiling required!).

2) BusinessWorks based Proxy for JMS

3) TIBCO EMS Server based queues.

4) BusinessWorks based Service for JMS


For training on TIBCO IProcess mail us at [email protected]

Following the first part, I explained the problem scenario and outlined the solution, in this post I present the implementation.

We need to create the following components:

1) Local Proxy – which will be the target for the Workspace Browser instead of the Action Processor which is sitting inside the ‘fence’ and therefore not accessible over HTTP.

2) Proxy for JMS – Proxy which puts the http request in a JMS message and gets the response back to the Local Proxy which returns it to the Workspace Browser.

3) JMS Queues – Queues to act like channels through the ‘fence’.

4) Service for JMS – Service to handle the requests sent over JMS inside the ‘fence’ and to send the response back over JMS.

I will group the above into three ‘work-packages’:

1) JMS Queues – TIBCO EMS based queues.

2) Proxy and Service for JMS – implemented using BusinessWorks.

3) Local Proxy – implemented using JSP.

Creating the TIBCO EMS Queues

Using the EMS administrator create two queues:

1) iPRequestQueue – to put requests from Workspace Browser.

2) iPResponseQueue – to return response from Action Processor.

Command: create queue <queue name>

Proxy and Service for JMS

For both the Proxy and Service to work we will need to store the session information and refer to it when making HTTP requests to the Action Processor. To carry through the session information we use the JMS Header field: JMSCorrelationID.

Otherwise we will get a ‘There is no node context associated with this session, a Login is required.’ error. We use a Shared-Variable resource to store the session information.

  (a) Proxy for JMS:

The logic for the proxy is simple.

1) HTTP Receiver process starter listens to requests from the Workspace Browser.

2) Upon receiving a request it sends the request content to a JMS Queue sender which inserts the request in a JMS message and puts it on the iPRequestQueue.

3) Then we wait for the JMS Message on iPResponseQueue which contains the response.

4) The response data is picked up from the JMS Message and sent as response to the Workspace Browser.

5) If the returned response is a complaint about ‘a Login is required’ then remove any currently held session information in the shared variable (so that we can get a fresh session next time).

In the HTTP Receiver we will need to add two parameters ‘action’ and ‘cachecircumvention’ with ‘action’ as a required parameter. The ‘action’ parameter value will then be sent in the body of the JMS Message through the ‘fence’.

In the HTTP Response we will put the response JMS Message’s body as ascii and binary content (convert text to base64), Session information in JMSCorrelationID to Set-Cookie HTTP Header in response, Content-Type Header in response will be ”application/xml;charset=utf-8″, Date can be set to the current date and Content-Length to length of the ascii content length (using string-length function).

  (b) Service for JMS:

The logic for the Service sitting inside the fence waiting for requests from the Proxy, over JMS, is as follows:

1) JMS Queue Receiver process starter is waiting for requests on iPRequestQueue.

2) On receiving a message it sends the request from the JMS Message body to the Action Processor using Send HTTP Request activity.

3) A Get Variable activity gets us the session information to use in the request to the Action Processor.

4) The response is then sent to a JMS Queue Sender activity which sends the response out as a JMS Message on iPResponseQueue.

5) If the session information shared variable is blank then we set the session information received in the response.

The Send HTTP Request will also have two parameters: ‘action’ and ‘cachecircumvention’ (optional). We will populate the ‘action’ parameter with the contents from the received JMS Message’s body. The session information will be fetched from the shared variable and put in the Cookie header field of the request. We will also put the contents of the JMS Message’s body in PostData field of RequestActivityInput. Make sure also to populate the Host, Port and Request URI to point to the ActionProcessor.

An example, if you Action Processor is located at: http://CoreWebServer1:8080/TIBCOActProc/ActionProcessor.servlet  [using the servlet version] then the Host = CoreWebServer1, Port=8080 and RequestURI=/TIBCOActProc/ActionProcessor.servlet. If you expect these values to change, make them into global variables.

Local Proxy
This wass the most important, difficult and frustrating component to create. The reason I am using a local proxy based on JSP and not implementing the functionality in the BW Proxy was given in the first part, but to repeat it here in one line: using a Local Proxy allows us to separate the ‘behavior’ of the Action Processor from the task of sending the message through the ‘fence’.

The source jsp file can be found source jsp file.

The logic for the proxy is as follows:

1) Receive the incoming request from the Workspace Browser.

2) Forward the request received from the Workspace Browser, as it is, to the BusinessWork Proxy.

3) Receive the response from the BusinessWork Proxy also get any session information from the response.

4) Process the response:

a) Trim the request and remove any newline-carriage returns.

b) Check the type of response and take appropriate action – if response has HTML then set content type in header to “text/html”, if response is an http address then redirect response and if normal xml then set content type to “application/xml”.

c) Set session information in the header.

5) Pass on the response received from the BusinessWorks Proxy, back to the Workspace Browser.

Once everything is in place we need to change the Action Processor location in the Workspace Browser config.xml file. This file is located in <iProcess Workspace Browser Root>/JSXAPPS/ipc/ folder. Open up the XML file and locate the <ActionProcessor> tag. Change the ‘baseUrl’ attribute to point it to the Local Proxy. Start the BW Proxy and Service, iProcess Process Sentinels, Web-Server for the ActionProcessor and the Workspace Browser. Also test whether the Local Proxy is accessible by type out the location in a browser window.

The screenshots given below show the proxy setup in action. The Local Proxy is at: http://glyph:8080/IPR/iprocess.jsp (we would put this location in the ‘baseUrl’). We track the requests in Firefox using Firebug.

In the picture above we can see normal operation of the Workspace Browser. Above we see requests going direct to the ActionProcessor without any proxy.

Above we see the same login screen but this time the Workspace Browser is using a proxy. All requests are being sent to the Local Proxy.

Above we can the Workspace Browser showing the Work Queues and Work Items (I have blacked out the queue names and work item information on purpose). Tracking it in FireBug we see requests being sent to the Local Proxy (iprocess.jsp).

For training on TIBCO IProcess mail us at [email protected]

public static void main(String[] args) throws RuntimeException {

DaemonManager daemonManager = new DaemonManager(“http://virtualnuggets.com:7580&#8243;);

if(daemonManager.getDaemonType() == DaemonManager.RVD) {
DaemonProxy daemonProxy = daemonManager.getDaemonProxy();

final RvdProxy rvdProxy = (RvdProxy) daemonProxy;

System.out.println(rvdProxy.getComponentName());
System.out.println(rvdProxy.getComponentInformation().getHostname());
System.out.println(rvdProxy.getComponentInformation().getIpAddress());
System.out.println(rvdProxy.getComponentInformation().getLicenseTicket());
System.out.println(rvdProxy.getComponentInformation().getName());
System.out.println(rvdProxy.getComponentInformation().getProcessID());
System.out.println(rvdProxy.getComponentInformation().getVersion());

Service[] services = rvdProxy.getServices();

System.out.println(services.length); //prints 0

for (Service service : services) {
System.out.println(service.getNetwork());
}
}
}


For training on TIBCO BusinessEvents mail us at [email protected]

Note: To add the ems server, both Administrator and EMS should be up and running.

1. Make sure the TRA installalled on the machine where EMS server is running.
2. Run Domain Utility from TIBCO_HOME/TRA/<version that matches to ur domain>/BIN/DomainUtility.exe (Windows) or .bin (Unix)
3. In windows you can double click the domain utility, but in unix use ./<PATH to TRA BIN>/DomainUtility
Note: To enable GUI mode in Unix, your desktop must have xwindows terminal like reflection,cygwin or xwindows etc. Puty does not support xwindows properly.
4. Choose EMS administration from the menu list.
5. Click Add EMS server to TIBCO domain and next.
6. Enter all the details that is required for EMS (Version, path of tibemsd executable (.exe in windows, .bin in unix)
7. Enter the port number, user name and password
8. Test the connection
9. Finish the rest
10. Stop the EMS and start from TIBCO administrator.


For training on TIBCO EMS mail us at [email protected]

What is TIBCO BusinessEvents?
What businesses need today is something that will perceive and identify various diverse events that occur within and across the organization, which may result and lead to a significant condition, problem, or opportunity that requires an immediate response or human intervention. These events may occur in a specific pattern or trend and may result to a specific outcome that could likely make an impact to the company either in a positive or a negative way. TIBCO BusinessEvents is a leading software in complex event processing that addresses the concern of responding to certain conditions or situations before they occur by processing or executing predefined rules. In this document, you will learn more about what TIBCO BusinessEvents can do, its features and advantages, and how easily you can define and make use of its resources.

What is Complex Event Processing?
Complex Event Processing is an event processing technology that processes events uninterruptedly. It is different from other event processing technologies because it treats all events as potentially significant and aims to identify meaningful events within the event cloud. It employs techniques such as detection of complex patterns of many events, event correlation and abstraction, event hierarchies, and relationships between events. You can use the data gathered by your car sensors, for example, to generate certain types of events. These car sensors measure the change in pressure of tires over time. If it detects that there is a dramatic drop in tire pressure within a small amount of time, it may send out a “lossOfTirePressure” event, notify the driver about the situation, and respond by slowing down the car. You can see that before the car experiences a flat tire, the system sends out a notification; thus, the problem that is likely to occur is prevented from happening. TIBCO BusinessEvents is a software that specializes in Complex Event Processing. It analyzes the cause and impact of different meaningful events and how to respond to those that may be considered as a potential harm or benefit. It also works on correlating massive amount of data about many events and applying specific rules to identify situations that require a response. BusinessEvents is “proactive”, which means that it responds before problems arise and opportunities come; thereby, eliminating possible complications that may happen and grabbing the chance or opportunity to gain leverage in business.

What are the different aspects of Complex Event Processing?
One aspect is about knowing the state of persons, objects, or entities in your business. It is monitoring of certain events and observation of certain performance indicators or criteria. Another aspect is about detecting significant facts about persons, objects, or entities in your business and responding to specific conditions that occur. The last is about tracking information over a period of time and tracing pertinent data that may result to a problem or an opportunity.

BusinessEvents enables CEP problems to be solved through a model-driven approach. What are these various models?
These models are the Event model, Concept model, Rule and Ruleset model, Rule Functions, and State model. The event model provides inputs into BusinessEvents through the event properties and optionally their XML payload. The Concept model refers to data concepts mapped from events properties or payload, or other means into BusinessEvents. Rules provide the behavioral mechanisms in BusinessEvents and are composed of the declarations, optional conditions, and actions. Rulesets serve as containers of related rules. Rule functions refer to algorithms, procedures, or functions, which have arguments and a body. They are reusable components in BusinessEvents projects. State model refers to some state machine or state model representation, which describes the states that an entity can hold, the transitions allowed between the states and the conditions for such transitions.

What are channels and destinations?
Channels represent a physical connection to a resource such as Rendezvous daemon or Java Message Service. Destinations are contained in only one channel and represent listeners to messages from that resource, and they can also send messages to that resource.

What are the types of channels?
There are three types of channels: TIBCO Rendezvous channels, JMS Channels, and Local channels. TIBCO Rendezvous channels use the Rendezvous daemon as a connection resource while the JMS Channels use the JMS as a connection resource. Local channels are used to route events to multiple rule sessions. Rule sessions refer to an instance of the BusinessEvents engine.

What is the difference between serializers and deserializers?
Serializers are used by BusinessEvents to convert events to messages while deserializers are used by BusinessEvents to convert messages to events.

What are the three sorts of event that BusinessEvents supports?
The three types of events supported are the simple event, time event, and advisory event. When called event, this refers to a simple event which defines an object that represents an activity such as debiting an account, logging an employee, or suspending a fraud account. You can define the properties of simple events. Time events are timers that are used to trigger rules. There are two types: the repeating time event which repeats every specified interval and the rule-based time event which is asserted into working memory after a specified period of time. Rule-based event can be done by using the ontology function provided in BusinessEvents. Lastly, the advisory event is an event asserted into working memory when certain condition occurs such as exceptions or errors, the failure of the BusinessEvents engine to invoke or call a BusinessWorks process, and the success condition of engine startup or activation. You do not have to create or configure an event of advisory type because it is automatically available for use in the resource list when you add a resource to the declaration portion of a rule.

What are concepts?
Concepts are descriptive entities similar to object oriented concept of a class. They describe a set of properties. For example, an Employee concept can have properties such as FirstName, LastName, Salary, and Department. Concepts have property history and you can set the history size to a number of values with their timestamp, which you want to keep in working memory or a persistent storage. History policies can either be Changes only, which means values will be stored only when they are modified or changed, or All Values, which means values will be stored all the time even though they are not modified or changed. Concepts can also have inheritance, containment, and reference relationships.

What are database concepts?
Database concepts are BusinessEvents concepts created by mapping tables or views from a database. Each row in a table represents one database concept instance, and each column represents the properties of the database concept. Database concepts are different from BusinessEvents concepts because you can perform database operations such as query, insert, update and delete.

What is a scorecard?
A scorecard is a special type of concept that serves as static variables available throughout the BusinessEvents project. Scorecards are used to track certain key factors. Unlike a BusinessEvent concept, a scorecard is itself a single instance and not a description for creating instances. It is created during design-time. Rules are used to view and update the values of the properties in a scorecard.

What is a rule? What comprises a rule?
Rules provide the behavioral mechanisms in BusinessEvents. A rule is composed of the declaration of entity types such as events or concepts, optionally one or more conditions, and an action. The action is executed by BusinessEvents when all of the conditions evaluate to true or there is no condition specified. BusinessEvents rules are declarative rather than procedural. This means that there is no definite execution of these rules but you can specify a rule priority to determine which rule or rules are executed first when certain condition occurs. The rule priority is a number from 1 to 10 with 1 as the highest priority and 10 as the lowest priority. The default value is 5. When you leave the rule priority to a default value, this means that the BusinessEvents will be the one to choose or decide which rule will be executed when certain condition occurs. Rules are contained within a ruleset which serves as a container of related rules.

What is a state modeler?
State modeler is a Unified Modeling Language (UML) compliant application that allows you to model the lifecycle of an instance. For each instance of a given concept, you can define which states it can have and how it will change from state to state based on applicable rules. A state model begins with a start state and ends with one or more end states. It is similar to a finite state automaton. In between may be simple, composite and concurrent states connected by transitions. A simple state is a state that has an entry and an exit action. A composite state is like a group of nested folders that contain other states. A concurrent state allows multiple state flows to be passed on. Transitions determine when an instance of a concept passes from one state to another which is indicated by complex transitions, or from a state to itself which is indicated by self-transitions.

What is a rule function?
A rule function is an algorithm or method you write in BusinessEvents language for use in the entire project. A rule function is composed of arguments and a body. It can return a value, for example, integer, String, or boolean data type. It can also return void or no value. Rule functions can be used as event preprocessors and can be executed during engine startup or shutdown.

What is an event preprocessor?
An event preprocessor is a rule function with one argument of type simple event. It performs actions after an incoming message is converted into a simple event but before it is asserted into working memory. This means that before a rule can process the simple event, the event preprocessor executes certain tasks first.

What is a virtual rule function?
A virtual rule function is a rule function that has arguments but no body. Its implementation is provided in the Decision Manager Business User Interface. The implementations are called decision table classes or external classes since they exist outside the BusinessEvents engine. Each row in a decision table forms a simple rule and collectively defines the body of the virtual rule function.

What is Decision Manager, its use, and importance?
Decision Manager is a component of BusinessEvents. It is an Eclipse-based platform. Its friendly user interface allows a non-technical user to write, test, and deploy business rules to the BusinessEvents engine. Users who do not know programming or TIBCO BusinessEvents can participate in the formulation of rules and rule functions and make their logic become part of the overall BusinessEvents project. It is a client application to Rules Management Server and is supported only in Windows platform.

What is a Rule Management Server?
A Rule Management Server (RMS) is another component of BusinessEvents, which manages decision projects and provides a mechanism for approval. It also provides user authentication, decision project authorization, and other project management features. Decision Manager communicates with Rules Management Server to check out decision projects, update local copies of decision tables, and commit changes. RMS users can then approve or reject those changes. What is nice in RMS is that it can be accessed remotely through a router or the Internet, which means that it does not have to be installed on the user’s machine.

Describe how an RMS project is created and used by Decision Manager users.
The BusinessEvents project is created by the user. He creates events, concepts, rules, and rule functions. The project must contain at least one virtual rule function. The EAR file for this project is built and the RMS user sets up an RMS project for it. The RMS user creates access control files which define the appropriate personnel that can access the decision project, domain model files which define what ontology resources the business user is allowed to utilize, and others such as test files that contain data to test the decision table. After that, the RMS user starts the RMS server and informs the business user that it is already running. The business user logs into Decision Manager and requests for a decision project by checking it out and saving it to his local computer. The business user creates one or more decision tables locally with a locally running BusinessEvents engine started by Decision Manager automatically. The business user commits the decision project for approval. The RMS user receives the request, reviews the project, and then approves or rejects it. If he approves it, the RMS generates class files in a known location on a production BusinessEvents engine or he can manually save it there. The class files are either hot deployed to a running system or deployed when the BusinessEvents system starts up. After this, the business logic defined by the business user is now part of the BusinessEvents application.

Conclusion
With TIBCO BusinessEvents, you can identify significant events and information over time within your organization. You can analyze the most likely impact of these events to your business and prevent the occurrence of problems and grab every opportunity that comes to your business. This prediction capability of TIBCO BusinessEvents makes it truly one of a kind and the leading software when it comes to complex event processing. It also incorporates business users to formulate rules based on their own expertise and integrate these rules in TIBCO BusinessEvents. It is a fantastic way to collaborate in building projects and this results to higher throughput, efficiency, and leverage in business.


For training on TIBCO BusinessEvents mail us at [email protected]

1. Start RVRD on both the boxes, i.e. box A and box B, which are in two different subnets.

2. Open the http interface of both the RVRDs in two different browser instances.

3. Click on the router link, add a unique router name for both the instances.

4.Then click on the local network link on the same page (which will be initially shown as 0), add the local network name, service, network specification and cost and click on add.

5. Then go to the routers link, click on the neighbours link (initially shown as zero), in the remote end point, put the hostname/ip address of the other RVRD box as well as the router name for the other RVRD and add the neighbor interface. In the port, use a TCP port that has been opened by your firewall. In this page, you can select on the type of your neighbors as well, i.e. accept any, passive etc. Default is ACTIVE-ACTIVE, i.e. any of these two RVRDs can initiate a connection to the other RVRD.

6. Follow step 4 and 5 for the other RVRD too.

7. Wait for some time and then click on the “Connected Neighbors” link to see if the connection is established between these two RVRDs.

8. Now for data communication, click on the local network name from the routers page and specify the export/import list of the subjects. This will enable your RVRD to send and receive the messages to/from the other network, which match these export/import subject.

9. Try a tibrvlisten/tibrvsend test on one of the exported/imported subject on both sides to check that the communication is happening.



For training on TIBCO mail us at [email protected]

The locks are held in the flag table.

Run the SQL

update swpro.flag_table set area_locked = 0, user_name = null; commit;

This will unlock the user manager areas but leave any flags that indicate the area is dirty in place.

P.S. Change swpro for whatever schema you have installed it to.

When using iProcess Administrator always do what you need to do and leave the area, this reduces the occurence of these locks being left in pleace as the result of a forced shutdown.



For training on TIBCO IProcess mail us at [email protected]

TIBCO Business is a B2B (business-to-business) gateway that allows your company to engage in electronic commerce with your partners. It enables secure transmission of documents and messages between partners using disparate internal business systems.

BusinessConnect is built on TIBCO ActiveMatrix BusinessWorks, which allows for a familiar experience and ease of integration. BusinessConnect supports all major transport and business protocols and comes bundled with EZComm, an easy-to-use data transfer protocol that allows you to securely exchange data with minimal configuration.

BusinessConnect provides a complete set of tools, allowing companies to do full audits of their B2B activities. A non-repudiation database enables BusinessConnect users to determine the authenticity of a message and a sender.

Below is the architecture of TIBCO BusinessConnect

In the above figure there are 3 components:

TIBCO BusinessConnect server:  This is a runtime engine that provides services to the TIBCO BusinessConnect protocols. The protocols are responsible for the primary TIBCO BusinessConnect functionality, which is processing B2B transactions. The run able version of the TIBCO BusinessConnect server is a BusinessWorks application and it is created when you deploy the TIBCO BusinessConnect application.

TIBCO BusinessConnect Database: This database contains the following:

• Configuration information used by TIBCO BusinessConnect protocols
• Data log created by TIBCO BusinessConnect protocols
• Runtime data used by the TIBCO BusinessConnect server and protocols

TIBCO BusinessConnect console in TIBCO Administrator: This console is used by administrators to do the following:

• Create the TIBCO BusinessConnect database
• Configure participants and business agreements
• View data logs created by TIBCO BusinessConnect protocols

Following are the features of the TIBCO BusinessConnect:-
• BusinessConnect Server engine, which handles transport, messaging, and business message    content
• User access control, where administrative users can set the access control permissions of  other users. Access controls can be used to restrict which trading partner information a user can access in the administration interface.
• Trading partner management system and certificate store
• Non-repudiation database
• Audit log database