Graft step Enables to attach multiple sub-procedures or external processes to a specific point in the procedure. An external application is used to start a number of sub-processes using TIBCO IProcess Objects calls and these are grafted to the main procedure using a graft step, like a wait step because the step is not released until all the sub-processes have completed. Graft step is used for dynamic sub-process call.

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

To make iProcess Engine stable – We should regularly perform the Maintenance jobs:

1. Regularly Deleteing the Old procedure versions (Recommended to keep last 4 versions of procedures)
2. Purging the Closed cases on Periodically basis
3. Regular Index Rebuilding for iProcess Engine database
4. DBMS STATS Gather on database Schemas
5. Archiving the logs from $SWDIR/logs
6. Taking the Regular backups of IPE Engines
7. Weekly Restart of IPEngine


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

Pre-requisites:

1) Administrator rights on the target server
2) iProcess Engine (version 11.1.0)
3) pthread.dll – POSIX thread implementation for Win32 environment.
4) SQLServer instance with user account having the correct permissions (see below) - as we will install the SQLServer version of the iProcess Engine.

NOTE: The installation process may require several re-starts, especially if you also install SQLServer instance on the same server, so make sure that the server can be restarted without problems.

VERY IMPORTANT NOTE: During the install process you will be required to supply a lot of information including usernames, passwords, node names, port numbers etc. Make sure you note these down as you complete each screen of the install wizard. It is very easy to forget a password or username when you really need it!

Space requirements:
iProcess Engine ~ 370 – 400 MB

Installation process:
The installation process is quite straight forward with a wizard like interface.

  (a) Pre-install:
1) Copy pthread.dll to the windows/system32 folder. This is required and the installation process will not start till the pthread.dll file is in the right place. On Windows 7 the folder to use for pthread.dll is windows/SysWOW64.

2) SQLServer access – make sure you can connect to the SQLServer instance and make a careful note of the connection parameters, username and password to be used. Also make sure the username you use has permission to create new databases/tables.

The installer will ask you for this information as the iProcess engine stores all its information in a database. The installer creates the main iProcess database and various tables, within it, as a part of the installation process. The easiest way of messing up the install is to give it a username which doesn’t have the required permissions to perform the table creation activity.

3) Log in as administrator.

  (b) Install:

The install section is fairly straight forward and is well covered in the TIBCO iProcess documentation. I will, therefore, not do a step by step description here but give an overall picture of the install process.

The install process starts off with various iProcess Engine related settings such as the node name (default: staffw_nod1).

NOTE: If you change the iProcess node name MAKE SURE you record it as you will be needing it almost everywhere.

Things done during the install process:

1) Define node name.
2) Define licensee name, which for some strange reason has to be at least 4 characters long.
3) Define a new iProcess administrator account (username and password).
4) Option to require users to login using a password (it is a hard to miss checkbox at the bottom of the screen).
5) Setup a SQLServer connection and create two new SQLServer user accounts (usernames and passwords): swpro and swuser
6) Setup Business Studio deployment (WebDAV), JMS connectivity, Email server as well as the iProcess web-server.

  (c) Post-install:

iProcess Objects Server Configuration -

This is where the fun really begins. Now is the time to configure the iProcess Objects Server. This bit is specially important if you are planning to install the TIBCO BusinessWorks iProcess plugin. Basically the plugin needs DB connection information. So you might want to select ‘ENABLED’ here.

A very important thing that you will need to do during this step is to setup the port for TCP. Open up the ‘services’ file in windows/system32/drivers/etc and scroll all the way to the bottom. There you should see two entries for iProcess similar to:

NODENAME_worker    PORTNUMBER/tcp      # Entry inserted by installer
NODENAME_watcher  PORTNUMBER/tcp      # Entry inserted by installer
Below the last entry add your own entry to define the TCP port to be used by the iProcess Objects Server (replace CAPPED entried with your values):

PORTNAME       PORTNUMBER/tcp               #Your comments

Copy-paste the PORTNAME to the TCP port textbox in TCP Settings tab in the iProcess Objects Server Configuration.

Save all settings and close the Configuration panel. Then restart the server.

After restart go to the ‘Services’ section of the Administrative Tools panel and locate the iProcess service (there will be two services if you also installed the iProcess web server).

NOTE: Make sure the SQLServer on which the iProcess database was created is up and running.

Start up the ‘iProcess Process Sentinals’ service.

If everything has been installed properly then the service will start up normally (it takes some time to do so, don’t be worried if you don’t see the progress bar moving for some time).

