TIBCO BW Process Design Guide (2 - 3)

These are some notes I have written in order to help myself to get ready to clear the TIBCO ActiveMatrix BusinessWorks 5 Certification Exam (TB0-123). More details about the exam, click here. This entry is about TIBCO BW Process Design Guide document. Any comment or suggestion, please write to luisagcenteno@gmail.com. Further details can be found at TIBCO Documentation. I hope these notes can help you as well as they did to me...

TIBCO ActiveMatrix BusinessWorks Process Design Guide (Part 2 of 3)

- XPath is an expression language developed by World Wide Web Consortium (W3C) for addressing parts of XML documents. XPath also has basic manipulation for strings, numbers and booleans.
- TIBCO ActiveMatrix BusinessWorks uses XPath language to specify and process elements of data schema.
- All process data and activity input are represented as an XML schema. Regardless of where the data comes from or its format, TIBCO ActiveMatrix BusinessWorks represents the data as a schema tree.
- Complex elements are structures that contain other schema elements, either simple elements or other complex elements. Both simple and complex elements can also repeat.
- In order to refer to a particular item in a schema, start with the root node and then use slashes to indicate a path to the desired data element. Relative paths can be used as well
- Namespaces are automatically added to elements that require this when creating mappings on the input tab of an activity or when dragging and dropping data in the XPath formula builder.
- An XPath expression can have a search predicate. The search predicate is used to locate a specific element of a repeating schema item.
$GetOrderInformation/OrderDetails/OrderItem[1]
$GetOrderInformation/OrderDetails/OrderItem[ProductId=”3A54”]
$GetOrderInformation/OrderDetails/OrderItem[position()>1]
- In order to test an element to determine if it is set to nil or not.
$Order/Item/OnSale/@xsi:nil=”true”
- Comments to XPath expressions
$GetOrderInformation/ShipName/Street {--returnsthe street--}
- XPath Formula Builder can be used where XPath expressions are allowed.
Elements in XPath Formula Builder
-Data tab. Contains the Process Data schema tree.
-Functions tab. Displays all available XPath functions.
-Constants tab. Displays all constants available for use in XPath expressions
-Documentation panel. Describes each selected function
-Evaluation Context field. Displays the evaluation context of the expression field that the editor was invoked from.
-XPath Formula field. Displays the XPath formula to create
-Expression evaluates to Panel. Displays the result of evaluating the formula shown in the XPath Formula field.If there are error in the formula, they are displayed there.
- <<>> are called placeholder
- When data must be represented in the input or output of an activity, the data is represented as string.
Numeric datatypes. xs:integer,xs:decimal,xs:float,xs:double
Decimal, float and double numbers are compressed to an integer when represented if there are only zeros following the decimal point (“1.000” is represented as “1”).
Scientific notation is never used to represent a floating point number as string (xs:double(‘1.2345E05’) is represented as 123400).
Data is truncated if the number of digits exceeds the maximum precision for the datatype (xs:float(‘1.23456789’) is represented as 1.2345679.
Both Zero and Negative Zero are represented as 0.
Positive and negative intinity are represented as Infinity and -Infinity.
Not a Number is represented as NaN
Boolean
xs:boolean(‘true’) and xs:boolean(‘1’) are represented by true as well as XPath function true().
xs:boolean(‘false’) and xs:boolean(‘0’) are represented by false as well as XPath function false()
Date Datatypes. Activities in TIBCO ActiveMatrx BusinessWorks implement dates in one of two ways.
Stored as the number of milliseconds since January 1, 1970 (Activities that are associated with Java)
Implemented according to XPath 2.0 or XQuery 1.0 standards as a set of normalized components (xs:date, xs:time, xs:dateTime, and so on) with an optional timezone offset. (Activities associated with XML). Supports arbitrary precision of the seconds component.
Conversion between date representations may result in a loss of information either because of the difference in time zone representation or the precision of the seconds
- XPath formulas to parse and format strings that represent dates and times.
format-dateTime(<>,<>)
format-date(<>,<>)
format-time(<>,<>)
parse-dateTime(<>,<>)
parse-dateTime(<>,<>)
parse-dateTime(<>,<>)
The format parameter of these functions is based on the format patterns available for the java.text.SimpleDateFormat. To include a simple quote in the format, use ‘’
G. Era (four or more G return the full name of the Era)
y. Year
M. Month in year
w. Week in year
W. Week in month
D. Day in year
d. Day in month
F. Day of week in month
E. Day in week (four or more E return the full name of the weekday)
a. AM/PM marker. Four or more ‘a’ return the full name
H. Hour in day (0-23)
k. Hour in day (1-24)
K. Hour in AM/PM (0-11)
h. Hour in AM/PM (1-12)
m. Minute in hour
s. Second in minute
S. Millisecond
z. Time zone represented as a GMT offset
Z. RFC 822 four digit timezone format
All other letters are reserved
For any format pattern letter that returns a numeric value, the number of letters in the format pattern represents the minimum number of digits. If the date or time has fewer digits than the number of pattern letters, the output is padded with zeros. For parsing functions, when the date or time has fewer digits than the number of characters in the format pattern, the extra characters are ignored, unless they are needed to determine the boundaries of adjacent fields.
- TIBCO ActiveMatrix BusinessWorks provides functions in the XPath formula builder that can be used to fetch process related information for any activity
getCurrentProcessName(<>). Fetches the process name associated with the specified process id.
getCurrentActivityName(<>). Fetches the activity name associated with the specified process id.
getHostName(). Fetches the host name on which the process is running. This function does not take any input parameter

- When an error transition is taken, error data is available to activities that execute after the error transition.
- There are two types of process variables that contain error data
$_error. Contains general information about the process in which the error occurred. StackTrace, Msg, FullClass, Class, ProcessStack, MsgCode and Data fields. The Data schema item contains activity-specific error information.
$_error_. Each activity has one or more predefined error schemas. Error schemas are displayed on the activity’s Error output tab. Typically there are two or three types of exceptions an activity can encounter and these are represented as a choice element in the error output schema. When an error is encountered, the $error_ is created and populated with error data. In order to determine if an error occurred
boolean($_error_MyCreateFile/ActivityErrors/ns2:FileAlreadyExistsException)
msgCode element can be used to determine the kind of error that occurred. Error Code should be used instead of Error Message text in order to detect and handle errors. Error Code should remain constant from release to release, but the text of the message may change.
- Groups and called processes define the scope of an exception.
- An exception that occurs within a group or a called process causes processing to halt.
- Any unhandled exceptions are propagated to the next highest exception scope.
- Unhandled errors occur where there is no error transition or Catch activity that specifies the activities to execute in the case of an error.
- Generate Error activity creates unhandled errors and does not permit any transitions to another activity.
- Unhandled errors halt the execution of a group and the error transition out of the group is taken.
- Any unhandled errors encountered when executing the called process cause the called process to halt execution and return the error to the next highest exception scope.
- A process can define an error schema and use the Generate Error activity to propagate specific data to the parent process.
- The error process variables contain the default data returned in the event of an error. Error schemas can be defined to hold data when errors are propagated from a group or a called process. Each process can define a number of error schemas by creating these schemas on the Error Schema tab of the process definition’s End Activity.
- When Generate Error activity is executed, the specified error schema is propagated to the parent process.
- If Default is chosen as error schema for a Generate Error activity, then only the $_error process variable contains the propagated error data.
- If an process error schema is chosen, the schema appears in the Input tab for the Generate Error activity and you can map data to the specified error schema.
- If the error occurs in a called process, then the portion is the name of the Call Process activity. If the error occurs in a group, then the portion is the name of the Generate Error activity in the group.
- The Catch activity allows to create a track that handles the exception and proceeds to the end of the current scope; either the end of the process definition or the end of a group. The Catch activity can specify the type of exception that should be caught. More than one Catch activity can be added but each one must handle a different exception type. Any unhandled exception (after all Catch activities) can be handled by a Catch All. Transitions cannot be drawn to the Catch activity. Also, transitions from any activity on the path of the Catch activity to any activity on the regular execution path. Activities on a Catch path can have transitions to other activities on other Catch activities.
- The Rethrow activity allows to throw the exception currently being handled by a Catch path. This is useful in order to do some processing and then propagate the error up to the next level.

- A transaction is a logical unit of work that allow to group activities into atomic execution units.
- Activities with transactional capabilities
JDBC activities
JMS activities
ActiveEnterprise Adapter activities that se JMS transports
EJB activities
TIBCO iProcess BusinessWorks Connector activities
- Any activity can be contained in a transaction group, but not all can be part of a transaction.
- Types of transactions
- JDBC. Allows many JDBC activities that access the same connection to be part of the transaction. The transaction group commits if all the activities in the group complete and a non-error transition is taken out of the transaction group. If any error occurs in the transaction group (even non-JDBC errors), the transaction is rolled back. Each set of activities that use a JDBC Connection is considered a separate transaction.
- Java Transaction API (JTA) UserTransaction. Allows JDBC, JMS, ActiveEnterprise (using JMS transports) and EJB activities to participate in transactions. JTA specifies standard Java interfaces between a transaction manager, the application server and the application. For activities that use JMS transport, request/reply operations cannot participate in a JTA transaction. Requires an installed application server installed and configured that implements the JTA interface javax.transaction.UserTransaction (WebLogic, WebSphere, JBoss). Not all app servers allow JDBC and JMS to participate in a JTA transaction. If it does not permit an operation, TIBCO ActiveMatrix BusinessWorks still allows to configure the operations in the transaction. However, no exception is raised and the operations that are not supported by the application server are performed independent of the transaction. JDBC Connections used by JDBC activities must be configured to use JNDI as the connection type and specify the data source in the application server. The JNDI configuration must specify the appropriate connection and JNDI Context information for the application server. The JTA User Transaction transaction group has the following fields.
-Transaction Manager. A JTA UserTransaction shared configuration resource.
-Include Checkpoint. When checked, an implicit checkpoint is performed after the last activity in the group completes successfully and before the transaction is committed. The deployment configuration must specify a database for storing process engine information and the JDBC Connection used must specify JNDI as the connection type for this checkpoint to participate in this transaction.
-Checkpoint duplicate key. When Include Checkpoint is checked, a duplicate key can be specified in this field to perform duplicate checking.
- XA Transaction. Allows to specify an XA-compliant transaction manager provided by a third party that supports the interfaces java.transaction.TransactionManager and java.transaction.Transaction (TIBCO BusinessWorks XA Transaction Manager 1.0, Arjuna Transaction Service 4.0, Java Open Transaction Manager (JOTM) 1.5.3). Allows JDBC, ActiveEnterprise Adapter activities that use JMS transport, and JMS activities to participate in transactions. Transactions over multiple databases are also supported. Also, if the process engine is configured to use a database for storage of process engine data, checkpoints can participate in an XA Transactions. For JMS activities and for ActiveEnterprise Adapter activities, request/reply operations cannot participate in an XA transaction. Also, EJB activities cannot participate in an XA transaction. A Transaction Manager is typically exected on the same JVM as TIBCO ActiveMatrix BusinessWorks so files needed to run the transaction manager must be placed in the TIBCO ActiveMatrix BusinessWorks classpath in the bwengine.tra and designer.tra files. For the TIBCO ActiveMatrix BusinessWorks XA Transaction Manager, configuration occurs during product installation. XA Transaction group contains the following fields.
-Transaction Manager. A XA Transaction Configuration shared resource
-Include In Transaction. Specifies a resource for which an acknowledgement will be sent (JMS Queue Receiver, Wait for JMS Queue Message, JMS Topic Subscriber). Transactional acknowledgement mode should be specified in the activity. This is part of the transaction if the transaction commits. There is no need for a Confirm activity for the resources specified in this field.
-Include Checkpoint. When checked, an implicit checkpoint is performed after the last activity in the group completes successfully and before the transaction is committed. The deployment configuration must specify a database for storing process engine information and the JDBC Connection used must specify XA as the connection type for this checkpoint to participate in this transaction.
-Checkpoint duplicate key. When Include Checkpoint is checked, a duplicate key can be specified in this field to perform duplicate checking.
Configuring Transaction Managers
-TIBCO BusinessWorks XA Transaction Manager. Automatically configured for use with TIBCO ActiveMatrix BusinessWorks. In case it is not configured, append following paths to the tibco.env.CUSTOM_EXT_APPEND_CP property in bwengine.tra and designer.tra files:
/bw/tm/1.0/lib
/bw/tm/1.0/lib/ext
-Java Open Transaction Manager (JOTM). Not changes required to the JOTM environment. Changes to TIBCO ActiveMatrix BusinessWorks
1.Include JOTM jar files in the TIBCO Designer and TIBCO ActiveMatrix classpath by adding the following JOTM directory to the classpath properties in the designer.tra and bwengine.tra file
\jotm-1.5.3\config
\jotm-1.5.3\lib
2. Logging details for JOTM is specified in TIBCO ActiveMatrix BusinessWorks log4j property file (\5.2\lib\log4j.properties). By default, the log4j property file is configured to send JOTM log messages to the TIBCO ActiveMatrix BusinessWorks log file (BWLogFileAppender). To send JOTM messages to a separate file, log4j file must be modified. There are several JOTM logger properties with the prefix log4j.logger.org.objectweb.jotm. To each of these properties, add jotm_log_file.
-Arjuna Transaction Service (ATS)
Changes in the ATS properties file.
1. ATS provides two transaction manager implementations, one that is local (com.arjuna.ats.internal.jta.transaction.arjunascore.TransactionManagerImple) and one that is based on the distributed JTA implementation (com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple). TIBCO ActiveMatrix BusinessWorks only supports the local implementations. For BW to work properly, ATS must be configured to use the local implementations. Set the following variables in ATS properties file (\ats-4.0\etc\arjunajts-properties.xml):


2. ATS provides two recovery modules for XA resources, one for local transaction recovery and one for distributed transaction recovery. In TIBCO BW, local transaction recovery is used. By default, the ATS properties file may be configured to enable both the transaction recovery modules.


TIBCO ActiveMatrix BusinessWorks uses the local transaction recovery, therefore the distributed transaction recovery property must be commented out or removed from the ATS properties file.
3. By default the ATS ObjectStore is created in the current working directory of the application. When using TIBCO BW, this will be the working directory or the directory where the TIBCO ActiveMatrix BusinessWokrs process engine is started. It is recommended to change the location where the ATS ObjectStore is created. To do so, set the following variable in ATS properties file.

Changes to TIBCO ActiveMatrix BusinessWorks
1. TIBCO Designer and TIBCO ActiveMatrix BusinessWorks classpaths must be modified to include ATS property file and jar files. The following directories must be included in classpath properties in the designer.tra and bwengine.tra files.
\ats-4.0\etc
\ats-4.0\lib
\ats-4.0\lib\ext
2. Logging details for ATS is specified in TIBCO ActiveMatrix BusinessWorks log4j property file (\5.2\lib\log4j.properties). By default, the log4j property file is configured to send ATS log messages to the TIBCO ActiveMatrix BusinessWorks log file (BWLogFileAppender). To send ATS messages to a separate file, log4j file must be modified. Comment out the line containing log4j.logger.com.arjuna=WARN, tibco_bw_log. Remove the comment from the line containing #log4j.logger.com.arjuna=WARN, tibco_bw_log, ats_log_file
Transaction Recovery is the ability to recover from the event of a failure.
TIBCO BusinessWorks XA Transaction Manager
The transaction recovery manager is started when TIBCO ActiveMatrix BusinessWorks is started and no additional recovery configuration is necessary as transaction manager and the recovery manager are started in the same Java VM. Running recovery manaher in a separate Java VM to allow transaction recovery to occur independently of TIBCO BW is possible. If using non-TIBCO JDBC drivers then edit the file /tm/1.0/bin/setupenv.bat or /tm/1.0/bin/setup_env.sh. Set the variable TIBCO_TM_JDBC_JARS to the name of the non-TIBCO JDBC driver JAR file.
Java Open Transaction Manager (JOTM)
Transaction Recovery is not supported
Arjuna Transaction Service
The Arjuna Transaction Manager and the Arjuna Transaction Recovery Manager are started when TIBCO ActiveMatrix BusinessWorks is started and no additional recovery configuration is necessary as transaction manager and the recovery manager are started in the same Java VM. However, transaction recovery manager is disabled if TIBCO ActiveMatrix BusinessWorks is stopped or if Java VM crashes and transaction recovery occurs when TIBCO ActiveMatrix BusinessWorks is restarted. Running the Arjuna Transaction Recovery Manager in a separate Java VM allows transaction recovery to occur independently, regardless of the status of TIBCO ActiveMatrix BusinessWorks. After a failure, the ATS ObjectStore may contain the serialized TIBCO ActiveMatrix BusinessWorks Java classes. When running the recovery manager in a separate Java VM, the recovery manager requires references to the TIBCO ActiveMatrix BusinessWorks .jar files to de-serialize the classes. Therefore, when starting the recovery manager in a separate Java VM, verify the following:
- Classpath for the Arjuna Transaction Recovery Manager must contain the location of the TIBCO ActiveMatrix BusinessWorks .jar file. The following libraries must be included in \bin\setup-env.bat:
\lib\palettes\plugins.jar
\lib\engine.jar
\lib\TIBCOxml.jar
\lib\TIBCOrt.jar
\lib\TIBCrypt.jar
\lib\TIBCOjms.jar
\jdbc\TIbase.jar
\jdbc\TIutil.jar
\jdbc\TIoracle.jar
\jdbc\TIsqlserver.jar
\jdbc\TIsybase.jar
\jsbc\TIdb2.jar
\jms.jar
\odbc14.jar
- The ATS property file for the recovery manager must refer to the same ATS ObjectStore that is configured for TIBCO ActiveMatrix BusinessWorks
- Do not allow more than one Arjuna Transaction RecoveryManager to refer to the same ATS ObjectStore. That is, do not start one recovery manager in the same Java VM as TIBCO ActiveMatrix BusinessWorks, and then start another recovery manager in a different Java VM when both recovery managers are pointing to the same ATS Object Store.
- Recovery may not be ppossible id the ATS ObjectStore is modified or destroyed.
BusinessWorks supports including Event Sources such as JMS Queue Receiver, AE Subscriber in a transaction. For the XA Transaction Type, Event Sources can be included in the Transaction Group by selecting the Event Source in the Include In Transaction dropdown list. The transaction is created when the message arrives at the Event Source. However, in some cases the transaction is required to be created before the message arrives at the Event Source. BusinessWorks enables this feature by providing an option to create transactions at the Event Sources before the message arrives.

TIBCO ActiveMatrix BusinessWorks provides TIBCO Hawk microagent methods for monitoring XA transaction processed by TIBCO XA Transaction Manager or Arjuna Transaction Manager. Hawk console can be used to return a list of the transactions that are currently being processed or to return statistics for all transactions since the process engine started. The two microagent methods available for transaction monitoring are ListInFlightTransactions() and GetTransactionStatus().

- JMS Local Transaction
Allows JMS activities to participate in a transaction. The JMS specification defines the concept of a transacted JMS Session that can be used to transact sends and receives, all or none of which will get executed when the session is committed.
A session, when specified as transacted, supports a single series of transactions. Each transaction groups a set of produced messages and a set of consumed messages into an atomic unit of work. Multiple transactions organize the session’s input message stream and output message stream into a series of atomic units. When a transaction commits, its atomic unit of input is acknowledged and the associated unit of output is sent. When a transaction rollback is done, all the produced messages (output stream) are destroyed and the consumed messages (input stream) are automatically recovered. The JMS Local transaction type allows JMS sender activities - JMS Queue Sender and JMS Topic Publisher, Get JMS Queue Message activity, JMS Event Sources - JMS Queue Receiver and JMS Topic Subscriber, and Reply to JMS Message activities to participate in the transaction. At runtime, the underlying JMS activities use the same transacted JMS session to provide transaction semantics for messages sent and received by the JMS activities.
The ActiveEnterprise Adapter activities such as Publisher to Adapter, Adapter Subscriber and Adapter Request-Response Server can also participate in JMS Local transactions.
The JMS Requestors and Wait for JMS Queue/Topic Message activities will not participate in a local transaction even if they are included in a JMS Local transaction group.
The sessions participating in the JMS local transactions cannot process other messages outside the transaction. Since sessions are limited resources defined by Max Sessions property, the number of messages that can be processed simultaneously, and hence the throughput, can be affected.
To exclude a JMS Send activity from a transaction, check the Override Transaction Behavior in the advanced tab.
Limitations while working with HMS Local Transactions
-Several JMS activities present within the same JMS Local Transactional group, but referring to different sessions. These activities may refer to
Different Shared JMS Connection resources. Although two Shared JMS Connection resources are exactly identical, but the name of the Event Source may differ. I such cases, they will not be part of the same JMS Local Transaction.
Different messaging domains such as Queues and Topics
JMS Local Transaction does not span accross sessions. Each session is transacted individually and each session is individually committed in a single phase. However, when a failure occurs while committing a particular session, BusinessWorks stops the execution of the process with an exception and no attempt is made to rollback other sessions.
- JMS 1.1 not supported. JMS specification version 1.0.2b specifies that the messaging domains for Point-to-Point and Publish-Subscriber are handled by separate set of interfaces with no common base interface. Since BusinessWorks is compliant with this JMS Specification version, it is implied that Topic and Queue Sessions cannot share the same JMS session, although they may be required to transact in a single session context. The Sessions created in JMS Local Transaction can be either QueueSessions or TopicSessions but cannot be both. Thus, places a limit on the acticities that can participate in a single transacted session.
When activities using both Queue and Topic are in the same transaction group, it results in two separate transactions running independently. However, if one the transaction fails, it is difficult to predict the behavior of the other.
- Potential deadlock in Request-Reply activity. Including Request-Reply activities in a transaction may result in a deadlock situation when the Request and Reply happen on the same queue, and the Reply is bound to the message sent by the request. Similarly, including JMS Sender and Get JMS Queue Message activities in the same transacted session with the same destination may result in a deadlock. Hence to avoid these potential deadlock situations, Request-Reply activities are not included in transactions.
- Nested Trnsaction. Although it is technically posible to nest transaction groups, BusinessWorks does not support nesting transactions. Each group starts a separate transaction irrespective of whether the group is nested or not. transaction commits and rollbacks are always local to the nested group and are not affected by the outcome of the nesting group.
The activities that can participate in one transaction is determined by the type of transaction.
-Nesting JDBC transactions in a JDBC, XA, JTA, or JMS Local transaction is allowed, but each transaction is independent. That is, each transaction commits or rolls back separately. The outcome of the parent transaction does not affect the nested transaction.
-Nesting XA transactions in JDBC, XA, JTA and JMS Local transactions is allowed but each transaction commits or rolls back separately.
- Nesting JTA transactions in JDBC, XA and JMS Local transactions is allowed but each transaction is independent. Nesting JTA transactions in JTA transactions is not allowed. An exception is thrown at the start of the nested transaction.
- Nesting JMS Local transactions in JDBC, XA, JTA and JMS Local transactions is allowed but each transaction is independent. That is, each transaction commits or rolls back separately. The outcome of the parent transaction does not affect the nested transaction.
- Activities that participate in JDBC Transactions
JDBC activities
TIBCO iProcess BusinessWorks Connector activities
- Activities that do NOT participate in JDBC Transactions
JMS activities
ActiveEnterprise Adapter activities (using JMS transport)
EJB activities
- Activities that participate in XA Transaction
Checkpoint (specified by the Include Checkpoint field of the transaction group) (when a database is used to store checkpoint data and the JDBC Connection is configured to use the XA connection type)
JDBC activities (when the JDBC Connection is configured to use XA transaction type)
TIBCO iProcess BusinessWorks Connector activities. (When XA connection is used)
JMS activities (When JMS is configured to use an XA connection) (Request/Reply operations are not permitted in transactions. Process starters and Wait For activities cannot be part of an XA Transaction group, but their acknowledge message can participate in the transaction if the resource is configured to use the Transaction field of the transaction group. However the acknowledge message for Wait for JMS Topic Message activities cannot be part of the transaction.
ActiveEnterprise Adapter activities (using the JMS transport). (When JMS is configured to use an XA connection)
- Activities that do NOT participate in XA Transaction
EJB Activities
- Activities that participate in JTA Transaction Type
Checkpoint (specified by the Include Checkpoint field of the transaction group) (Supported by -BEA server when database used to store checkpoint data and the JDBC Connection is configured to use the JNDI connection type)(Not supported in IBM nor JBoss servers)
-JDBC Activities (Supported by BEA server when the JDBC Connection is confiured to use the JNDI connection type) (Not supported in IBM nor JBoss servers)
-JMS Activities (Supported by BEA Server when using BEA JMS server, not supported by BEA when using EMS) (Not supported by IBM nor JBoss application server)
-EJB activities

- Duplicate messages should be detected and discarded to avoid processing the same event more than once.
- Duplicate detection is performed when a process instance executes its first Checkpoint activity.
- A value should be specified for duplicateKey element in the Checkpoint activity input schema. This value should be some unique key contained in the event data that starts the process.
- Duplicate detection process by process engine.
1. Incoming message received and process instance created
2. Activities in process instance are executed until the first Checkpoint activity is reached. The Checkpoint activity has a value specified for the duplicateKey input element.
3. Process engines checks the current list of duplicateKey calues for a matching value.
a. If no process instance has stored the given duplicateKey value, the process engine stores the value and completes the Checkpoint activity.
b. If another process instance has already stored the given duplicateKey value, the process engine terminates the process and throws a DuplicateException.
4. Once a process engine stores a duplicateKey value and performs the Checkpoint for a process instance, no other Checkpoint activities in the process instance can be used to store a different duplicateKey value.
- Duplicate detection can only be done across multiple engines on different machines if a database is used to store process engine data. If fault tolerant process engines are running (only one process running at a time) or if all process engines run on the same machine, file system can be used for process engine storage.
- While detecting duplicate messages, it is important to place the Checkpoint activity before any activities that are notgoing to be executed more than once.
- Duplicate detection is only as efficient as unique the dupicateKey that is specified is.
- Transaction groups using certain types can allow Checkpoint activities to be performed as part of the transaction. In this case, the checkpoint performed for the transaction may be the first checkpoint in the process definition
- Process Engine properties that control duplicate key detection
- bw.engine.dupKey.enabled. Specifies whether duplicate detection is performed
- bw.engine.dupKey.timeout.minutes. specifies how long (in minutes) to keep stored duplicateKeys. The default is 30 minutes. 0 indicates the duplicateKey is removed when the job is removed. However, if bw.engine.enableJobRecovery=true, the job is not automatically removed after a failure so the duplicateKey will remain as long as the job remains. Such a job can be restarted or purged later.-1 indicates to store duplicateKey values indefinitely.
- bw.engine.dupKey.pollPeriod.minutes. Specifies the number of minutes to wait before polling for expired duplicateKey values.
-Process instances can be executed in the order they were created. TIBCO ActiveMatrix BusinessWorks allows to specify a sequencing key on process starters that determines which process instances to execute sequentially.
- Process instances with sequencing keys that evaluate to the same calue are executed in the order they were started. Process instances can have sequencing keys that evaluate to different values, but only process instances with the same value are executed in the order they were started. Process instances with different sequencing key values can be executed concurrently.
- TIBCO Administrator allows to control maximum number of process instances in memory as well as maximum number of concurrently executing process instances. Using these administrator setting is only recommended when process definitions cannot be changed in project before deployment.
- TIBCO ActiveMatrix BusinessWorks provides the bw//lib/log4j.properties file to allow to configure logging services for third party components. The properties defined in this file are required by the components used by TIBCO ActiveMatrix BusinessWorks. Do not remove any required property.
- It is a good idea to create a backup copy of the log4j.properties file before altering it.
- There can only be one log4j.properties file per Java VM. If a different log4j.properties file is going to be used, add properties to bw//lib/log4j.properties or alter bwengine.tra to point to the location of the custom log4j.properties file.

- In order to handle inter-process communication TIBCO ActiveMatrix BusinessWorks provides the Wait, Notify and Receive Notification activities from General Activities palette.
- A process containing a Wait activity waits for another process to execute a corresponding Notify activity. Alternatively, the Receive Notification process starter creates a new process instance when another process executes the corresponding Notify activity.
- The data sent between the activities is defined by a Notify Configuration resource.
- The Notify activity only sends information to the Receive Notification or Wait activities that specify the same Notify Configuration resource.
- A string-based key is used to coordinate between Wait/Notify/Receive Notification activities to determine when a Notify activity corresponds to a Wait or Receive Notification. The key is supplied to the Notify activity and any Wait activity that matches that key is executed when the Notify occurs
- When a Notify activity executes, its information is stored until a matching Receive Notification accepts the information, The Notify activivity executes immediately and transitions to the next activity. The Notify activity cannot be used to determine when a corresponding Receive Notification or Wait has received the information.
- Steps for inter-process communication.
1. Define the data that must be passed between the processes by creating a Notify Configuration shared configuration resource.
2. Determine the key that correlates processes with Notify activities with the corresponding processes with Receive Notification process starters or Wait activities.
3. Create process definitions that use the Receive Notification, Wait, and Notify activities which are located in General Activities palette.
4. If process engines are in different machines, a database must be used to store process instance information Wait/Notify information is stored in a database so that process engines on different machines can share information.
- The Notify Configuration shared configuration resource defines the data that the Notify activity passes to the corresponding Wait activity or Receive Notification process starter
- When configuring Receive Notification, Wait and Notify activities, a key should be specified to coordinate which activities correspond to each other. Also a timeout can be set to specify for how long to keep the the information about Wait and Notify activities before it is removed from storage
- Any XPath expression that evaluates to a string can be used in order to set the event key. A global variable can be used to set the key for a Receive Notification activity
- Any Notify activity corresponds to exactly one Receive Notification or Wait activity (the first Wait or Receive Notification activity that matches the key, can then execute)
- Many Notify activities with the same key can be executed.
- Timeouts define how long information will be kept before it is removed from storage
- Although Notify activity transitions immediately to the next activity in the process definition, timeout value is used to specify for how long the information should be kapt in storage before it gets removed.
- Wait activity will wait for notification from Notify activity until the timeout is reached.
- Receive Notification does not contain a timeout field.
- If process engines are located in different machines, a database is required to store process instance state for inter-process communication. A database allows process engines to share process instance state information across machines in a domain. Deployment COnfiguration must specify a database for process engine storage if it is expected that process instances on different machines to have corresponding Wait/Receive Notification/Notify activities.
- Distributing incoming events across multiple process engines allows a greater scalability because the load of incoming events is distributed.

- Web Services provide a standard-based approach for application integration between or within organizations.
- Standards that web services comply
-HyperText Transfer Protocol (HTTP) or Java Message Service (JMS). Transports or mechanisms to relaying information.
-Simple Object Access Protocol (SOAP) v1.1 or v1.2. Communications protocol that defines message structure and bidings to the underlying transports.
-EXtensible Markup Language (XML).Used to define data schemas for SOAP message content
-Web Service Definition Language (WSDL). Describes the interface to a web service. A Web Service provider publishes a WSDL file that describes the offered service. A client uses the WSDL file to determine the appropriate input, output and fault messages for the service.
- Web Service Security (WS-Security). Standard-based approach to message-level security which allows to secure messages that may travel through multiple hops on a distributed transport channel.
- Operations can be one-way (no information returned), or request-response (a response message is returned)..
- TIBCO ActiveMatrix BusinessWorks can act as either a web service or a web service provider.
- There are two approaches to implementing web services as a web service provider in TIBCO ActiveMatrix BusinessWorks.
-The SOAP Event Source process starter creates a simple service with one operation over one transport.
- The Service resource allows to create a service that implements multiple operations offered over multiple transports.
- A service implements one or more interfaces and exposes one or more endpoints per interface.
- The interface is a PortType in a WSDL 1.1 file.
- The endpoint is referred to as Port. However it does not imply a physical network address where the service is listening.
- Services provide an abstraction of web services so that a more generic service-oriented architecture (SOA) that is not dependent upon a specific transport can be implemented.
- Services decouple the underlying transport from the implementation.
- Endpoints available in TIBCO ActiveMatrix BusinessWorks
SOAP over HTTP
SOAP over JMS
Local
- A service joins an abstract WSDL interface to concrete implementations and exposes them on one or more endpoints.
- A web service client invokes one of the abstract interface operations using configuration settings provided by the service in form of concrete WSDL bindings.
- Context resource allows to create an schema for storing relevant context information.
- Each operation within Service resource can reference a different Context resource.
- Data from incoming request can be mapped to Context resource
- Get Context and Set Context activities can be used to handle information within the Context.
- Configuring a Service
-WSDL file. Describes the operations contained in the service and input, output and fault messages for the operations.
- Endpoint bindings. Endpoint expose the location of the service to the service partner. An endpoint binding specifies the transport to use for the endpoint, any transport-specific properties, and any SOAP details (SOAP version, SOAP action, etc).
- Operations Implementation. Each process definition must specify the process definition to execute the operation.
-In TIBCO ActiveMatrix BusinessWorks process definitions implement operations. The input, output and error schemas must match the input, output, and fault messages specified for the operation.
- Only one WSDL message should be specified as root of input, output or error schema.
- When a project containing a Service is deployed and run, a service agent is created for the service resource. The service agent waits for incoming requests on specified endpoints and creates process instances to execute the implementation for the operation. For each incoming request, the service agent passes the request’s input message and any specified context information to the process instance that implements the requested operation. The process instance executes and sets the appropriate values in the output or fault messages if an error occurs. The service agent then sends the output or fault message to the client.
- Partners are external services that can be invoked from BusinessWorks process definitions. Partners are defined by a name and a WSDL portType that describes the operations that can be invoked.
-The Invoke Partner activity is used inside a process definition to invoke an operation on partner service.
- The Receive Partner Notification activity is used within a process definition to invoke notification services, where notification service sends a message that the invoker receives.
- Partner can be either inside the same project as the process that invokes the service,or the partner can be an external partner service invoked over the Internet by way of SOAP protocol.
- Add or remove partners from the Partner tab in a process definition.
Partner Name. Name of the partner
Port Type. WSDL containing the portType for the partner
Port Type Namespace. Namespace of the partner.
Partner Link. Partner Link Configuration resource that contains the Partner endpoint. If this is specified, it is not required to specify the Partner Binding tab in the Service, when this process definition is used as an operation implementation.
- Partner Link Configuration resource associates partners with endpoints. The service can then correlate partners invoked by the operations with the partner link configurations that specifies the actual binding to endpoints. Instead of specifying the actual endpoint of a partner service in the process definition, specify the interface, and the let the service that uses the process bind the interface to the actual endpoint. This allows to easily change third party partner services without changing the implementation.
- Endpoint operation of a partner link defined in a Partner Link Configuration resource acts as a security subject and the security policies can be applied to it. There is a unique association between the partner link service endpoint opertaion security subject and the applied security policies.
- The SOAP event source policies are applied at the operation level. The policies applied to a Partner Link Configuration resource are always at the service endpoint operation level.
- Applying a policy on a Partner Link Configuration,
1. Add a new Partner Link Configuration resource onto design panel
2. Click the + button to add a Partner Link with SOAPEndpoint.
3. Drag and Drop Security Policy Association resource onto Design Panel.
4. Drag and Drop Secrity Policy resource onto Design Panel.
5. Name the Security Policy
6. From Policy Type dropdown, select inbound
7. Click the select button to the right of the Apply Policy to field. In the Choose Security Subject, expand Partner Link Configuration resource and select a service enpoint operation.
8. CLick the Browse button in the Inbound Message Policy field. In the Select a Resource dialog, expand Policies and select, Inbound Security Policy
- Partner Link Configuration fields
- Apply Policy To. Associate security policy with PortTypeEndpoint.
- Inbound Message Policy. Associate message being received with security policy
- Outbound Message Policy. Associate message being sent with secrity policy
- Inbound Fault Message Policy. Apply security policy to fault messages being received
- Outbount Fault Message Policy.. Apply security policy to fault messages sent.
- Using the service endpoint operation as the security subject ensures consistency in associating the security policies with the service resources. The service resource also exposes the service endpoint operation as a security subject. Exposing partner links as security policy subjects ensures a WS-Security support for all the TIBCO ActiveMatrix BusinessWorks or TIBCO ActiveMatrix BusinessWorks BPEL extension constructs that use partner links for outbound invocations. This implies that the Invoke Partner activity is WS-Security enabled if, it is bound using a partner link that has a SOAP endpoint.
- Use the SOAP Request-Reply activity in order to perform SOAP requests.
- Web Services are described by WSDL files. It can be retrieved in order to store it in the project.
- Web service may be configured to send a reply or a fault. When a web service sends a fault, the fault is stored in the error output of the activity and an error transition is taken to the next activity in the process definition. One-way operations do not receive reply or fault messages.
- The SOAP Request Reply executes synchronously.
- SOAP Event Source process starter defines the concrete WSDL file for the web service. SOAP clients must retrieve the concrete WSDL file before sending a SOAP request to the service. The WSDL palette allows to locate and store existing and concrete service definitions or create own abstract service definitions. If using an existing concrete service definition, the concrete bindings are ignored and service can be configured to use different namespaces and input/output headers.
- Using SOAP Event Source allows to use WSDL interface files that have only one operation. Only one operation can be implemented by the process definition containing the SOAP Event Source. In order to implement a web service with multiple operations, use Service resource.
- Creating a web service.
1. Create XSDs to define input, output and messages for the web service
2. Create a WSDL file resource that defines the interface to the web service.
3. Create a process definition that performs the work of the web service. Use SOAP Send Reply activity in order to return a reply or the SOAP Send Fault activity to return a fault to the client.
4. Create a web service that retrieves the concrete WSDL file and sends it to the web service clients. Use the HTTP Receiver process starter and the Retrieve Resources activity for this process definition.
- SOAP messages can have parts that contain attachments. For a message part to contain an attachment, specify the Special Type in the Type field of the Part Details section of the Message resource when creating a WSDL file configuration
- The messages are transmitted separately as MIME attachment and the SOAP message may or may not have a reference to the reference.
- The actual data for the attachment is always contained within the mimeEnvelopeElement of the output schema for the given resource. This element contains a repeatable element named mimePart that holds the list of attachments in the SOAP message. The attachment list can be correlated to the message parts containing the attachments by using the content-id mimeHeader element. Note that the attachement is not part of the SOAP infoset. For all existing projects, the Sw A attachment style is the default option.
- Message Transmission Optimization Mechanism (MTOM) provides another way of sending binary content or attachment processing by serializing SOAP messageswith attachments (only avaliable with SOAP 1.2). Optimization is only available for element content that is in canonical lexical representation of xs:base64Binary data type.
- For an outbound SOAP message with MTOM attachments sent by SOAP Request Reply or SOAP Send Reply activities, any element of type xs:base64Binary in the SOAP response message is treated as an MTOM attachment and appears as a separate MIME part on the wire.
- For an inbound SOAP Message with MTOM attachments received by SOAP Event Souce or SOAP Request Reply activities, the SOAP message will have a XOP include reference to the attachment. Any XOP include reference in the SOAP message will be replaced by the corresponding attachment’s content encoded in base 64. Any MIME attachment that is not referenced from the SOAP Message using XOP include reference will be ignored by the MTOM Processing Layer. Although the message is transmitted outside the SOAP message with a reference to it, the attachement appears as if it’s embedded in the SOAP message. The binary content is part of the SOAP infoset. MTOM-style attachments are available inline with the SOAP message at as shown.
- A runtime error wll be thrown if a SOAP 1.1 message with MTOM attachments is received.
- There are two wizards to create web services in TIBCO ActiveMatrix BusinessWorks
- To expose one or more process definitions as web services
1. Select a process definition that has input, output and error schemas defined in XSD.
2. Create a transport shared resource (either HTTP or JMS Connection)
3. Select and right click on the name of one of the process definition in the project tree
4. Choose Tools or Multi-User > Generate Web Service > From Process from the pop-up menu
5. The Generate Web Service dialog appears
-Namespace.
-Port Type. Name of the interface for the web service
-Transport. Transport for incoming messages (HTTP or JMS). The default is the first connection found in the project tree.
-Location. Location in the project to place the generated Service and WSDL resources
-Operation Names. List of operations in the generated service interface which contains the process definition names. The Add More Processes to Interface button to select other process definition to include in the service interface.
-Process Chooser.Contains the Add More Processes to Interface button to select other process definition to include in the service interface
6. Click Generate button to create a Service and a WSDL resources(Service resource name: intf-service WSDL file name intf).
7. Setting Endpoint URI for HTTP transport might be needed. For JMS transport, Destination name must be specified.
- To generate web service stubs (to implement the web service) based on a WSDL file
1. Place WSDL file in project directory
2. Open project in TIBCO Designer
3. Create transport shared resource (either HTTP or JMS connection)
4. Right click on the WSDL resource
5. Choose Tools or Multi-User>Generate Web Service>From WSDL from pop-up menu
6. Set values on dialog
- Port Type. WSDL file and name of the interface for the web service
- Transport. HTTP or JMS shared resource. Default is the first HTTP or JMS connection found in the project tree
- Location. Location in the project to place the generated Service and WSDL resources
7. Click Generate to create Service resource and process definition stubs for operations in WSDL file. Service resource is named -service.
8. Click the -service resource to display the resource. Setting Endpoint URI for HTTP transport might be needed. For JMS transports, Destination Name must be specified.
9. Click on each process definition stub and provide implementation for each operation.
- TIBCO AciveMatrix BusinessWorks allows to specify security policies for inbound and outbound SOAP messages. Security policies follow Web Services Security:SOAP Message Security 1.0, OASIS Standard 200401
- Security policies are defined in Security Policy shared configuration resource.
- One policy can be set and shared among all web services. Multiple security policies can also be defined and used on a per-resource basis.
- Policy attributes.
Authentication. User/Password or X.509 compliant certificates
Integrity. Whether messages must be validated with a signature to ensure the message has not been altered since its creation.
Confidentiality. Whether messages are encrypted or unencrypted
Timeout. Whether messages should expire after a certain time.
- Errors generated from Web Service Security Policies are not published due to malicious users can attempt to gain information about security policies by attempting to replicate known errors. Only licensed users can request a list of error messages and code by contacting TIBCO Support
- Security Policy Association allows to associate a security policy with a web service.
- A Security Policy can either be associated with a SOAP activity or an operation in a Service resource.
- Security Policy Association resources are not automatically included in EAR files as they are not referenced by process definitions. They must be manually added to a Shared Archive within an EAR file.
- When a policy is associated with a Service operation, it applies to all regular or fault inbound and outbound messages for the operation. When it is applied to a SOAP resource, it applies to messages sent or received by the activity.
- Although more than one Security Policy Association can be created for the same SOAP or Service resource, this is not recommended, because only the first Association will be used and all others will be ignored.
- To run a project with security associations successfully, ensure that all the policy associations in the project are valid. Any invalid associations must be removed from the project before running the project.
- Authentication is checked against user and passwords in TIBCO Administrator, which can also point to an LDAP registry for username/password lookup. Password callback class can be written by implementing interface javax.security.auth.callback.CallbackHandler interface which must iterate over CallbackHandler object and look for WSPasswordCallback type. Method WSPasswordCallback.getIdentifyer() to obtain the username. Then, code can be written to lookup the password for that username in system. Once obtain, password must be set in the Callback objectusing setPassword method.
- To use custom password lookup in a security policy.
1. Compile Callback object in a jar file
2. Open TIBCO ActiveMatrix BusinessWorks project containing the processes for which you are creating security policies.
3. Click General Palette, and drag and drop an AliasLibrary resource into design panel.
4. Place Callback object .jar file into the AliasLibrary resource and include classes that the object depends on
5. Click Policy palette and drag and drop a Security Policy resource into design panel.
6. On the Configuration tab, click the checkbox in the Custom Password Lookup field.
7. In the Custom Password Callback Java Class field, browse the AliasLibrary resource.
8. In the Class field, use the Show Class Browser button to locate and select Callback object.
9. Click apply and then associate the security policy resource with the desired web services
10. Save the project.
- Not applying inbound or outbound security policies is allowed in ActiveMatrix BusinessWorks because it allows the propagation of security context information sent by TIBCO ActiveMatrix Policy Manager and its mapping to appropriate fields in security context in ActiveMatrix BusinessWorks. The security context information is available only when a policy is applied and the information is sent by TIBCO ActiveMatrix Policy Manager.
- ActiveMatrix Policy Manager sends security information as an XML document, either as part of the header when HTTP transport is used or as a message property when JMS transport is used. Security information is available under the header com.tibco.security.userinformation.
- When Service resource or SOAP Event Source activiy receives such a message, it processes the XML document from the header and propagates it in its output tab.
- ActiveMatrix BusinessWorks propagates the incoming security context to all outbound invokes by adding the security information as HTTP header in case of HTTP or as property in case of JMS transport.
- In order to enable security context propagation from TIBCO Policy Manager, select the Expose Security Context checkbox available on the Configuration tab of the Service resource or SOAP activity using either HTTP or JMS transport.
- Security Context types from ActiveMatrix Policy Manager that TIBCO ActiveMatrix BusinessWorks can propagate
- Authenticate Username Token. TIBCO ActiveMatrix BusinessWorks only propagates the username because ActiveMatrix Policy Manager does not give out the complete Username Token. Password and Password type values in the security context will be empty.
- Authentication Certificate Information and Signature Certificate Information. TIBCO ActiveMatrix BusinessWorks propagates the certificate information consisting of Subject_DN, Issuer_DN, Serial No and encoded certificate.
- Inbound policies available in Policy Manager and the corresponding policies in BusinessWorks
Inbound Policy in ActiveMatrix Policy Manager (Available Security Context in ActiveMatrix BusinessWorks)
Authentication - IMS (Authentication UserName Token)
Crypto - Check Signature (Signature Certificate Infotmation)
Authentication Signature and Crypto - Check signature. (Authentication Certificate Information and Signature Certificate Information)
Authentication Signature. (Authentication Certificate Information and Signature Certificate Information)
Authentication - IMS and Crypto, Check signature. (Authentication Certificate Information and Signature Certificate Information)
Authentication - IMS and Crypto - Encrypt or Decrypt. (Authentication Certificate Information and Signature Certificate Information)
- Limitations to Security Context Propagation from TIBCO ActiveMatrix Policy Manager
- For Authentication UserName token policy only user name value will be available (password and password type fields will be empty)
- TIBCO ActiveMatrix BusinessWorks will not propagate any extra information given out by ActiveMatrix Policy Manager.
- Transport Security Context in TIBCO ActiveMatrix BusinessWorks will never be populated with the clients transport security context when security context is propagated by ActiveMatrix Policy Manager due to ActiveMatrix Policy Manager does not propagate the Transport Security Context received from the client.
- Signature using Username Token is not available in ActiveMatrix Policy Manager. As a result, it cannot be supported by ActiveMatrix BusinessWorks when using ActiveMatrix Policy Manager.
- TIBCO ActiveMatrix BusinessWorks uses persistent object framework (POF) API to authenticate with TIBCO Administrator in the standalone mode. Alternatively, JAAS login can be used to authenticate TIBCO ActiveMatrix BusinessWorks. To do so,
1. Run TIBCO Domain Utility to create an administration domain and enable HTTPS.
2. Create a text file named jaas.config and copy the following contents in it
AuthenticationService{
com.tibco.atlas.auth.jaas.AuthenticationServiceLoginModule required
soap_username=”a”
soap_password=”#!bflsdjhfiorngoiue/w==”
authority=”localhost:5443”
scheme=”https”;
};
Where soap_usernameis the super user name of the admin server and soap_password is the obfuscated password for the above user.
Username and password information can be retireved from AdministrationDomain.properties file located in $TIBCO_Home\tra\domain\. User name and password are provided as name=value pairs with UserID and Credential. Remove \ characters
authority=”localhost:5443” specifies admins servers host and https port.
jaas.config file can be located anywhere but its location must be set to com.tibco.bw.security.login.jaas java property in bwengine.xml file.
3. Edit bwengine.xml file and recreate the EAR file before redeploying the project.
4. Add the following java property to bwengine.xml file
java.property.java.security.auth.login.config=\jaas.config
To use other keystores than the ones used by JRE by default.
java.property.javax.net.ssl.keyStore=C:\tibco\administrator\domain\\SSL\keyStore
java.property.javax.net.ssl.keyStore=password
java.property.javax.net.ssl.trustStore=C:\tibco\administrator\domain\\SSL\keyStore
java.property.javax.net.ssl.trustStorePassword=password
To use default keyStore export the certificates from Admin Server’s keyStore using keytool and import them into JRE’s keyStore
5. Enable JAAS authentication by adding property in bwengine.xml
java.property.com.tibco.bw.security.login.jaas=true
- Universal Description, Discovery and Integration (UDDI) refers to the protocol used by web-based registries to publish information about web services. TIBCO ActiveMatrix BusinessWorks supports both browsing and publishing to UDDI registries that comply with UDDI 2.0 API specification. UDDI registries can be accessed via TIBCO Designer and TIBCO Administrator. TIBCO Administrator provides a UDDI module that allows to browse and publish web service details.
- Web Service Inspection Language (WSIL) is an XML document format that is similar in function to UDDI but simpler in implementation. TIBCO ActiveMatrix BusinessWorks supports browsing WSIL files that comply WSIL 1.0 specification.
- Business publish information about the web services they offer using WSIL or to UDDI Operator Sites.
- In TIBCO Designer, the Tools>UDDI menu brings up the WSIL and UDDI Registry browser dialog which allows to browse web services or publish the details of a web service
- Tabs of WSIL and UDDI Registry browser
Configuration. Specifies required information to connect to UDDI server
- Inquiry URL. Select either UDDI or WSIL, then enter the URL for accessing the WSIL files or the UDDI registry
- Publish Info
- Publish URL. URL to use for publishing information to UDDI registry
- User. User name for publishing to UDDI registry
- Password.
- SSL Configuration
- Trusted Root Certs Folder. Folder in the project containing one or more certificates from trusted certificate authorities.
- Proxy Server Setting. When accessing the registry by way of a proxy server
- Host
- Port
- User Name
- Password
Browse. Search criteria to locate web services (also displays the result of the search)
- Search Fields
- Search type. Select one of the options (Service Name, Business Name, Tmodel Key, All WSDLs, NAISC, DUNS, ISO 3166)
- Search term. Only entries with the specified search term are retrieved.
- Max Rows. Maximum number of services to return
- Case-Sensitive
- Order Asc
- Exact Match
- All WSDLs Area for searches based on WSDLs, NAISC, DUNS or ISO 3166
- Get Services button. Select a WSDL in the All WSDLs field then click the Get Services button to return the service details in the results table.
- Result Columns.
- Service Name.
- Business Key. UDDI key for the service
- Description.
- WSDL Access URL. WSDL file or URL for accessing the WSDL file
- Delete Service Button. Removes the selected service from the list of returned services.
Publish. Allows to specify web services to publish to a UDDI registry
- Business Details Sub-tab
- Name.
- Key. Business key (UDDI) for the company
- Description.
- Contact. Name of person or organization to contact in company.
- Address. Address of the person or organization specified in Contact field
- Phone.
- Email.
- Services Sub-tab. Specifies the web service to publish
Name.
Description.
WSDL URL. URL of the WSDL file for the web service.
Endpoint URL. The URL of the deployed web service.
Publish Button. Publishes the specified web services to a UDDI reqistry.