EAI TIBCO Interview Preparation Guide

Really good question as far of my knowledge

when insert any data through adb adapter adb will create publication table through that or by checking log file

In publish by value, all the data will be copied from main
table to P table..where as in publish by reference only the
reference will be copied.

Below are the scenerio I can expect:
1. When ever the TIBCO Administrator is down we have to
deploye a application from TRA -> Appmanage.
2. In case we have to deploye various applications using
same global parameters, we have to provide every time these
parameters in TIBCO administrator wile deployement.

So its better to get a best proctice to deploye application
from backend using the scripts. below are the advantages:

1. If Admin is down we are able to deploye application
2. We use a properties file (XML) which is having all the
variables which can be used by various similler
applications. So low workload.

In the TIBCO Administrator, navigate to
All Applications > <your application name> > click on
"History" button right over Configuration builder pane.

In .PAR folder. We can see this folder in TIBCO
adminstrator in Application management--> application-->EAR

This field can contain an XPath expression that
specifies a custom ID for the process instance. This ID
is displayed in the View Service dialog of TIBCO
Administrator, and it is also available in the
$_processContext process variable.

This string is appended to the AE
tracking info appInfo field. The AE
tracking info for messages published is a
concatenation of bw + <processName> +
<jobID> + <businessKey>.
Note: It is a good idea to have all
publishers in a process use the same
business key. Only the most recent
publisher’s business key is used in the
tracking info for the message.

An XPath formula specifying the name of the process
to call. Use this field to dynamically determine which
process to call when the process instance is running.

You can use the Process Name Dynamic Override field on the Configuration tab
to specify an XPath expression that determines which process to call. This is
useful for calling a different process depending upon the value of the XPath
expression. For example, you have an incoming HTTP request that contains an
attribute named orderAmount. For all incoming orders over $10,000, you wish to
call a process that includes activities in the Manual Work palette to obtain the
proper approvals. For orders under $10,000, you wish to call a process that
handles the order automatically. You can create the following expression that
resolves to the proper process name for each type of order:
if($IncomingOrder/orderAmount > 10000) then
’/MyProject/manualApproval.process’
else ’/MyProject/processOrder.process’
Use the full path and name of the process file as stored in the project directory.
When you use the Process Name Dynamic Override field, you must also specify a
process to call in the Process field. The input, output, and error definitions of the
specified process must be the same as any process that the expression in the
Process Name Dynamic Override field can evaluate to.
Input
See TIBCO BusinessWorks Process Design Guide for more information about
mapping and transforming input data.
The input for the activity is the following.
It may be helpful to create process definitions that act as programmatic interfaces
when using the Process Name Dynamic Override field.
In the example above, you may create a process named orderProcessOrApprove.
The only purpose of this process is for specifying the input, output, and error
schemas. Place this process in the Process field of the Call Process tab. Then,
create the manualApproval and processOrder process definitions as copies of the
orderProcessOrApprove process. The Call Process activity then has the correct
input, output, and error schemas for all processes that can be called.
If you use the Process Name Dynamic Override field, make sure you include all
potentially callable subprocesses when you create your Process Archive for
deployment. TIBCO Designer cannot determine which subprocesses are
potentially callable at design time, and therefore they cannot be automatically

Specifies whether to spawn a new machine process
for executing the called process. If this option is
checked, the parent process cannot access the called
process’ output. The called process is executed in a
separate process instance.

JMS Queue receiver is a starter activity. It starts a
process on the recipt of a message for the specified JMS
queue, it is listening to.
ON the other hand, JMS queue requestor is not a starter
activity, it is used to send a request to a JMS queue and
receives a response back from the JMS client. This activity
uses temporary destinations to ensure that reply messages
are received only by the process that sent the request.