In case the service does not start up normally (Windows will throw up an error message) the FIRST thing to check is whether the SQLServer instance, you created the database on, is reachable and you can login with the same credentials you provided (swpro) during the install.

Testing the install:

The best way to test the install (ONLY if you are the administrator AND you have studied the documentation) is to play around with ‘swadm’  in the ‘swserver/NODENAME/util’ directory.

One of the things you might want to do is allow addition of non-OS users to iProcess, especially important if you have enabled external authentication (e.g. through LDAP).

Open up command line interface and go to the ‘util’ directory. Type in and press enter the following command:

swadm set_attribute 0 ALL 0 DISABLE_USER_CHECK 1

The above command sets up a new attribute called DISABLE_USER_CHECK with the value of ’1′. It will allow the addition of non-OS users for all processes. 0 is the Logical Machine ID, ALL signifies do it for all processes (otherwise add process name) and 0 is for the process instance.

An easier way to check it is to install the Windows-based Workspace Browser (11.1.0) and point it to the new iProcess engine.

NOTE: I have done a similar install on Windows 7 – 64bit edition. While TIBCO does not support iProcess Engine SQLServer (11.1.0) on Windows 7, there were no problems in the installation and the performance was up to the mark.




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

The following sub-sections steps through the key functional areas exposed by the SSO API into the TIBCO iProcess Engine and provide a set of best practices that to be followed when working with the API.

Node Discovery
Node Discovery involves the identification of the appropriate iProcess Engine node to connect to, and as such always represents the first task in any SSO module. There are 3 different mechanisms that can be used to locate an iProcess Engine node:

• UDP Broadcast via sNodeManager.getNodes
• Directed UDP Discovery via sNodeManager.verifyNode
• Explicit identification via vNodeId instantiation

The latter of these options is the quickest option for node discovery, and should always be used in preference to the other 2 mechanisms.

Note: Node Discovery should always be performed via vNodeId instantiation

This leads to 2 other considerations, and one further attendant recommendation:

• In order to allow for vNodeId instantiation it is required to configure the SPO Server to use a static TCP/IP port
• The connection details for the iProcess node must be made available to the SSO Module. This is most appropriately done via entries in properties files.

Note: Node connection details should always be read in from properties files and never hard coded

Connection handling:
Once the iProcess Engine node has been identified, the second task in any SSO module is to log-on to the node, and thereby create a connection to the node. This is handled within the SSO API via the instantiation of any of the ‘Server Objects’.

To instantiate one of the ‘Server Objects’ it is required to pass in the username and password details of the user that is being used to connect to the iProcess Engine. The first time any user is logged in, this in turn causes the creation of an underlying ‘SAL Session’ to the iProcess Engine.

Subsequent logins by the same user will reconnect to the existing SAL Session if it is still available (a much less expensive operation that the creation of a new session). This leads to 3 further recommendations:

The SPO Server should be configured with a SAL Session pool size equal to or greater than the total number of named users, and those SAL Sessions should be configured to never expire.
When disconnecting a server Object always use <server_object>.disconnect(false) to keep the SAL Session alive.

When multiple connections are being made (e.g. if SSO is being used to allow for user access) ensure that each user connects as themselves and not either anonymously, or via any form of user ‘pool’ – this will minimize any potential performance issues to do with the synchronization of calls through the same SAL Session.

Each time a ‘Server Object’ is instantiated a TCP/IP socket connection is made to the iProcess engine node (via the SPO Server / SPO Director component). There is a special ‘Server Object’ called sSession that can be used to share the same socket connection across multiple ‘Server Objects’.

To minimize network overheads it is therefore strongly recommended that the sSession server Object always be used to spawn instances of the other ‘Server Objects’ that are required to fulfill the required functionality. For consistency it is also recommended that this approach be followed even when only one type of ‘Server Object’ is required to fulfill the required functionality.

The first ‘Server Object’ to be instantiated should always be an sSession Object, and that sSession should then be used to spawn the other required ‘Server Objects’.

Load Balancing
Connections to the iProcess engine via the SSO API are handled via the ‘SPO Server’ component of the TIBCO iProcess Engine. Multiple ‘SPO Server’ instances can be configured against any iProcess Engine instance to provide scalability.
When the iProcess engine is configured in this way an additional component, the ‘SPO Director’ can be used to provide automated load balancing. It is not a definitive requirement to make use of the ‘SPO Director’ when dealing with multiple ‘SPO Server’ instances as it is possible to provide a bespoke load balancing solution, but there is no real advantage to such an approach.
 
If multiple SPO Servers are configured to provide extra scalability then the SPO Director should be enabled and all connections made to the SPO Director

