TIBCO Administrator Temporary Files

TIBCO Administrator use the temporary folder (usually /tmp on Unix machine) to save configuration data, which might be required during re-deployment or roll-back of a deployed application.

 If files from the temporary folder are tampered, then TIBCO Administrator will fail to re-deploy applications. This can happen if for example, the machine is rebooted, which deletes all files from the temporary folder.

The work-around to avoid this issue is to have TIBCO Administrator use another folder to store its temporary data. This must be done after the domain and the primary TIBCO Administrator Server has been created:

Complete the following activities on the machine that will run the Admin.

1. Connect as login  to the machine.
2. Stop TIBCO Administrator Server if it is already running:
3. Open the file “/opt/tibco/administrator/5.2/bin/tibcoadmin_<DOMAIN>.tra” with vi. If the version of TIBCO Administrator is 5.3, the file is “/opt/tibco/administrator/domain/<DOMAIN>/bin/tibcoadmin_<DOMAIN>.tra”.
4. Add the following text at the end of the file (if not present):

# redirect temp to /opt/tibco/tra/domain/<DOMAIN/tmp

java.property.java.io.tmpdir=/opt/tibco/tra/domain/<DOMAIN>/tmp

###############################################################################

###  END OF FILE  #############################################################

###############################################################################

5. Create the folder “/opt/tibco/tra/domain/<DOMAIN>/tmp”.
6. Restart TIBCO Administrator.

Decrypting the password data type Global Variables in TIBCO ActiveMatrix BusinessWorks

We can Decrypt the password directly with value like if we have the value like below

"#!oe2FVz/rcjokKW2hIDGE7nSX1U+VKRjA"

then by using the Java Code below mentioned we can get the decrypted value as string .

import com.tibco.security.ObfuscationEngine;
String var = new String(ObfuscationEngine.decrypt(Input));
Output=var;

Use the below code in Java Code Activity

first create the Output Parameter and Input Parameter on Configuration tab of the Java Code.

package ProcessDefinition;
import java.util.*;
import java.io.*;
import com.tibco.security.ObfuscationEngine;
public class ProcessDefinitionJavaCode{
/****** START SET/GET METHOD, DO NOT MODIFY *****/
 protected String Input = "";
 protected String Output = "";
 public String getInput() {
  return Input;
 }
 public void setInput(String val) {
  Input = val;
 }
 public String getOutput() {
  return Output;
 }
 public void setOutput(String val) {
  Output = val;
 }
/****** END SET/GET METHOD, DO NOT MODIFY *****/
 public ProcessDefinitionJavaCode() {
 }
 public void invoke() throws Exception {
/* Available Variables: DO NOT MODIFY
 In  : String Input
 Out : String Output
* Available Variables: DO NOT MODIFY *****/
String var = new String(ObfuscationEngine.decrypt(Input));
 Output=var;
}
}

For Example the GV is like below

#!oe2FVz/rcjokKW2hIDGE7nSX1U+VKRjA
 
Then use the GV value as input for the JavaCode input i.e. "#!oe2FVz/rcjokKW2hIDGE7nSX1U+VKRjA"  then will get the Decrypt value in Output Parameter.

 

Difference between RPC and Document Style - WebServices WSDL

RPC and document style in WSDL are the two most widely used terms in reference to Web services and SOAP protocol.

Performance wise there is no difference at all. and   below are the  differences RPC and document style

1. In document style, the SOAP message is sent as a single document whereas in the RPC style, the SOAP body may contain several elements.
2. The document style is loosely coupled whereas the RPC is tightly coupled.
3. In the document style, the client sends the service parameters in simple XML format whereas in the RPC style the parameters are sent as discrete of values.
4. The Document/Literal style loses the operation name in the SOAP message whereas the RPC/literal style keeps the operation name in the SOAP message.
5. In the Document/Literal style, messages can always be validated using any XML validator whereas in the RPC/literal style, the transferred data is difficult to validate by the SOAP message.
6. If we take the concrete WSDL for both of them and import it in the SOAP UI  then we will find the difference below

 Document style

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sch="http://www.tibco.com/schemas/webservice/Schema.xsd">

   <soapenv:Header/>

   <soapenv:Body>

      <sch:OrderRequest>

         <sch:Name>?</sch:Name>

         <sch:Price>?</sch:Price>

      </sch:OrderRequest>

   </soapenv:Body>

</soapenv:Envelope>

 

RPC Style

 

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:inp="http://InputMessageNamespace" xmlns:sch="http://www.tibco.com/schemas/webservice/Schema.xsd">

   <soapenv:Header/>

   <soapenv:Body>

      <inp:BookOrder>

         <sch:OrderRequest>

            <sch:Name>?</sch:Name>

            <sch:Price>?</sch:Price>

         </sch:OrderRequest>

      </inp:BookOrder>

   </soapenv:Body>

</soapenv:Envelope>

 

Here BookOrder is the operation name.  In RPC style as we can see after the Soap body comes the operation name and then the inputs. In document style just after the Soap body comes the inputs.

 

The use attribute also helps to distinguish between RPC and document styles.

The use attribute describes how both the styles are represented in XML. The use attribute describes whether the message parts are encoded or the message follows an XML schema definition.

Based on choices, there are four possible combinations of both RPC and document styles; viz RPC/encoded, RPC literal, Document/Encoded or Document/Literal.

 Not all of the four combinations are in use, and the preference of one combination over the other is more of a personal interest.

The main difference between document and RPC styles is that, in the document style, the client always sends the service parameters to the server in a simple XML document format rather than a discrete set of parameter values. The document style is loosely coupled as compared to the RPC style.

In the Document/Literal style, the message can always be validated using any XML validator. The content within the SOAP body is clearly defined in the schema.

In the RPC/literal style, the transferred data is difficult to validate by the SOAP message.The Document/Literal style loses the operation name in the SOAP message whereas in the RPC/literal style the operation name still exists in the SOAP message.

Out of four different combinations, the styles that are widely used are RPC/literal and Document/Literal.

  

Perform upgrade of TIBCO components / Migration from TIBCO BW 5.X to 5.Y

These are the example steps for migrating from domain "OLD" to domain "NEW".

1.We have a writable directory to export the applications to. Let's call it $BATCHDIR.

2.We should know the actual username and password for the old and new domains.

3.Make sure both domains are running.

4.cd to $TRA_HOME/tra/<ver>/bin/ , lets say /utils/tibco/tra/5.3/bin/

5.Use this command to create a batch file and export .ear files and configuration files: "AppManage -batchExport -domain OLD -user tibco -pw tibco -dir $BATCHDIR "

6.To import all of the applications without starting them, use this command: "AppManage -batchDeploy -domain NEW -user tibco -pw tibco -dir $BATCHDIR -nostart"

If we want to automatically start the applications after deploying, leave off the -nostart parameter. If we don't want to deploy all the applications, modify the $BATCHDIR/AppManage.batch file by commenting or deleting the applications we don't want to deploy.

Typically after we do the batch deploy, we manually stop all of the engines in the old domain, then manually start the engines in the new domain, then stop the old domain itself. This leaves the old domain intact in case something went wrong with the deployments, but it no longer uses any resources.

Business needs may require us to have an engine running at all times, so we could start the new engines before stopping the old engines, but we should make sure they will not conflict with each other first.

Improvements to the AppManage utility in TRA version 5.3 give even more control over working with multiple engines.

Pain points which needs to put light in migration

Is all the Services are scripted deployed or not, in OLD domain?
If few of them manual deployment How to go about it?
How to convert everything to Scripted deployment going forward to ease further enhancements?
Memory Issues (Physical as well as RAM), System requirements due to migration?
Get to know the Basic difference of versions (old and new), e.g. Kind of repository used?
What causes engine startup error due to migration?
How to automate these entire process?
Can be divided into sections Export, Process & Import ?
Is services falls under LB as well as FT?
What are all adapters involved?
Carefully diagonize the difference this is where you end up more processing ?






 

Difference between Inter Process Communication and main process & sub process Communication (using called and calling)

When you excute a "Call Process" task, you just execute another process in the same engine and thread, and wait for its completion. It is like calling a method/function in a standard language.

If in this task, you select the "Spawn" option, the other process will be executed in parallel, in the same engine, but in another thread. The task will complete without waiting for the process completion. This can be used if you want to start a separate process running in parallel.

Now you will use the "Notify" task to send a notification from a process (A) to another one (B) running separately in parallel in different threads. The other process (B) uses the "Wait Notify" task to wait for a notification from another process (A).

In order to work, both A and B notification tasks require a shared configuration object: a "Notify" configuration object. This one can define an XML schema, so processes using this configuration can pass data (from A to B).

The "Notify" configuration object, by default, works for processes running in the same TIBCO BusinessWorks engine. A BW engine is a Operating System process running its own Java Virtual Machine and running a set of BW processes, started by events. Each engine is a separate process at the OS level.

If you want to pass data from one engine to another process in another separate engine, you will select the "Multi-Engine" option of the "Notify" configuration object. In this case, both engines need to access the same database, where TIBCO BusinessWorks stores the data passed from one engine to another one. This mode of communication is slow and requires a database.

Generally, to communicate between separate engines in an efficient and flexible way, you are better consider proper SOA and EAI communication transports and formats, such as SOAP over HTTP/HTTPS/JMS, XML over HTTP/HTTPS/JMS/Rendezvous, etc...

The notification between separate engines is something to consider as last possibility and to be used only for synchronization: for example, execute something only when something else is finished somewhere else.