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:Header/>
   <soapenv:Body>
      <sch:OrderRequest>
         <sch:Name>?</sch:Name>
         <sch:Price>?</sch:Price>
      </sch:OrderRequest>
   </soapenv:Body>
</soapenv:Envelope>
 
RPC Style
 
   <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.


syntax error near unexpected token `newline' or `$'\r''

Common errors in running an unix shell scripts are 

line 34: syntax error near unexpected token `newline'
line 30: syntax error near unexpected token `$'\r'' 

Solution:

Unix script file name example.sh then the below is the command to fire on machine.

dos2unix example.sh example.sh

So that it removes the hidden Windows Characters from Files.

While editing files on a machine running some form of Windows and uploading them to a Linux server is convenient, it can cause unforeseen complications. 

Windows-based text editors put special characters at the end of lines to denote a line return or newline. 

Normally harmless, some applications on a Linux server cannot understand these characters and can cause the service to not respond correctly. 

There is a simple way to correct this problem: dos2unix.

What do the hidden characters look like?

Below is an example from the example.sh file showing what the hidden characters look like:

;;;;;;;;;;;;;;;;;;;^M
; Resource Limits ;^M
;;;;;;;;;;;;;;;;;;;^M
;^M
max_execution_time = 30^M
max_input_time = 60^M
memory_limit = 32M^M

As said before, these characters will not appear in most Windows text editors, but will appears in Linux command line utilities like cat or vi. Removing them is rather painless. Just run the command dos2unix.

root@host [~]# dos2unix example.sh example.sh

In the above example of the example.sh, it will look something like this:

root@host [~]# dos2unix example.sh example.sh
dos2unix: converting file
example.sh to UNIX format ...

That’s it. If the command has worked correctly, the file in question shouldn’t have any of the hidden characters in it, like the follow:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;
;
max_execution_time = 30
max_input_time = 60
memory_limit = 32M

The dos2unix command is a simple way to make sure that files that have been edited and uploaded from a Windows machine to a Linux machine work and behave correctly.



How can create custom process starters in TIBCO AMBW ?

 Custom process starters can also be created.

 The Java Event Source process starter allows to create a custom process starter based on Java code.

 Java Event Source provides the features (such as Sequencing key) of other process starters without the need to write extra code.

 Java Event Source provides an abstract class to extend to create a process starter. The abstract class describes the methods that interact with the process engine. 

Custom code must provide implementation for the methods,

 init(). Called when the process engine starts. Can initialize any resource connections. Specify a Java Global instance on the Advanced tab that initializes resource connections. Java Global instances are loaded and initialized during process engine start up. this.getJavaGlobalInstance() can be executed to obtain the Java Global Instance resource in process starter code.

 onStart(). Called by the process engine to activate the process starter. This method must activate any event notifier or resource observer code. The notifier or observer code can then call the onEvent() method to start a process instance.

 onStop(). Called by the process engine to deactivate the process starter. This method must deactivate any event notifier or resource observer code.

onShutdown(). Called by the process engine when the engine shuts down. The method should release any resources and resource connections and perform any required clean up operations.

Methods already implemented.

onEvent(Object object). Called when a listener or resource observer catches a new event. Input to this is a Java object containing the event data.

getGlobalInstance(). Returns an object reference to the Java Global resource specified on the Advanced tab of the process starter. Useful when initialization code is placed in a Java Global Resource instead of the init() method.

onError(). Throws the exception specified in the input parameter. Used to propagate an error to the TIBCO ActiveMatrix BusinessWorks process instance when a listener or resource observer fails to generate an event.

How to create a Custom palette with Custom activities ?

Creating a Custom palette with Custom activities.

1. Create a Custom palette

    a) Select Palettes > My Palettes > New Palette from TIBCO Designer menu.
    b) Specify a name in the dialog that appears
    c) Custom palette appears in palette panel.

2. Drag and drop custom activity to custom palette.
3. Save the project

Distributing custom palette

1. Locate the file(s) containing the custom palette(s) which, by default, are stored in the location specified in the User Palette Directory foeld of the General User Preferences dialog. The file extension of the custom palette is .mypalette.

2. Copy the .mypalette file to the custom palette directory on the machines to use the custome palette. An installation program may be created to perform this step so that users can easily install the custom palettes.

3. Start TIBCO Designer and click the MyPalettes tab to see the custom palette. If TIBCO Designer is already running, click on Palettes > My Palettes > Reload Palettes from the menu to retrieve the new custom palette.
  • Custom activities behave like any other activity in TIBCO ActiveMatrix BusinessWorks. The name of the Custom Activity and the name of the process definition in which the Custom Activity is included should be unique. If names are the same, input and output schemas are not displayed.
  • Global Variables used in Custom Activity are automatically added to the Global Variable list in the project (if they are not included yet).
  • When tracing is enabled, the trace information for activities executing within a custom activity is written to a log file. 


How to create 'Custom Activity' in Active Matrix Business Works ?

TIBCO BW > General Activities >  "Custom Activity"  Configuration

A process definition can be packaged into a custom activity that hides the implementation details of the process from the user.

Steps for creating a custom activity.

1. Create a folder (uniquely named is strongly recommended)

2. Create a process definition

3. Optionally, create output schema to the process definition Start activity.

4. Implement business logic for process definition.

5. Optionally, specify input schema for the End activity in the process definition and mapping.

6. In the project panel, click on the root node of the project, then select the General Activity palette in the palette panel.

7. Create a Custom Activity resource.

8. Click on Browse button to select the process definition.

9. Click Apply.

10.Take one new process definition to use this Custom Activity resource which is configured in previous steps.

(By drag & drop this configured Custom Activity resource cannot use in new process definition, we need to copy the configured Custom Activity resource and past inside the new process definition)

11.Once this done,then the resource is loaded into the new process definition,so now we can run this process.

Any resources referenced by the process definition in a custom activity are automatically included in the custom activity. 

Dynamically called subprocesses are not known at design time, and therefore are not referenced by the process definition. 

Therefore, dynamically called subprocesses cannot be used by a process definition within a custom activity.

Only process definition that do not have a process starters can be referenced by a custom activity.

Global variables used within the process definitions referenced by custom activities are automatically added to the global variable list of the project when the activity is added to a process definition.

Thus a naming convention for Global variables should be specified.

WSDL or XSD files are not automtically included when the process definition is placed in a custom activity. 

WSDL and XSD files must be made available to any user of custom activity.



TIBCO Admin -Transport options local / rv / http

When TIBCO Administrator deploys an application, it creates an application repository which contains information about the application configuration.

We can view and change certain aspects of the application repository.
 
TIBCO Admin -Transport  options local / rv / http

In TIBCO Admin , browse new ear file and  go to the path "Edit Application Configuration > Advanced tab"

There are two sections

Global Variables
TIBCO BusinessWorks and Adapters Deployment Repository Instance    


under the section "TIBCO BusinessWorks and Adapters Deployment Repository Instance" there is Transport drop down box having the options local ,rv and http

This transport is that the administration server uses to communicate with the client application.
  •  local
By default, the transport is set to local. This means that the application repository will be sent to the target machine. This allows the application to run independently of the administration server.

If you change the transport from local to another value, the application repository will not be pushed to the target machine, and the application will communicate with the administration server at runtime.
 
The local choice is supported only if the target machines have installed TIBCO Runtime Agent 5.3 or later.
  •   rv

If rv selected, the client application will use TIBCO Rendezvous to communicate with the administration server.
 
  • http

If selected, the client application will use HTTP to communicate with the administration server.

If administration domain is not initially enabled for HTTPS, and there are deployed applications in the domain that use HTTP to connect to the application repository, the service instances will not restart after they are shut down. In this case, you must redeploy each service instance after changing the transport to HTTPS.
 
The parameter  HTTP URL, HTTPS URL  is the URL on which the client attempts to connect to the server. What displays depends on whether you configured the server for HTTPS

Scenario - web services / Performance Tuning / work load

We have created web service as server (starter activity 'soap event source') process.

How many  number of  incoming HTTP requests (concurrent i.e.occurring at the same time) that can be handled by this web service  ? or  How can we define the workload for this process ?

Answer :

Workload can define by setting the following properties in bwengine.tra file:

bw.plugin.http.server.minProcessors
bw.plugin.http.server.maxProcessors


Setting maxProcessors to 100, means  upto 100 requests can be accepted concurrently.

 Engine.ThreadCount

To improve the ability to execute process instances concurrently, more engine threads are required.

The number of engine threads to be allocated can be set using the property Engine.ThreadCount. The default value is 8.

Engine.StepCount

Set the property, Engine.StepCount, to specify the maximum number of execution steps for a job, unless in a transaction or when the ActivationLimit is set. The default value is 20.

A low value of StepCount results in frequent thread switches. This is an overhead, especially when the number of execution steps for most jobs is high.

bw.plugin.http.client.ResponseThreadPool


To specify the size of the thread pool used by the Request-Reply activity on the web service client side, set the properties: 

bw.plugin.http.client.ResponseThreadPool
bw.plugin.http.client.ResponseThreadPool.type

As the thread pool is created when the engine starts, use a reasonable number to specify the size of the ResponseThreadPool for your system. A high value results in extra resources being allocated which may never be used.

What is SOAPAction ? or What it specifies ?

The SOAP Action HTTP header is defined by the SOAP specification, and it indicates the intent of the SOAP HTTP request.

SOAP Action value is completely arbitrary, and it's intended to tell the HTTP server what the SOAP message wants to do before the HTTP server decodes the XML.


 

RV- Peak Load Test /Performance Test Tools

RV 8.1 and above version software provides a tool rvperf (Rendezvous performance assessment software)

This tool is to answer questions about network behavior under sustained load conditions.

For example:
  •  What happens to network performance when an application sends a batch of ten thousand messages without pausing?
  •  Which computers in my network can send messages the fastest? Which can receive fastest?
  •  How do peak loads affect network throughput?

Performance assessment software consists of two executable programs in below location once after tra installation.

C:\tibco\tibrv\8.1\bin>

●    rvperfm (master) sends messages, gathers performance data, and outputs the report.

●    rvperfs (slave) subscribes to messages from rvperfm, and sends back data about its own speed and effectiveness.

Example :

 Open  command prompt  and go to the path C:\tibco\tibrv\8.1\bin>
 
Start listener with one subject and  Fire the command below then it gives the output report for the mentioned subject.

C:\tibco\tibrv\8.1\bin>
rvperfm -service 1234 -network localhost -daemon tcp:1234 -subject TEST -messages 1 -size 30003728


rvperfm coordinates the tasks of measuring network performance. It sends messages to the network, and reports statistics to stdout.

rvperfm prints a brief string as it begins sending the run of messages, and another when it finishes sending the run.

Then it outputs its run report:

1.     Statistics that rvperfm collects while sending the messages.
2.     Statistics that each rvperfs process collects while receiving messages. 

Each group of statistics represents the performance of one rvperfs process.


 


 Elapsed Time :

Both programs in the performance tool report the total time that elapsed in each complete run.

The speed at which the Rendezvous daemon can deliver messages to the network depends on the network itself, the network interface card (and other hardware parameters), and the host operating system.

If rvperfm sends at a faster rate than the network can accept, rvperfm retains messages in its outbound queue until the network can accept them.

Elapsed time: 0.500000 seconds

Above example screenshot, 0.500000 seconds elapsed from the time that rvperfm sent the first message of the run, until the time that the daemon transmitted the last message of the run to the network.
 

  © Blogger templates The Professional Template by Ourblogtemplates.com 2008

Back to TOP