There are several different ways to configure the ‘SPO Director’ component to perform its load balancing (refer to the iProcess Objects Director Administrators Guide in the iProcess Documentation library for full details).

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

When you don’t properly close your iProcess procedure you have a chance of locking the object for further use. This will result in the following error message:

For some strange cosmic reason, this happens to me a lot. To fix this quickly in a DEV environment connect to the iProcess database and search for the following tables, find the record and delete it.
                 PM_OBJECTS_LOCK:

PROCEDURE_LOCK:

And you are good to go …

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

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]

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]

While purging the huge number of case ,Please be aware that Archive logs will be Huge – Ask your DBA to compress archive logs during the purge activity and Going forward you can schedule the purge activity regularly.

To Add Extra MBox – Run the below query on the database side to create extra AQ Queue/table:

BEGIN
DBMS_AQADM.CREATE_QUEUE_TABLE
(
QUEUE_TABLE => ‘extramboxtable’
,QUEUE_PAYLOAD_TYPE => ‘swlocalmsg’
,COMPATIBLE => ’8.1.3′
,STORAGE_CLAUSE => ‘TABLESPACE Data_Tablespace’
,COMMENT => ‘default background mbox’
);
END;
/

BEGIN
SYS.DBMS_AQADM.CREATE_QUEUE
(
QUEUE_NAME => ‘extramboxqueue’
,QUEUE_TABLE => ‘extramboxtable’
,QUEUE_TYPE => SYS.DBMS_AQADM.NORMAL_QUEUE
,MAX_RETRIES => 12
,RETRY_DELAY => 300
,RETENTION_TIME => 0
);
END;
/

BEGIN
SYS.DBMS_AQADM.START_QUEUE
(
QUEUE_NAME => ‘extramboxqueue’
,ENQUEUE => TRUE
,DEQUEUE => TRUE
);
END;
/

BEGIN
DBMS_AQADM.GRANT_QUEUE_PRIVILEGE ( PRIVILEGE=> ‘all’,
queue_name=> ‘extramboxqueue’,
grantee=> ‘IPE_DBSchema_Owner’,
grant_option=> FALSE
);
END;
/

BEGIN
DBMS_AQADM.GRANT_QUEUE_PRIVILEGE ( PRIVILEGE=> ‘all’,
queue_name=> ‘extramboxqueue’,
grantee=> ‘IPE_DBUser’,
grant_option=> FALSE
);
END;
/

Login as IPE BG User and check how many Mboxes and queues are there :

cd $SWDIR\util
./swadm show_mboxsets v
——————————————————————————–
Mboxset ID Mboxset Name Queue Type Queues in MBOX Set
——————————————————————————–

1 BGMBSET Local 1,2
2 WMDMBSET Local 3,4
3 WISBGMBSET1 Local 1
4 WISBGMBSET2 Local 2
5 PREDICTMBSET Local 6

./swadm show_queues
——————————————————————————–
Queue ID Queue Name Queue Type Queue Desc
——————————————————————————–

1 BGMBOX1 Local 0001::bgmboxtable1:bgmboxqueue1
2 BGMBOX2 Local 0001::bgmboxtable2:bgmboxqueue2
3 WISMBOX1 Local 0001::wismboxtable1:wismboxqueue1
4 WISMBOX2 Local 0001::wismboxtable2:wismboxqueue2
5 PREDICTMBOX1 Local 0001::predictmboxtable1:predictmboxqueue1
6 PREDICTMBOX2 Local 0001::predictmboxtable2:predictmboxqueue2


Now add Extra queue and Mbox for purging :
./swadm add_queue extraMBOXQueue Local 0001::extramboxtable:extramboxqueue
Create new MBOX set
./swadm add_mboxset extraMBOX Local
Show MBoxset – note extraMBOX has no queues and it is number ’6′
./swadm show_mboxsets v
——————————————————————————–
Mboxset ID Mboxset Name Queue Type Queues in MBOX Set
——————————————————————————–
1 BGMBSET Local 1,2
2 WMDMBSET Local 3,4
3 WISBGMBSET1 Local 1
4 WISBGMBSET2 Local 2
5 PREDICTMBSET Local 6
6 extraMBOX Local

Show Queues – note the new queue is number ’7′
./swadm show_queues
——————————————————————————–
Queue ID Queue Name Queue Type Queue Desc
——————————————————————————–
1 BGMBOX1 Local 0001::bgmboxtable1:bgmboxqueue1
2 BGMBOX2 Local 0001::bgmboxtable2:bgmboxqueue2
3 WISMBOX1 Local 0001::wismboxtable1:wismboxqueue1
4 WISMBOX2 Local 0001::wismboxtable2:wismboxqueue2
5 PREDICTMBOX1 Local 0001::predictmboxtable1:predictmboxqueue1
6 PREDICTMBOX2 Local 0001::predictmboxtable2:predictmboxqueue2
7 extraMBOXQueue Local 0001::extramboxtable:extramboxqueue

Add queue 7 to mboxset 6 ./swadm add_queue_to_mboxset 6 7
Check that the queue is now part of MBoxset 7
./swadm show_mboxsets v
——————————————————————————–
Mboxset ID Mboxset Name Queue Type Queues in MBOX Set
——————————————————————————–
1 BGMBSET Local 1,2
2 WMDMBSET Local 3,4
3 WISBGMBSET1 Local 1
4 WISBGMBSET2 Local 2
5 PREDICTMBSET Local 6
6 extraMBOX Local 7

Now you can assign the dedicated BG process to this extra MBox so that it won’t disturb the ongoing transactions and won’t slow down the speed.
SHow the current attribute list for the BG attributes (Read/Write)
cd $SWDIR\util
./swadm show_all_attributes | grep _BG

0 ALL 0 MBSET_READ_BG I 1
0 ALL 0 MBSET_WRITE_BG I 1
0 BG 1 MBSET_READ_BG I 3
0 BG 2 MBSET_READ_BG I 3
0 BG 3 MBSET_READ_BG I 4
0 BG 4 MBSET_READ_BG I 4
0 BG 5 MBSET_READ_BG I 3
0 BG 6 MBSET_READ_BG I 3
0 BG 7 MBSET_READ_BG I 4
0 BG 8 MBSET_READ_BG I 4
0 WIS 1 MBSET_WRITE_BG I 3
0 WIS 2 MBSET_WRITE_BG I 4
0 WIS 3 MBSET_WRITE_BG I 3
0 WIS 4 MBSET_WRITE_BG I 4

The above attributes shows that – there are total 8 BG(s), so I am picking up the last 3 processes ( BG 6 , BG 7 , BG 8) to dedicate to the extra mboix set. If you have more than 8 BG(s) then you can also pick up the last three processes to dedicate to the extra mbox. ( for example if you have 20 BG(s) then you can pick up BG 18, BG 19 and BG 20 ). This is just a convention.

Now stop the engine:
$SWDIR/bin/swstop -f
$SWDIR/bin/swstop -p
Reset the BG attributes for BG 6, BG 7 and BG 8
cd $SWDIR/util
./swadm DELETE_ATTRIBUTE 0 BG 6 MBSET_READ_BG
./swadm DELETE_ATTRIBUTE 0 BG 7 MBSET_READ_BG
./swadm DELETE_ATTRIBUTE 0 BG 8 MBSET_READ_BG
Note : I have deleted the MBSET_READ_BG attribute for BG 6, BG 7 and BG 8.

Now set BG 6 as normal to read the WISMBOX2 (Mbox Number is 4) 
Note :Your Logical Machine ID can be different May be 0 or 1 so use accordingly.
./swadm set_attribute 0 BG 6 MBSET_READ_BG 4
Now set BG7 and BG8 to read from MBox Number 6 , for Purging (Which we have added recently)
./swadm set_attribute 1 BG 7 MBSET_READ_BG 6
./swadm set_attribute 1 BG 8 MBSET_READ_BG 6

Configure the command “SWBATCH” to write to MBox 6 (Purging one)
./swadm set_attribute 0 SWBATCH 0 MBSET_WRITE_BG 6
Now you can start the engine. If anything goes wrong then you can revert all commands.



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

When trying to test the connection to iProcess from BW, this error  occurs.
BW-iPROCESS-000053 Connection Test Failed.  Unable to establish connection to  the iProcess Objects Server.  Exception [com.staffware.sso.data.vException]  occurred. com.staffware.sso.data.vException: SAL system error.   [SWErrorCode=2.   SWErrorCode.  ]


From SWEntObjSv01.log
04440|009CC|04/17/2011 22:09:08.450|00000040|ERROR|sal_login failed  username(swadmin) error(-2)
04440|009CC|04/17/2011 22:09:08.453|00000040|ERROR|process_transaction()  failed, rc=-2, Message Code(OU)
Any ideas how to solve it?

Solution:
Use regedit and set DBConnectionAccess to 1 instead of 0 under ‘Staff EntObj  Server’ if the Server Configuration Utility does not work.
Make sure needed db jarfiles are in place under tibco/tpcl/5.7/jdbc



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