lunes, 17 de octubre de 2011

TIBCO BusinessWorks Administration Notes (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 Administration 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...

- In order to view and change the status of all process engines running i the Administration Domain Application Management > All Service Instances. The console also displays the software for which there are running instances
- To view all process instances for an application, select the corresponding application, then choose Service Instances. Only process engines for that application are displayed.
- Starting or Stopping a Process Engine.
- In the Application Management > All Services console, click the checkbox next to a service or process, and then choose the appropriate button which becomes available.
- In Application Management module, select All Service Instances console and then click the instance name. In the window displayed, select General tab. State has a clickable word next to it that allows to start or stop service instances.
- In Application Management module, select the Service Instances console for the application, click the checkbox next to a service instance and then choose the appropriate button which becomes available.
- A service instance can be started when it is deployed, or they can be explicitly started after deployment.
- TIBCO Administrator itself is also listed as a component software. Shutting down the TIBCO Administrator is not recommended as a stopped server cannot be started from TIBCO Administrator. It can be restarted is a database domain is used or if there is a secondary server defined in the domain. Select the server and choose Restart. In that case a ‘Page cannot be displayed’ is shown. TIBCO Administrator GUI should be invoked again and log in once more.
- Shutting down the administrator server does not stop running processes or services in the domain. However they cannot longer be monitored and no component can be restarted in case of a failure. In addition, some components load configuration information on demand which will fail if the administration server is not available.
- Starting or stopping process engines.
1. Under Application Management select All Service Instances or go directly to a specific application and select All Service Instances.
2. Select the service instances, process engines or both to start and click Start. Click Stop or Kill to shutdown the service instance or process engine
- Starting or Stopping a Process Engine in a Service Container. If multiple applications related to a single Designer project in a service container, those applications can be started or stopped from TIBCO Administrator.
- Tracing options are set in TIBCO Designer when configuring a service or process. Tracing options for a process or service instance can be viewed and set search parameters to display only a subset of a log file. Log can also be exported to a file.
- When Trace tab is displayed, the log file to get information from is specified as well as the number of lines to return.
- Date/Time before/after. Specify a date to filter. Two dates can be used to create a range.
- Role. Allows to choose only traces to certain roles. Choose Info, Warning, Debug, Error, or specify a Custom role.
- Category. Specifies a category. Items for that category are then sent to the trace. Categories include Configuration, Application, Adapter, Database, TibRvComm and XML.
- Detail description. Allows to specify a detail description for which it is required to display (or not) all log entries.
- To view tracing results for a process engine
1. Under Application Management, select All Service Instances or go directly to a specific application and select All Service Instances.
2. Click the process engine name.
3. Click the Tracing tab
4. Click details to drill-down view the entry.
5. To export an entry to a file, select the item(s) to export.
6. Click Export.
7. Click Done.
- Editing Process Engine Properties.
1. Under Application Management, select All Service Instances or go directly to a specific application and select All Service Instances
2. Click a process engine name.
3. Click the BW Processes name
4. Select an item from the drop-down menu. The panel changes, depending on selection.
5. Click Done.
- Viewing the TIBCO Administrator Audit Log. For TIBCO Administrator, tracing cannot be configured. Audit log can be viewed and filtered to better view the information needed.
1. Click Application Management > All Service Instances
2. Select TIBCO Administrator
3. Click the Audit Log tab.
4. Click the Search button to display the Administrator log
5. Optionally, add a search condition and click Search.
6. Click details to drill-down view the entry
To export an entry to a file, select the items to export
1. Click Export
2. Click Done.

- A checkpoint saves the state of a process instance at a given point in time. Checkpoints are used to restart or recover a process instance either when an engine fails or if the process instance fails by encountering an unhandled exception or by manual termination in TIBCO Administrator or TIBCO Hawk.
- In the event of an engine failure, by default all process instances executing at the time of the failure are automatically restarted and begin executing from the last checkpoint. Process instances can be configured to not start to be automatically restarted when the engine restarts. To specify that checkpointed process instances should not automatically restart when a process engine restarts, set the custom property bw.engine.autoCheckpointRestart to false.
- When a process instance fails, checkpoint data for the process instance is deleted. Optionally, it can be specified that checkpoint data should be saved for terminated process instances so that the process instance can be recovered at a later time. Failed process recovery can be enabled by setting the custom property bw.engine.enableJobRecovery to true.
Recoverable processes can be managed either through TIBCO Administrator, TIBCO Hawk, or programatically using the Engine Command activity in a process instance.
- Managing and Restarting recoverable process instance.
1. Under Application Management, select All Service Instances or go directly to a specific application and select All Service Instances.
2. Click a process engine name.
3. Click the BW Process tab.
4. Select Recoverable Processes tab.
5. Check the box next to the process instances to manage. Click the Restart button to restart the process instances or click the Remove button to remove the process instances from the list of recoverable processes.
- Limitation of Recoverable process instances.
- If a Java object reference is normally shared among process instances, process instances that start normally or are restarted during process engine startup retain the shared references to the object. However, a process instance that is recovered after a process engine starts receives a unique copy of each Java Object that it references.
- If a recovered process instances uses sequencing, then the process instance may not be able to be restarted if there is already a process instance currently executing that has the same sequence key. Such a job can only be restarted when no other process instances are running.
- If a recovered process instance has a duplicate detection key, then the key is only released when the process instance finishes normally or is deleted.
- The View Service Instance Dialog displays cumulative statistics for process engines. Statistics can also be stored for each executed process instance and each executed activity. Statistics are stored in a comma-separated value (CSV) format that can be imported into most analytical tools, such as Microsoft Excel.
- Statistic collection is controlled differently for process engine statistics and activity statistics.
Statistic collection for process instances is controlled by a custom engine property.
Statistic collection for activities is controlled dynamically while the process engine is running.
- Collecting statistics on a per process instance or activity basis affects the performance of the process engine. Extra processing and I/O is required for gathering and writing the statistics to a file. Collecting statistics on an activity basis is especially resource intensive. It is recommended that activity statistics are collected for brief periods of time while determining the prformance requirements of a system of while tuning an application. It is not recommended that activity statistic conllection is run continuously on a production system.
- Process Instance Statistic Collection. Process instance statistic collection is controlled by the custom engine property bw.engine.jobstats.enable. The default value of this property is false indicating that statistics for each process instance should not be stored. Setting this property to true enables the gathering of statistics for each process instance.
- Activity Statistic Collection. Activity statistic collection using either TIBCO Administrator or TIBCO Hawk commands can be enabled or disabled.
1. Under Application Management, select All Service Instances or go directly to a specific application and select All Service Instances.
2. Click a process engine name.
3. Click the Engine Control tab
4. In the Statistics Collection pane, click the Start button to begin statistics gathering for activities or click the Stop button to halt statistics gathering. The current status of statistic gathering is detailed in the Status field. If statistics gathering is disabled, the Status is Off. If statistics gathering is enabled, the Status field details the location of the file containing activity statistics.
- Statistic collection for the activity elapsed time in the Ouput schema of JDBC activities can be enabled by setting the property java.property.bw.activity.output.stats.elapsedTime.activity_name in designer.tra for design time and bwengine.tra for runtime. Setting this property causes a performance overhead and hence the use of this property is recommended in a non-production environment as a diagnostic tool. This property can be turned off and not calculate the elapsed time at run-time by setting the property java.property.bw.activity.output.stats.elapsedTime.turnoff in the bwengine.tra file
- Managing Statistics Files. Separate files are kept for process instance statistics and for activity statistics.
The name of the activity statistics file(s) are in format
stats--.csv
The name of the process instance statistics file(s) are in the format
jobStats--.csv
Files are stored in a location determined by bw.enigine.stats.dir custom engine property. Default location for this property is /stats.
- For activity statistics, a new file file is created each time statistics collection is enabled. For process instance statistics, a new file is created each time the process engine is started or when the statistics file reaches the specified size. Maximum size for job statistics files is specified with the custom engine property bw.engine.jobstats.rollover. The property specifies the maximum size in megabytes.
- Process instance statistics. One record per process instance is created and stored.
Statistic    Description
jobId    ID of the process instance
processName    Name of the process definition the process instance is executing
startTime    Time stamp at process instance start
endtime    Time stamp at process instance completion
elapsedTime    The endTime minus the startTime. The total clock time that has elapsed during the execution of the process instance.
evaltime    The sum of the evaluation times for each executed activity in the process instance. Evaluation time is the time between the beginning and end of the evaluation period. This should be close to but is not exactly equivalent to CPU time, due to the limitations of statistic computation.
status    Status of the process instance at completion. This can be either success or error

-Activity Statistics. One record per completed activity execution is created and stored.
Statistic    Description
startTime    Offset (in milliseconds) from the start of statistic gathering to the time the activity was invoked.
elapsedTime    The time when the activity ended minus the time the activity started. The total clock time that has elapsed during the execution of the activity.
evalTime    The time between the beginning and end of the evaluation period for the activity. If the activity completes in one step, the evalTime and elapsedTime would be the same. However, some activities, such as Request/Reply or Wait For... activities typically do not complete on one step.
jobId    ID of the process instance in which this activity executed.
processName    Name of the process definition the process instance in which this activity is located.
callStack    When the activity is executed as part of a called process, this column contains the call stack from the original process to the called process.
paged    Specifies whether the process instance was paged out to disk when the activity was involved.

- All Service instances Dialog.
- Search. Allows to display only the items that match a search criteria
- Start. Starts the selected process engine(s)
- Restart. Stops the selected process engine(s), and then starts it.
- Stop. Stops the selected process engine(s). If graceful shutdown options are set for a process engine, the options are applied. Click a process engine name to access graceful shutdown options.
- Kill. Forces an immediate shutdown of each selected process engine. If checkpoints or other graceful shutdown options are defined for a process engine, the options are ignored. Current jobs are terminated before given a chance to complete.
- Group By. Determines how items in the display are grouped.
- Instances List
- Service Instance. Displays the TIBCO ActiveMatrix BusinessWorks engine, adapter instance, JMS Server service, and so on. Click the component name for additional info.
- State. Stopped, Starting Up, Running, or Shutting Down. If the component belongs to an FT group, StandBy is also an option. Shutting down TIBCO Administrator is not recommended. Restarting is an option.
- FT Group. Fault Tolerance group to which component belongs, if any.
- Machine. The computer on which this component is running.
- Software. Name of the installed TIBCO software that runs the application. The highest alert for that software is displayed in the left-most column.
- View Service Instance Dialog.
- General Tab
- General. Displays information about a process engine or service instance
- Uptime for this component.
- Process ID for this component.
- Name of the process.
- Status of the component. If stopped, click start to start it. If running, click Stop to stop it.
- Name of the machine on which this process engine or service instance is running.
- Name of the fault tolerant group, if any, to which this component belongs.
- Statistics. Only displays for process engines.
- Created Processes. Process created by the process engine.
-Suspended Processes. Processes currently suspended.
- Swapped Processes. The total number of times processes were swapped up to current.
- Queued Processes. Processes currently queued.
- Aborted Processes. Processes that were aborted.
- Completed Processes. Processes that were completed.
- Checkpointed Processes. The processes currently checkpointed.
- Total Execution (ms). Total execution time for all processes. This refers to the total time the process was executing but does not include any wait times.
- Average Execution. Average duration for execution of a process.
- Active Alerts. Displays information about the active alerts for this component.
- Date/Time. The date and time at which the alert occurred.
- Alert Level. The alert level set when the alert was created.
- Text. Description defined when creating the alert.
- BW Processes. This tab displays only for process engines. Select Active Processes, Process Starters, Process Definitions, Locks, Recoverable Processes or Blocked Resources.
- Active Processes. Displays active process engines. As a rule, this includes process engines that are suspended or waiting. All other process engines usually complete before TIBCO Administrator is updated by auto-refresh and are therefore not displayed.
- Add Search Condition. One or more search condition can be added to narrow the display.
- Export. Click to export information about the selected process engine to a comma-separated file.
- Kill. Stops the selected process engine.
- Suspend. Suspends the selected process engine.
- Resume. Resumes the selected suspended process engine.
Statistic    Description
Process ID    ID of the running process instance
Status    Status of the process
Tracking ID    Tracking ID for the process instance
Custom ID    Custom ID for the process instance
Start Time    Time when the process instance started
Duration (ms)    Elapsed clock time (in milliseconds) since the process instance started.
Process Defn    Name of the process definition
Current Activity    Name of the currently executing activity in the process instance.
Starter    Name of the process starter that started this process instance.

- Process Starters. Displays all process starters in the process engine. Individual process starters can be selected, enabled or disabled.
- Process Definitions. Use the search field to limit the display. The * character can be used as a wildcard. Click a process engine to display the process definition details.
- Name. Activity for which throughput is displayed
- Called Process. This field only shows information if a running
process engine is called by another process engine.
- Execution Count. Number of jobs in which this activity is currently participating.
- Elapsed time. Average time this activity took to complete.
- CPU time (ms). CPU time used by this activity.
- Errors. Number of errors encountered for this activity.
- Status. Activity status.
- Function. Name of the activity resource.
- Details. Click for more detailed information about this particular activity.
- Locks. Lock object shared configuration resources are used by Critical Section groups to ensure that only one process engine executes the activities within a Critical Section group at a time. The lock name, wait position, process id and requestor display. Lock information can be exported to a comma separated file, or kill a lock, if necessary.
- Recoverable Processes. Recoverable processes are process instances that have been checkpointed but not restarted. The recoverable Processes option allows to manage recoverable processes and either restart or remove them.
- Blocked Resources. A process instance can become blocked when resources that it depends upon are unavailable and TIBCO Enterprise Management Advisor blocks their use. This option allows to resume a blocked process instance once the resource becomes available.
- Tracing tab. Allows to view the trace logs for this application. One or more search conditions can be created to narrow the search scope. To see the default log, leave Where File is .log and click Search. the log may grow quite large, and one or more search conditions can be added before clicking Search. The number of lines displayed is governed by tibcoadmin.monitor.traceLog.MaxLines in tibcoadmin_.tra and defaults to 1000.

- Graceful Shutdown tab.
- Edit. Click to change the parameters under this tab.
- Kill Jobs Timeout. Specifies the maximum timeout in seconds the process engine will wait for jobs to finish before shutting down the engine. A zero (0) value means 0 seconds, which effectively turns the graceful shutdown into an immediate shutdown.
- Wait for Checkpoint. When selected, causes the process engine to wait for all jobs to finish (up to the maximum timeout) before shutting down the engine, rather than removing jobs at their next checkpoint.

- UDDI Servers module allows to browse and publish to UDDI Operator Sites.
- Universal Description, Discovery and Integration (UDDI) refers to the protocol used by web-based registries to publish information about web services.
Business publish information about the web services they offer to public UDDI Operator Sites. This allow other business to locate and access published web services. TIBCO ActiveMatrix BusinessWorks supports both browsing and publishing to UDDI registries that comply with the UDDI Version 2.0 API specification.
- UDDI Servers module allows to define connections to UDDI servers and view the web services contained in the servers. If there is access to publish web services, UDDI Servers module can be used to publish information about business and web services offered.
- Clicking the UDDI Servers module displays the UDDI Servers panel. UDDI Servers must be added to the server list before proceeding with any other operations.
- The UDDI Servers panel allows to add, view or remove UDDI servers from the list of servers.
- Adding UDDI Servers
1. Click the UDDI Servers module, then click the Add button. The Manage UDDI Server panel appears.
2. Enter the following information about the UDDI Server
- Name. Name of the UDDI Server
- Description. Description of the UDDI Server.
- Inquiry URL. URL for browsing the businesses contained in this server.
- Publish URL. URL for publishing business information to this server.
- Username. Name of the user that has publish access to this server.
- Password. Password for the specified user.
- SSL Configuration. Folder containing one or more certificates from trusted certificate authorities. This folder is checked when a client connects to the registry server to ensure that the server is trusted. This prevents connections to rogue servers.
- Proxy Server Settings. Specify these fields when access the registry by way of a proxy server.
- Host. Host name of the proxy server.
- Port. Port number on the proxy server.
- User Name. User name on the proxy server.
- Password. Password on the proxy server.
3. Click the Done button to save the information.
- Once a UDDI server has been added to the server list, the server details can be viewed by clicking the server’s name in the server list. The View UDDI Server Detail panel is displayed. This panel allows to add businesses to the server. If access to publish to this server has been granted. Server’s details can also be edited by clicking the Edit button.
- Business Entities describe the businesses that publish web services to UDDI servers. A business entity contains discovery URLs, contact information and services.
-Viewing or Editing a Business Entity and Services
1. Click the UDDI Servers module, then click the UDDI server name that contains the business in the server list.
2. The View UDDI Server Detail panel appears. The Businesses area lists all businesses contained in the UDDI server. The business list contains a list of business names, descriptions and UUID key values for each business.
3. Click the name of the business to display the View Business Detail panel.
- Name. Name of the business.
- Key. UUID key for the business.
- Description. Description of the business
- Authorized Name. The name of the user that published the business entity.
- Services. A list of web services available from this business.
4. Click the Edit button to display the Manage Business panel and edit any of the business details. Only authorized users can edit business entities. The Manage Business panel also allows to add discovery URLs or contact information for a business.
5. The Services area lists the services available for a business entity. Web services deployed and running TIBCO Administrator applications can be added by clicking the Add button.
- Adding a Business Entity
1. Click the UDDI Servers module, then click the UDDI Server name to which the business entity is going to be added. The View UDDI Server Detail panel appears.
2. Click the Add button to add a business entity to the list. The Manage Business panel appears.
3. Enter the following information about the business
- Name. Name of the business
- Key UUID key for the business.
- Description. Description of the business.
- Authorized Name. The name of the user that published the business entity.
4. Add discrovery URLs to this business entity by clicking the Add button in the Discovery URLs area. A discovery URL provides a link to additional information, either technical or descriptive, about business. Enter the URL and the use for the URL. UDDI Defines two uses for discovery URLs: businessEntity and businessEntityEx
5. Add contact information to this business entity by clicking the Add button in the Contacts area. The Edit Contacts Detail panel appears where a contact name, description, phone, email and address can be added.
6. Click Done to record the changes made.
- Adding Services. Deployed and running TIBCO ActiveMatrix BusinessWorks web services can be added to business entities. This allows to publish the details of the web services to an external audience. Only Service resouces or process definitions that contain a SOAP Event Source process starter can be added to a business entity.
1. Click the UDDI Servers module, then click the UDDI Server name that contains the business entity.
2. Click the business name in the list of businesses for the selected UDDI server.
3. Click the Add button in the Service area to add a TIBCO ActiveMatrix BusinessWorks web service. The Add Service panel appears.
4. Click the Browse button to view a list of deployed and running applications that contain web services. A panel appears that allows to select the desired Service resources or process definitions that contain SOAP Event Source process starters.
5. Click Done once the desired web services have been selected. The web services are added to the Services area.
6. Click each service nae to bring up the View Business Service Detail panel.
7. Add bindings to each web service by clicking the Add button in the Bindings area. The Edit Service Binding Detail panel appears.
8. Enter the appropriate binding information.
- Access Point. The URL where the service can be accessed.
- Binding Key. The UUID binding key for the service
- Service Key. The UUID service key for the service.
9. Click Done to dismiss the Edit Service Binding Detail panel and save the changes.
10. Click Done to dismiss the View Business Service Detail panel and save the changes.

- TIBCO ActiveMatrix BsinessWorks process engines can be configured using custom properties in configuration files.
- The TIBCO ActiveMatrix BusinessWorks process engine is responsible for running instances of process definitions. The default configuration settings are sufficient for most users.
- Custom properties can be defined in engine’s configuration files to configure the process engine.
- Properties are set by specifying their name and value in the configuration files.
- Some properties can be set for specific process definitions or activities and the property name can be variable.
- Properties that have variable portions can use the wildcard character (*) to indicate the property should be set to the specified value for all potential names.
- Property names and values can be separated by either a space ( ), an equal sign (=) or a colon (:). If a property value contains a space, equal sign or colon, those characters mst be scaped in the property value by using a \
- Comments in the configuration file begin with a hash sign (#).
- TIBCO Designer runs a process engine when process definitions are tested sing the Tester tab. To set cstom properties for the process engine that TIBCO Designer runs, a properties file must be created and specify its location.
1. Create a properties file containing the cstom properties to set in the process engine that runs in the testing environment.
2. Add properties to the file.
3. Start TIBCO Designer and open the project to test
4. Click the Start Testing Viewed Process button to start the test engine
5. On the Select Processes to Load dialog, click the Advanced button.
6. In the Test Engine User Args field, enter the -p argment, followed by the location of the properties.cfg file.
- TIBCO Administrator is responsible for deploying process engines in a production environment. TIBCO ActiveMatrix BusinessWorks provides a file for specifying any custom properties to set in deployed engines. The bwengine.xml file is located in the C:\tibco\bw\lib\com\tibco\deployment subdirectory of the TIBCO ActiveMatrix BusinessWorks installation directory.
- The bwengine.xml file has a element that defines all of the properties to have avaliable in deployed process engine.Each property is contained in a property element with the following structure

Name to display in TIBCO Administrator

default value
short description of property

- Once the property is defined in the bwengine.xml file, it is available in Enterprise Archive Files created by TIBCO Designerand will be displayed in the Advanced tab of the deployment configuration in TIBCO Administrator.
- EAR files should be re-saved in TIBCO Designer and re-loaded into any deployment configurations created in TIBCO Administrator after changing the bwengine.xml file.
- The vale of any property can be altered on the Advanced tab of the deployment configuration and that value will be used in the deployed project.
- A Service Container property in bwengine.xml file enables TIBCO BusinessWorks to host multiple process engines in a service container

Service Container


Enable deployed instance to run inside a container

- It allows to deploy multiple project archive files in the same service container. Multiple BusinessWorks engines can be hosted in one Service Container based on deployment configurations and the process hosted by engine.
- TIBCO BusinessWorks provides parameters to enable or disable the Built-in Resouce provider feature. This feature performs tasks similar to that of the Retrieve Resource activity, but eliminates the need to create the Retrieve Resource process. The properties to enable, disable and control the Built-in Resource Provider feature can be set in the bwengine.xml
- Custom Engine Properties.
- Engine Properties
-bw.engine.autoCheckpointRestart. Controls whether checkpointed process instances are automatically restarted when a process engine restarts. Default is true. If set to false, checkpointed process instances can later be recovered using Job Recovery dialog in TIBCO Administrator.
-bw.engine.dupKey.enabled. Controls if duplicate detection is performed. Default is true.
-bw.engine.dupKey.timeout.minutes. Specifies how long (in minutes) to keep stored duplicate keys. 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.enableJobRecovery. Specifies whether checkpoint data for process instances that fail due to unhandled exceptions or manual termination should be saved for later recovery with Job Recovery dialog in TIBCO Administrator. Default is false.
-bw.engine.stats.dir. Specifies the location of the process instance and activity statistic files when statistics storing is enabled. Default location is /stats.
-bw.engine.jobstats.enable. Controls process instance statistic collection. Default is false.
-bw.engine.jobstats.rollover. Specifies the maximum size (in bytes) for process instance statistic files. Once a file reaches the specified size, a statistics are written to a new file. Default is 1024 (1 MB)
-EnableMemorySavingMode or EnableMemorySavingMode.. Memory saving mode can reduce the memory used by actively running process instances as well as potentially improve the performance of checkpoints.By default, memory saving mode is disabled, but garbage collection can be enabled on specific process instances by setting EnableMemorySaving Mode. property to true.
-Engine.dir. Controls the location of the process engine storage when process engine is configured to use local file for storage. Default is /tra/domain//application/.
-Engine.ShutdownOnStartupError. By default, checkpointed process instances are restarted when the engine restarts and if the engine encounters errors during startup, the restarted process instances continue to be processed and may eventually be lost depending upon the type of error at startup. It can be specified that the process engine should shutdown if any event of an error. This property, controls this behavior. Default is false, but setting it to true shuts the engine down if errors are encountered when the engine starts.
-Engine.StandAlone. Under some situations, a unique constraint violation is thrown when using a database as the data manager for process engines. Set this property to false if this situation is encountered.
-Engine.StepCount. Controls the max number of execution steps (unless inside a transaction) for a job before an engine thread switch occurs. Default is 20. Frequent thread switching can cause engine performane degradation, but when a process instance keeps the thread too long, this may cause less concurrency for the executing process instances (and therefore inefficient use of CPU).
-Engine.ThreadCount. Controls the number of threads available for executing process instances concurrently. Default is 8. On a multi-CPU machine, the ThreadCount value can be increased. However many threads can cause resource contention.
- TIBCO Hawk Properties. TIBCO Administrator is the preferred monitoring and management tool for TIBCO ActiveMatrix BusinessWorks. However, process engines have a TIBCO Hawk microagent as well. These properties should be set only on deployed engines. These properties are not intended to be used with process engines started by TIBCO Designer for testing definitions.
-Hawk.Enabled. Controls whether or not TIBCO Hawk can be used to monitor and manage the process engine. Also, allows the Engine Command activity to be used. true, Enables both TIBCO Hawk and Engine Command activity usage. local, Enables only Engine Command activity. TIBCO Hawk cannot be used when this value is used. false, disables both TIBCO Hawk and Engine Command activity usage.
- Hawk.Network. Specifies the network parameter for the TIBCO Rendezvous transport of TIBCO Hawk configuration. Default is “”.
- Hawk.Daemon. Specifies the daemon parameter for the TIBCO Rendezvous transport of TIBCO Hawk configuration. Default is tcp:host:7474
- Instrumentation.. Some of the TIBCO Hawk instrumentation methods require runtime actions that impose performance and memory overhead. These actions can be enabled or disabled on a per-process definition basis at any time by setting this property. The actions that can be enabled or disabled are
-Collection of activity statistics for the GetActivity microagent method.
-Calls the OnProcessActivity and OnProcessStatusChanged microagent methods.
Setting the engine property Instrumentation.* to true enables those actions for all process definitions. Setting the property Instrumentation. to true enables those actions for a specified process definition. Setting this property to false disables the actions.
The instrumentation properties can be set at runtime by calling the TIBCO Hawk setInstrumentProperties method. The property value specified in a call to setInstrumentPropeties takes effect immediately.
- TIBCO Enterprise Management Advisor Property. TIBCO BW works with TIBCO EMA to suspend business processes when external resources become unavailable.
-bw.engine.emaEnabled. Setting this property to true enables communication with TIBCO EMA. A resource dependency list for all process definitions executing in this engine is created and process are suspended when TIBCO EMA communicates the unavailability of any dependent resources.
- Trace Properties. Control which trace messages are sent and where they are sent to. Tracing is controlled wither by roles, by activities, or by process definitions. The Write to Log activity allows to specify a user-defined role for the message to write.
-Specifying Location of Trace Messages. Control where trace messages are sent. Messages can be sent to the log file, to the console, or published as TIBCO Rendezvous messages.
-Trace.Role..Term. Controls whether or not messasges for the specified user-defined role are sent to the console; use Trace.Role.*.Term to control console output for all user-defined roles.
-Trace..Term. Controls whether or not messages for the specified system role (Error, Warn, Info, or Debug) are sent to the console.
-Trace.Role..Log. Controls whether or not messages for the specified user-defined role are sent to the log file; use Trace.Role.*.Log to control log output for all user-defined roles.
-Trace.Role..Publish. Controls whether or not messages for the specified system role (Error, Warn, Info or Debug) are published as a TIBCO Rendezvous message. By default, messages are sent on TIBCO ActiveMatrix BusinessWorks default transport. A different transport can be specified for published trace messages with the following properties
- Trace..Publish.Subject
- Trace..Publish.Service
- Trace..Publish.Network
- Trace..Publish.Daemon
- Specifying Rolling Log Files for UserRole. It can be specified that entries for the role named UserRole are sent to a set of rolling log files. To accomplish this, location of log files, log file name, the number of log files and the maximum size of each log file must be specified. Entries will be written to the first log file until it reaches its maximum size, and so on. Once the maximum number of log files is reached, entries are then redirected back to the first log file again.
- Trace.Role.UserRole.Log.Dir. Location for the set of rolling log files.
- Trace.Role.UserRole.Log.File. Filename for the log files. A number is appended to each log file created up to the specified maximum number of log files.
- Trace.Role.UserRole.Log.MaxSize. Maximum size of a log before entries are directed to the next log file in the sequence.
- Trace.Role.UserRole.Log.Maximum. Maximum number of log files to create. Entries are directed back to the first log file when the maximum number of log files have been created.
- Tracing by Role. Enable or disable all tracing for user-defined and system roles.
-Trace.Role. or Trace..*. Enables or disables the specified user-defined role; specify Trace.Role.* to enable or disable all user-defined roles. Trace..* enables or disables the specified system role (Error, Warn, Info or Debug).
- Tracing by Resource. Enables or disables tracing for activities and process starters.
-Trace.Task.*. Controls whether or not trace messages for all activities are output.
-Trace.Task... Controls whether or not trace messages for a given activity in a process definition are output. Specifying a wildcard for the process definition name indicates to control trace messages for all activities with a given name. pecifying a wildcard for the activity name indicates to control trace messages for all activities in the specified process definition.
-Trace.JC.. Controls whether or not trace messages for a given process starter are output. Specify Trace.JC.* to control trace messages for all process starters.
- Including Activity Input/output in Trace Messages. When resource tracing is enabled, resource input or output XML can optionally be included in the trace messages.
- bw.engine.showInput. When set to true, resources that have input will include the input XML in the trace messages for that resource.
- bw.engine.showOutput. When set to true, resources that have output will include the output XML in the trace messages for that resource.
- TIBCO Rendezvous Advisory Messages. TIBCO Rendezvous advisory messages can be written to the TIBCO ActiveMatrix BusinessWorks log file. There are three types of advisory messages: Error, Warn and Info. Error advisories are logged by default.
-Trace.RV.Advisory.Error
-Trace.RV.Advisory.Warn
-Trace.RV.Advisory.Info
Prefix the above properties by “java.property.” to enable the associated advisory messages.
- XPath and XML Properties. Control behavior of XPath and XML in TIBCO ActiveMatrix BusinessWorks. Prefix these property names by “java.property.” while setting the properties in the configuration files.
-com.tibco.xml.xpath.create-dateTime.has.timezone. Determines whether a time zone us added by XPAth function create-dateTime. TIBCO strongly advises against modifying this property unless TIBCO Support advises it.
-com.tibco.xml.xpath.variable-declaration-required. Controls whether variable references are checked. Default is false.
-com.tibco.xml.schema.preserve-boolean-lexical-value. Specifies whether the lexical value of xs:boolean is preserved. Default is false. TIBCO strongly advises against modifying this property unless TIBCO Support advises it.
- Security Properties. Control the behavior of Secure Sockets Layer (SSL) and other security settings. Some protocols such can use SSL to ensure secure communication.
-bw.plugin.security.stringcipher.minstrength. Specifies the cipher suites to exclude when the String Cipher Suites Only checkbox is checked in an SSL configuration. This property also allows to choose the types of cipher suites to disable. Equivalent key strength is taken into account. Default value is DISABLED_CIPHERS_BELOW_128_BIT. This property is also only available for resources that have the String Cipher Suites only field checked.
-Valid values for this property.
-DISABLED_CIPHERS_EXPORTABLE. Cipher suites that are suitable for export out of the Unisted States are disabled. This list of exportable cipher suites is controlled by the US government. This usually refers to asymmetric algorithms (such as RSA) with a key of modulus lower than 512 bits or symmetric algorithms (such as DES) or key length 40 or lower. Typically exportable cipher suites contain _EXPORT_ in the suite name, but this is not always the case.
-DISABLED_CIPHERS_BELOW_128_BITS. Cipher suites whose key length (or equivalent) is below 128 bits are disabled.
- DISABLED_CIPHERS_128BIT_AND_BELOW. Cipher suites whose key length (or equivalent) is 128 bits or less are disabled.
- DISABLED_CIPHERS_BELOW_256BIT. Cipher suites whose key length (or equivalent) is below 256 bits are disabled.
By default, the jurisdiction policy files shipped with TIBCO ActiveMatrix BusinessWorks are not unlimited strength. When lower strength cipher suites is disabled, an error suggesting to upgrade policy files may be received. To download unlimited Strngth policy files
1. Download the required files
2. Unzip jce_policy-1_5_0.zip
3. Copy US_export_policy.jar and local_policy.jar to TIBCO_HOME\jre\1.5.0\lib\security
- General Activities Properties. Control behavior of activities in the General Activities palette.
-Engine.WaitNotify.SweepInterval. Notify timeouts cause the notify information to be marked for removal, but the information is removed at regular intervals. The default interval for checking Notify timeouts is 60 seconds.
-log.file.encoding. Specifies the character encoding to use when writing to the log file. Any valid Java character encoding name can be used.Default encoding is the one from JVM.
-WaitNotify.Service. When Wait and Notify activities are used across multiple engines, TIBCO Rendezvous is used for communication between the engines. This property specifies the service parameter for the TIBCO Rendezvous transport.
-WaitNotify.Network. When Wait and Notify activities are used across multiple engines, TIBCO Rendezvous is used for communication between engines. This property specifies the network parameter for the TIBCO Rendezvous transport.
- WaitNotify.Daemon. When Wait and Notify activities are used across multiple engines, TIBCO Rendezvous is used for communication between engines. This property specifies the daemon parameter for the TIBCO Rendezvous transport.
- HTTP Properties. In some situations, it may be needed to alter the configuration of the HTTP Server that receives incoming HTTP requests for TIBCO ActiveMatrix BusinessWorks.
-bw.plugin.http.protocol.single-cookie-header. Allows to send multiple cookies in a single, non-repeating Cookie header element for outgoing HTTP requests in the Send HTTP Request activity.
-bw.plugin.http.server.allowIPAddresses. Allows to specify a comma-separated list of regular expression patterns that is compared with the remote clien’s IP address before accepting or rejecting requests from the client. The remote IP address of the client must match for the request to be accepted.
-bw.plugin.http.server.restrictIPAdresses. Allows to specify a comma-separated list of regular expression patterns that is compared with the remote client’s IP address before accepting or rejecting requests from the client. The remote address of the client must not match for any request from this client to be accepted.
-bw.plugin.httpserver.acceptCount. This property specifies the maximum queue size for incoming requests. Incoming requests that are not handled by available threads (see bw.plugin.http.server.minProcessors and bw.plugin.http.server.maxProcessors) are placed on the queue until they can be processed. If the queue is full, new incoming requests are refused with an error. Default value of this property is 100. This property is only available when the server type ‘Tomcat’ is selected.
-bw.plugin.http.server.serverType. Specifies the server type that is to be used for the HTTP Connection resource. Two server types are available: Tomcat and HTTP Component. The default value of this property is Tomcat.
-bw.plugin.http.server.httpcomponents.workerThread. Specifies the maximum number of web server threads available to handle HTTP requests for the HTTPComponents server type. Default is 50.
-bw.plugin.http.server.minProcessors. Specifies the minimum number of threads available for incoming HTTP Requests. The HTTP server creates the number of threads specified by this parameter when it starts up. Default is 10. If Flow Limit deployment property is set, the value of this property is set to /2.
-bw.plugin.http.server.maxProcessors. Specifies the maximum number of threads available for incoming HTTP requests. The HTTP server will not create more than the number of threads specified by this parameter. Default is 75. If the Flow Limit deployment property is set, the value of this property is set to - 1.
-bw.plugin.http.server.maxSpareProcessors. Specifies the maximum number of unused request processing threads that can exist until the thread pool starts stopping the unnecessary threads. Default is 50.
-bw.plugin.http.client.ParseEntireMultipartMessage. Enables the HTTP client to parse the entire multi-part message. For BusinessWorks 5.2, an HTTP response message is received by the HTTP client, is parsed on the content-type header. When the message is a multi-part message, the attachments are put in the attachment list. In BusinessWorks 5.2., the message body that is exposed to the user should contain the entire message body, including the attachments. However, parsing a multi-part message is not a problem in BusinessWorks 5.3 and later versions as MIME attachments are handled differently.
-bw.plugin.http.client.ResponseThreadPool.By default, each Request/Response activity that uses the HTTP protocol is associated with a unique thread pool. Each request is executed in a separate thread, belonging to the thread pool associated with the activity. The size or each thread pool is 10 by default, therefore, only 10 requests can execute concurrently. Setting this property to a value specifies the size of the thread pool to use for request/response activities. This thread pool can be for each activity, or all activities can share the same thread pool. The thread pool is created when the engine starts, therefore be careful to set the value of this property to a reasonable number for the system. If the valus is set too highm it may result in extra resources allocated that are never used.
-bw.plugin.http.client.ResponseThreadPool.type. This property determines the type of thread pool to use for request/response activities,Either one thread pool per activityis created, or one common thread pool is created to be shared across all activities. Specify default as the value of this property if a thread pool for each activity needs to be created. Specify single as the value of this property if a single common thread pool for all activities is needed.
-bw.plugin.http.client.usePersistentConnectionManager. Specifies that a pool of HTTP connections to each HTTP Server should be created so that connections can be reused by Send HTTP Request activities. Not all HTTP Servers support persistent connections.
When this property is set to true, a pool of connections is created for each HTTP server that Send HTTP Request activities connect to. The total number of connections in the pool is limited by the bw.plugin.http.client.maxTotalConnections property. The number of connections for each host is limited by bw.plugin.htt.client.maxConnectionsPerHost property. The default value of this property is false.
-bw.plugin.http.client.maxConnectionsPerHost. The value of this property is ignored unless the bw.plugin.http.client.userPersistentConnectionManager property is set to true. This property specifies the maximum number of persistent connections to each remote HTTP server. Default value for this property is 20.
-bw.plugin.http.client.maxTotalConnections. The value of this property is ignored unless the bw.plugin.http.client.userPersistentConnectionManager property is set to true. This property specifies the maximum number of persistent connections to create for all HTTP servers. Default is 200.
-bw.plugin.http.client.checkForStaleConnections. The value of this property is ignored unless the bw.plugin.http.client.userPersistentConnectionManager property is set to true. When using persistent connections, a connection can become stale. When this property is set to true, a persistent connection is checked to determine if it is stale before it is used by a Send HTTP Request activity. Checking for stale connections adds significant processing overhead, but it does improve reliability. Default is false.
-bw.plugin.http.handleAllimePartsAsAttachment. In previous releases, when the content-type of an incoming message was “multipart/*”, the first part of the message was presented as the POSTDATA. This is incorrect according to the MIME specification. This property fixes this problem. If this property is set to true and the top-level content-type of the incoming HTTP message is “multipart/*”, then an HTTP Receiver will present all the MIME parts as attachments and the POSTDATA field will be empty. If this property is set to false (default value), backward compatibility is maintained and the first MIME part is presented as the POSTDATA. Do not check the Parse Post Method Data field on the HTTP Receiver process starter when this property is set to true. This causes an error to be thrown.
-bw.plugin.http.server.debug. When set to true, specifies that the contents of incoming HTTP request are written to the log file. Writing each request to a log file does incur some overhead and additional processing time.
-bw.plugin.http.server.defaultHost. Specifies the name of the default host to use when the machine has multiple domains or IP addresses. The value of this parameter can be either a host name or IP address.
-bw.plugin.https.server.deferClientAuthentication. Defers client authentication and outputs the client’s security context when the client connects to the server using HTTPS.
-JDBC Properties. Custom properties for resources in the JDBC palette.
-Engine.Database.TestStatement.. When a SQL error occurs during statement execution, TIBCO ActiveMatrix BusinessWorks executes a test SQL statement to determine if the error is caused by a bad connection. If the error is due to a bad connection, the statement can be re-executed using a different connection in the connection pool. This property allows to specify a test SQL statement. Specify the database name in the portion of the property and set the value of the property to avalid SQL statement.
-Engine.DBConnection.idleTimeout. Normally, connections in the database connection pool close after a period of time when they are idle. This property specifies the time (in minutes) to allow database connections to remain idle before closing them. Default is 5 minutes.
-Config.JDBC.Connection.SetLoginTimeout. Time (in seconds) to wait for a successful database connection. Only JDBC drivers that support connection timeouts can use this property. If the JDBC driver does not support connection timeouts, the value of this field is ignored. Most JDBC drivers should support connection timeouts. The value of this property overrides any value set for connection timeouts in the Configuration tab of the JDBC Connection resource.
- JMS Properties. Custom properties for resources in the JMS palette.
-bw.plugin.jms.receiverTimeout. Specifies the polling interval for JMS activities that receive messages. Specify an integer as the value of the property to determine the number of seconds to set the default polling interval for all JMS activities that receive messages. Individual activities can overridethis default polling interval by specifying a value in the Receiver Timeout field on the Advanced tab of the activity.
-bw.plugin.jms.recoverOnStartupError. When a process engine attempts to startup and the JMS server that JMS activities connect to is not up, the JMS process starters cannot connect to the JMS server.Setting this property to true allows the process engine to start and the JMS process starters will wait until the JMS server is up before starting.
- Mail Properties. Custom engine properties for resources in Mail palette.
-bw.plugin.mail.receiverFlattenNesteedAttachments. In previous releases, the Receive Mail activity threw exceptions when receiving email, if the email was in rich text format and the any mime part contained nested mime sub-parts. Setting this property to true fixes this problem. It creates a flat output structure where all sub-parts are siblings. Setting this property to false will keep the behavior of previous releases.
-bw.plugin.mail.receiverHandleDiscreteTypes. In previous releases, the Receive Mail activity did not handle incoming mime messages with mime types application/*, audio/*, video/* or image/*. While fetching these types of emails, TIBCO ActiveMatrix BusinessWorks threw exceptions. This can be fixed by setting this property to true . false value keeps the behavior of previous releases.
-bw.plugin.mail.receiverRetryCount. When a mail sender is in the process of sending a message, the mail server may expose the message to the Receive Mail process starter, but indicate later that the message is unavailable. This typically occurs when sending large messages. The Receive Mail process starter attempts to receive the message during subsequent polls of the mail server. By default, the process starter will attempt to receive the message for three minutes. The number of retries within that three minute limit depends upon the value of the polling interval. This property allows to specify the number of times the Receive Mail process starter will attempt to receive the same message. The amount of time allotted for retries will be the value of this property multiplied by the polling interval.
- Rendezvous Properties. Custom engine properties for activities that can use TIBCO Rendezvous transports. This includes activities in the Rendezvous palette and the ActiveEnterprise Adapter palette.
-Config.Tibrv.cmQueueTransport.TaskBacklogLimitInBytes. When the RVCMQ transport is used, TIBCO ActiveMatrix BusinessWorks applies the value of this property to the RVCMQ transport using the RVCMQ API setTaskBacklogLimitInBytes() method to set the scheduler task queue limits in bytes for the distributed queue transport. Value should be a positive integer. When RVCMQ is the transport, this property calls the setTaskBacklogLimitInMessages() method to set the backlog limit of the task scheduler in bytes for the transport.
-Transaction Properties. Custom engine properties for resources in Transaction palette.
-bw.plugin.transaction.xa.arjuna.objectStoreDir. By default, when executing the Arjuna Transaction Service within the same JVM as TIBCO ActiveMatrix BusinessWorks, the Arjuna property file is used to determine the location of the object store directory. If overriding the value in Arjuna property file is needed, set this property to a valid directory name.
-bw.plugin.transaction.xa.isolation. By default in an XA transaction, the transaction isolation level is set to the default value for the JDBC driver used. In order to ensure a particular transaction isolation level, set this property to one of the following values
Value
Transaction Isolation Level Description
1
java.sql.Connection.TRANSATION_READ_UNCOMMITED
2
java.sql.Connection.TRANSATION_READ_COMMITED
3
java.sql.Connection.TRANSACTION_REPEATABLE_READ
4
java.sql.Connection.TRANSACTION_SERIALIZABLE

-bw.plugin.transaction.xa.lock.connection. By default, JDBC activities in XA transaction groups obtain database connections from a connection pool and release the connections from a connection pool when the activity completes. This can cause a database connection to be used concurrently in multiple transactions. Some databases or JDBC drivers support this behavior and others do not. If a JDBC driver that requires database connections to be used in only one transaction at a time, set this property to true. When the value of this property is true, once a connection is associated with a transaction, the connection remains associated with the transaction until the transaction completes. Default is false.
- TCP Properties. Custom engine properties for resources in TCP palette.
-bw.plugin.tcp.server.acceptCount. Specifies the maximum number of incoming requests that can be handled by the TCP server. Default is 50.
- Properties for Backwards Compatibility. Allow to revert to the behavior of previous releases of TIBCO ActiveMatrix BusinessWorks
-bw.plugin.ftp.stripLineFeedInput. Prior to release 5.2.0, the FTP Put activity stripped the \n when \r\n was used for a new line in a file. This caused files to be unusable when a file was taken from a MS Windows machine and put onto a VMS machine. The FTP Put activity no longer strips the \n, and if this behavior in existing projects is correct, this property can be set to true to obtain the behavior of previous releases.
-bw.plugin.http.client.urlEncodeQueryString. As of release 5.2.0, the QueryString input element of the Send HTTP Request activity is not automatically URL encoded. Prior to release 5.2 the activity used URL encoding for the Query specified in the QueryString element. It is now the user’s responsibility to properly URL-encode the query specified in the QueryString. Therefore, the activity does attempt to encode the value supplied in this element. This change may cause backward compatibility issues. Default is false but setting it to true reverts to the behavior of previous releases.
-bw.plugin.javaCode.explicitNull. To indicate a null reference, the Java Code activity omits the value in its output. This causes a String value used as a null placeholder when another activity attempts to read the null in its input. However, other activities did not behave in this way. Other activities pass an explicit null for null references. To preserv backward compatibility, the Java Code activity still behaves the same, but setting this property to true, causes the Java Code activity behave the same way as other activities. An explicit null is set for a null reference. Default is false.
-bw.plugin.parseData.enforceLineLength. In previous releases, the line length specified in the Data Format resource was not enforced. This allowed files with one large line to be parsed in some situations. In more recent releases, the line length is enforced so that files containing one large line are not longer allowed. Behavior of previous releases is achieved by setting this property to false. Default is true.
-bw.plugin.timer.useJavaMonth. In previous releases, the Timer process starter used the Java convention (0-11) for month numbers in its output, however, the expected convention for month numbers is 1-12. In release 5.2.0, the month is returned as a number between 1 and 12. Previous releases behavior is achieved by setting this property to true.
-com.tibco.plugin.soap.no_xsi_type. SOAP activities were enhanced in release 2.0.5 to emit xsi:type attributes. To maintain backwards compatibility, set this property to true.
-com.tibco.xml.xpath.create-dateTime.has.timezone. In release 2.x, the XPath function create-dateTime() returned a value that included a time zone. In Release 5.1.2 and 5.1.3, the function was changed to omit the time zone. This property controls whether the time zone is included in the output of the create-dateTime() function. Setting this property to false (the default value) omits the time zone from the function output (same behavior as 5.1.x). Setting this property to true causes the time zone to be included in the function output (same behavior as 2.x).
-Config.JDBC.CallProcedure.InputOptional. In releases prior to 5.2.0, the JDBC Call Procedure activity created input elements that were optional for stored procedure parameters. Optional parameters have never been supported by this activity. When migrating a project from a previous release, there will be validation errors for any unspecified input elements for stored procedure parameters. These migrated projects cannot be executed until the errors are resolved.. Migrating a project without fixing this problem is achieved by setting this property to true.
-Config.JDBC.CallProcedure.OutputUseNil. Prior to release 5.1.2, if a value returned from a database table was null, the output element corresponding to that table value was not placed into the output schema for a JDBC Call Procedure activity, if the output element was optional. The element is now placed into the output schema and has “xsi:nil = true” to indicate the element is null. Elements that can be nil should be surrounded with an if statement to determine whether to output the element. To maintain the behavior of previous releases, this property controls whether elements that are nil are contained in the output. Set the property to false to achieve the behavior of previous releases.
-ignore.delimiters.under.quotes. Prior to release 2.0.4, when using the activities in the Parse palette, delimiter-separated data was not treated in a standard way. There was not mechanism to escape the specified delimiter character. Also, there was no way to have a field contain a comma as in include leading and trailing spaces. Now fields can be surrounded in double quotes. To disable this functionality, set the value of this property to true.
-java.property.DiscardUTF8BOM. When a file is saved on a Windows platform using UTF-8 encoding, Windows adds a Byte Order Mark (BOM) to the beginning of the file. This BOM is not necessary for UTF-8, but it is valid. Prior to release 2.0.6, the File Reader activity’s output includes the BOM at the beginning of the data read from the file. The BOM is now stripped when it is encountered. To retain the functionalty of previous releases, this property can be set to false.
-java.property.com.tibco.schema.ae.makeNillable. Certain TIBCO ActiveEnterprise-based schema elements do not display as nillable in the Input mapping tab. This can result in mappings (optional to optional) that do not copy the xsi:nil attributes at runtime to the output elements, and subsequently validation errors. Setting this property to true causes mappings that meet the criteria to show warnings. Selecting the input mapping with an error and clicking the Mapper Check and repair button will display yellow warnings: “The input and this element are both nillable, set to copy-nil”. Clicking OK changes the mappings to add the copy-of for the nil attribute (“Optional and nillable to optional and nillable”). This is generally a better way to map this structure and ensures if the element in the source data has the xsi:nil attribute, it will be copied to the target element. In Release 5.2.1 and subsequent releases, the default setting for this property is true, which may cause new warnings to appear in existing projects. Typically, the Mapper Check and repair button can be used to update the mappings to copy xsi:nil attributes. If this is preferable to have empty elements emitted in this case, then the property can be set to false. A new mapping done by drag-and-drop with the property set to true will have the “Optional and nillable” style mapping instead of the “optional to optional” style.

-BusinessWorks service container is a JVM (Java Virtual Machine) that can host multiple process engine instances. The number of applications that can run in each container depends on the deployment configuration and the process running on each process engine.
-Each service container is identified by a unique name within the deployed domain. The name is generally a comnbination of local machine name, port number and other identifications.
-To run a process engine in a service ontainer, the container must be manually started from the command line and then an application should be deployed in the same container. Using this unique name, a particular instance of a process engine can be started without affecting all the other processes running in the same service container.
-Once a service container is enabled, multiple EAR files can be uploaded in the same container. Therefore, one service container can have multiple processes running on separate process engines that are isolated from each other. Each process engine can host a single EAR file that represents one or more BusinessWorks processes or services.
-As all the processes running in a service container are isolated and independent of each other, when there is a need to include additional new service in the same project, another EAR can be deployed in the same container without bringing down all the running services.
-Similarly, if an existing process already running in a service container needs to be upgraded, the corresponing instance of the proess engine can be stopped, the process upgraded, the EAR file rebuilt and redeployed in the same service container and start the process engine again.
- Guidelines to create new services into running BusinessWorks engines
-In general, the design of a process in TIBCO BusinessWorks is completely independent of the TIBCO BusinessWorks service container.
-The unit of deployment or upgrade is an EAR file, so to upgrade an application, an new EAR file needs to be deployed.
-Consider the contents of an EAR file carefully while building it, because the EAR decides the granularity at which the processes can lifecycle at runtime.
-Typically, one EAR file is built for each application. One EAR file represents a shared archive, one or more process archives, and global variables. However, if the application is very big and complex many EAR files can be built. While building multiple EAR files for a single project, make sure that only the relevant processes are combined in one EAR file. Also, try to combine the process that have similar lifecycle in a single EAR file.
-Basically, a project can be packaged in multiple EAR files based only on the natural units of deployment that need to be lifecycled independetly.
-Decide the deployment configuration based on the memory utilization of each archive file.
-BusinessWorks process can only invoke another BusinessWorks process that is in the same EAR, the BusinessWorks process can only communicate with inter-engine features like sending a message or multi-engine wait or notify activity.
-The processes connected with each other via dynamic or static call process activity should be grouped into the same EAR file. This is because call process communication occurs in memory and therefore both, the caller and the called process need to be running in the same engine instance.
-Multiple applications (EARs) can be deployed in a single service container.
-If a project is very complex and it contains several processes that consume a lot of memory, multiple service engines can be deployed in multiple service containers.
-A Service Container property in the bwengine.xml file enables TIBCO BusinessWorks to host multiple process engines in a service container.

Service Container


Enable deployed instance to run inside a container

It allows to deploy multiple project archive files in the same service container. In one service container, multiple BusinessWorks engines can be hosted based on deployment configurations and the processes hosted by engine.
-After enabling the service container, the following operations can be performed.
-Start a service container.
bwcontainer --deploy
-List all the service containers
bwcontainer --list
-Stop a service container.
bwcontainer --undeploy
- If an application is packaged into multiple EAR files, they can be deployed in separate process engines in a single or multiple service containers using the following methods.
1. Start the service container. Service container must be running before deploying applications to it.
\bin\bwcontainer --deploy
2. Open TIBCO Designer and create the EAR files for the application.
3. Start TIBCO Administrator and log into a domain.
4. Select Application Management > New Folder to create a folder to hold all the related applications together.
5. In the newly created folder, select New Application and upload the EAR file. Application names should be unique in the domain in order to identify all the processes and service running in the same domain. It also helps to monitor and manage all the applications from the Application Management > All Service Instances dialog. By default, the application name derives from the name of the uploaded EAR file. If an EAR file has already been uploaded, modify the Application Parameters from the Configuration dialog of the application to change the application name.
6. Once the EAR file is uploaded, go to the Application console and select the Configuration dialog.
7. Select the Process Archive.par entry in the Configuration dialog.
8. Go to the Advanced tab.
9. For the bw.container.service property, enter the service container name as a value. Correct name must be entered as TIBCO Administrator does not validate this property.
10. Click the Deploy button to deploy the application. The bwcontainer properties in TIBCO Administrator cannot be specified if an EAR file, generated with TIBCO BusinessWorks 5.4.x or earlier versions, is deployed. To enable the bwcontainer properties in TIBCO Administrator, recreate the EAR file with TIBCO ActiveMatrix BusinessWorks 5.6.0 and deploy in TIBCO Administrator.
- Configure Logging using log4j.
1. Go to Configuration > Advanced tab for the application to be deployed.
2. For the variable bw.log4j.configuration, specify the location of the log4j configuration file, log4j.properties.
3. Configure other deployment properties for the application as needed. Click the Deploy button to deploy the application.
- If the log4j configuration file is in XML configuration format, then specify the file name with the .xml file extension in TIBCO Administrator.
- Starting and Stopping applications in a Service Container
1. Go to Application Management > All Service Instances.
2. Locate the processes to manage by checking the application name in the Application column.
3. Check the appropriate process
4. Click Start, or Stop button from the top bar.
- Do not click the Restart or Kill button as it will bring down the service container and all the running applications inside the container.
- After the service container is started from the command tool and deploy applications in it, all the messages related to these applications are logged in the same command prompt. All the messages in this window can be checked to know the current status of the process engines running in the service container. Even if the application is started from command line or TIBCO Administrator, the corresponding messages are displayed in the command tool from where the service container is invoked. Messages are also logged in the \container\logs\.log file.
- Undeploying Applications in a Service Container. TIBCO Administrator allows to selectively undeploy applications from the service container. However, all the applications can simultaneously be deployed in a service container using the command line.
TIBCO Administrator
1. Open Application Management > All Applications dialog
2. Check a single or multiple applications to undeploy
3. Click the Undeploy button on the top bar.
Command Line
1. Open a command prompt window and go to the folder \bw\\bin
2. Enter the following comand to undeploy a service container and all applications within the same container
bwcontainer --undeploy
The system first undeploys all the applications hosted inside a service container and then undeploys the service container.
- Upgrading an Application in a Service Container.
1. Open TIBCO Administrator and log into a domain.
2. Select Application Management > All Service Instances.
3. Locate the process to be upgraded by checking the application name in the Application column.
4. Click Stop from the top bar.
5. Go to Application Management > All Applications
6. Check the appropriate application from the list.
7. Click Undeploy button from the top bar.
8. In TIBCO Designer, open the corresponding project to upgrade the process as per the need. Build a new EAR file that contains the modified process archive file.
9. In TIBCO administrator, go to Application Management and upload the new EAR file.
10. Deploy the new application in the same Service container.
- Adding a new application in a service container
1. Open TIBCO Administrator and login to a domain.
2. Go to Application Management > All Applications
3. Select the folder in which all the other related applications in the same project are deployed.
4. Configure the application to deploy in the same service container by specifying the appropriate container for the bw.container.service property.
5. Verify that the new application is running properly by checking the process engine status in Application Management > All Service Instances.
- Understanding limitations.
- If a project is complex and multiple Enterprise Archive are going to be created for a single Designer project and if each archive includes multiple processes, make sure that all processes using HTTP process starters are grouped into the same EAR file.
- If a project uses JMS-MQ for message transport and the plan is running it through TIBCO Administrator, add the fscontext.jar and other MQ jar files from to the CLASSPATH in one of the following ways.
- Add the jar files from to /jre/1.5.0/lib/ext
- Edit the property tibco.env.CUSTOM_EXT_APPEND_CP in /BW//bin/bwcontainer.tra to include the path for the jar files tibco.env.CUSTOM_EXT_APPEND=%TCPL_HOME%/tomcat/5.5/compatible/lib/%PSP%/java/util.
- Whenever a service container goes down, all the deployed appliations in the container also stop. However, when the container restarts, these deployed applications do not restart automatically, All the deployed applicationsmust be manually restarted from TIBCO Administrator.

3 comentarios: