TIBCO Designer allows to create alias to resources that can
be reused across projects.
Alias are used in 2 resources
1)AliasLibrary- Used to alias file system resources like
the jar files needed in the project.
2)Library builder- Used to alias shared resources like
Schemas, SSL Certs, BW processes needed during design time.
see when we intract with any applications or dbs commnly we use protocols or connections.sometimes protocols also doesnt support to intract applications by rectifying all those things we need a middleware application. Tibco is the one of the middleware application
why we choose this?
becuase most midleware applications will follow server architecture but tibco follows bus architecture with special feature called tibco rv
If the installation folder of tibco will be in C directory
then once we have deployed the ear file ,the information
will be stored in the following location.
if domain name is mydomain and projectname is TestOne then
Log files :
TestOne.tra file :(it contains all properties) :
In call process we have an option as Process Name Dynamic
Override, this field is used to determine dynamically
which process to call when the process instance is
running.But here both the sub process should have the same
input,output and error schema.
by using the "SQL Direct activity " in the JDBC palette
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.
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.
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
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.
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
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.
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.
In .PAR folder. We can see this folder in TIBCO
adminstrator in Application management--> application-->EAR
In the TIBCO Administrator, navigate to
All Applications > <your application name> > click on
"History" button right over Configuration builder pane.
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 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.
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