TIBCO BusinessWorks Administration Notes (1-3)
- A TIBCO ActiveMatrix BusinessWorks has the following lifecycle:
- Design. Creating and testing the project using TIBCO Designer.
- Deploy. Use TIBCO Designer to create an EAR file containing the required resources for running the project. Then, TIBCO Administrator is used to deploy the project to the machine(s) where it will run.
- Run. TIBCO ActiveMatrix BusinessWorks process engine executes the process instances of the deployed project and TIBCO Administrator can be used to monitor and manage the process engine.
- TIBCO Administrator is a central administration server for TIBCO products. Applications are created, deployed and managed in TIBCO Administrator using a web-browser-based interface.
- Launching TIBCO Administrator in Microsoft Windows.
Two Microsoft Windows Services must be running for the server to be available. After creating an administration domain, t services are installed and set to start automatically. To Start the services the first time, navigate to the Services dialog, find the TIBCO administration server for the domain and click the Start button. Repeat for the TIBCO Hawk Agent Service.
If the TIBCO Hawk Agent is started as a service, mapped drives on the machine are not recognized by deployed services. The workaround is to start the TIBCO Hawk Agent from the command line.
To start on the command line.
1. Start the administration server
% cd
% tibcoadmin_
2. Start TIBCO Hawk Agent which performs the TIBCO Administrator monitoring functions
% cd
% hawkagent_
- Launching TIBCO Administrator on UNIX
1. Start the TIBCO Administration Server
% cd
% tibcoadmin_
2. Start TIBCO Hawk Agent which performs the TIBCO Administrator monitoring functions
% cd
% hawkagent_
- Launching TIBCO Administrator GUI.
- Manually (UNIX and Windows)
1.Enter the URL in a web browser
http://
-host-name is the name of the machine where administration server has been installed.
-port is 8080 by default although it can be changed using TIBCO Domain Utility. If multiple domains were created on the machine, the port is incremented by 10 for each domain.
This shows a list of domains and port that each domain is using.
2. Log in. For the first login, this must be the user specified as domain administrator user with Domain Utility. That user can then assign other privileges to log in.
- From Start Menu (Windows)
1. Select Start > All Programs > TIBCO > TIBCO Administrator
2. Log in. For the first login, this must be the user specified as domain administrator user with Domain Utility. That user can then assign other privileges to log in.
- Stopping the Administration Server. There are several ways to do it
- On all platforms, from TIBCO Administrator, choose Application Management > All Services Instances. Select
- If administration server is started from command-line, Control-C can stop the server.
- On Windows, navigate to Services panel. Select administrator server service and then click Stop button.
- On UNIX, use the appropriate kill command for the system to stop administrator server.
- TIBCO Administrator is the preferred monitoring and management application for TIBCO ActiveMatrix BusinessWorks. However, the process engine is instrumented with a TIBCO Hawk microagent that can be used to perform most administrative functions.
- TIBCO Enterprise Manager Advisor (EMA) extends TIBCO Administrator and allows to automate the management of resources in an enterprise. It also allows managed resources to automatically communicate their availability with each other and react accordingly.
- TIBCO ActiveMatrix BusinessWorks can receive notifications from TIBCO EMA about the status of resources. When a resource becomes unavailable, TIBCO ActiveMatrix BusinessWorks suspends execution of processes that rely on the resource until the resource is once again available.
- Using TIBCO EMA to manage resource dependencies with TIBCO ActiveMatrix BusinessWorks can help to minimize error handling in process definitions as it handles resource availability.
- TIBCO ActiveMatrix BusinessWorks automatically builds a list of resources that a process definition depends upon and communicates the list to TIBCO EMA. Communication between TIBCO EMA and BW relies on TIBCO Hawk microagent methods.
- To enable TIBCO EMA Integration with TIBCO ActiveMatrix BusinessWorks, both TIBCO Hawk and TIBCO EMA must be enabled with custom engine properties. The properties bw.engine.emaEnabled and Hawk.enabled must both be set to true.
- TIBCO Administrator can be used to resume processes that have been suspended due to blocked resources.
- When project is ready to deploy, an EAR file must be generated which contains the configuration for the process definitions to deploy as well as shared resources required by the process definitions.
- Whenever changes are performed in code, EAR file must be rebuilt and redeployed. Saving the project, does not affect the EAR file. Multiple Enterprise Archive resources can be defined for a project containing selected processes.
- The EAR file size may become an issue when it is built in TIBCO Designer, loaded into TIBCO Administrator and deployed to remote machines. An EAR file should only include resources that are required to deploy the project. Large archive files can have a negative effect at deployment. If each application in the project uses different resources, different AliasLibrary resources should be used by each application (rather than one large AliasLibrary)
- Machine on which EAR file is loaded and deployed must have sufficient disk space.
- A warning reminding that ‘all files and directories included in a folder are included in the EAR file’ is displayed when a directory or an AliasLibrary that references a directory are added to the EAR file. EAR file size is typically one fifth of the warning, due to compression.
- The following property can be modified in designer.tra so the warning appears only when files of the given size are loaded.
designer.ear.watermark.size=16
The value is in megabytes. If the warning appears, the heap size value in designer.tra so Designer has enough memory to manage the project.
- Creating an Enterprise Archive
1. In TIBCO Designer, select a folder and find Enterprise Archive resource (General palette).
2. Drag an Enterprise Archive into the design panel.
3. Provide the following information.
- Name.
- Description.
- Author
- Archive Version. User assigns this number. TIBCO Designer does not use this number
- File Location. Location where this archive will be saved.
- Include all service level global variables. Includes all global variables for which Service checkbox is clicked. This checkbox is provided for some adapters that do no properly report all their properties. TIBCO Designer cannot tell if that adapter is using a service global variable or not. This checkbox explicitly forces inclusion of all service-level variables.
4. Create one or more Process Archives and add them to the Enterprise Archive.
5. Build the archive by clicking the Build Archive button. When the button is clicked, TIBCO Designer creates an EAR file that can then be deployed from TIBCO Administrator.
- Creating a Process Archive (contains all process definition that are part of an application).
1. Create and configure one or more process definitions that have process starters.
2. Select the Enterprise Archive resource in the project panel. If there are any processes that have process starters in the project, a Process Archive resource becomes available in the palette panel (Process palette).
3. Drag the Process Archive into the design panel
4. Specify information in the Configuration tab.
-Name.
- Description.
- Author.
5. Click the Processes tab to specify the process definitions to include.
a. Click the browse button (binoculars)
b. Select the process definitions to add to the archive. Any process definitions called by the selected process (unless dynamically called) are automatically included in the archive. Explicitly add any dynamically called subprocesses.
c. Repeat the procedure to add multiple processes. Multiple process definition can be selected by using shift-click or control-click.
6. Click Apply.
7. Select the Enterprise Archive and click the Build Archive button in order to build the EAR file.
- When creating an Enterprise Archive, a Shared Archive is automatically included in the archive and becomes visible when Enterprise Archive is selected. By default, TIBCO Designer adds any resources that are referenced by process definitions for which activities were created.
- All JDBC Connections are included in the Shared Archive automatically when the EAR includes a process archive.
- Changing a Shared Archive
1. Select the Shared Archive and provide a name and description if desired
2. Click the Shared Items tab
- Click the Browse button next to the include from Local Project field to include items from the currently loaded project (this should not usually be necessary)
- Click the Browse button next to the Incluide from Filesystem field to include other items.
3. Click Apply.
4. To build the archive, select the Enterprise Archive and click the Build Archive button.
- If Deploy on Save is selected when creating a New Application, TIBCO Administrator uses the parameters specified in the project file and the default machine that registered the software in TIBCO Administrator. Deploy on Save is not recommended when deploying to another machine and changing parameters of the application.
- When Configuration is clicked, Configuration Builder (customize application) and Deployed Configuration (shows deployed applications) panels are shown
- Monitoring an application can be done in two different ways,
- Viewing Default Monitoring Information
- Specify a Custom Alert. Alerted if certain conditions are met.
- In Configuration Builder, select Process Archive (.par)
- Click Monitoring tab, in Events tab click Add
- Select Event Type, check Generate Alert and select vale for ‘Generate Alerts for’ and Level and type Message.
- Click OK and Save
- Redeploy
- The TIBCO Administrator Application Management module allows to create and deploy applications using the corresponding archive files. It is only available if TIBCO Administrator Enterprise Edition is purchased and user resource management option is enabled.
- TIBCO Administrator Application Management module contains the applications imported into TIBCO Administrator. All applications can be viewed in the All Applications dialog or all process engines in the All Services dialog. Alternatively, process engines for an application can be configured and managed under the application’s dialog.
- Creating an Application.
1. Select either ApplicationManagement, a previously created folder or All Applications.
2. Click New Application
3. Click Browse and select an enterprise archive file, and then click OK.
4. Click Save
Once an application is created, deployment configuration information is specified, such as which machines should run which progress engines in the application. Then the application can be deployed and the process engines can be started. The same EAR file can be used to create multiple applications and configure and deploy each application separately with different deployment options. This allows to balance the load of the application across multiple machines.
- A deployed application can be modified and redeployed. If changes do not have the desired result, you can also revert to an earlier deployment.
- Options when creating an application
- Verify application information and make choices in the fields that allow input. If desired, a different archive file can be selected by clicking Change EAR File.
- If Quick Configure is selected, the services are bound to the targets selected in the target field.
- If Quick Configure is selected, Deploy on Save can be selected. When the save button is clicked, the application is created and immediately deployed to the target machines specified in the Services pane, Target column. All variables, logging and other configuration values will use defaults defined in the archive file. The next screen will display the deployment status.
- If Deploy on Save is not selected, the application must be explicitly deployed using the application’s Configuration Console that displays upon save. This allows to change settings, such as global variable settings and runtime options before deploying.
- Deleting an application. When an application is deleted, all files associated with that application are removed and it becomes unavailable in TIBCO Administrator. In order to recreate again the application, the related EAR file must be uploaded again.
1. Click Application Management or All Applications
2. Select the application to delete
3. Click Delete
4. Click OK in the confirmation dialog.
- When an application is deployed, TIBCO Administrator copies any required configuration information to the target machine and creates services to run the deployed process engines. Any deployed service can be automatically started after the application is successfully deployed.
- A deployed application can be changed, and once it is changed, it can be deployed. The currently deployed application can continue to run while changes are made. When the updated application is deployed, the current application is automatically undeployed.
- Possible changes to an application.
- Deployment configurations
- Machines where the processes or services are deployed.
- Monitoring behavior.
- Runtime variables
- Checkpoint behavior for TIBCO ActiveMatrix BusinessWorks
- How TIBCO ActiveMatrix BusinessWorks processes are executed.
- Deploying an application
1. Click Application Management
2. Click ApplicationName > Configuration, where ApplicationName is the application created when the EAR file was loaded.
3. Before deploying
- Process Archive (PAR) can be changed
- Service Instance (
4. Click Deploy. A dialog displays and informs that all running processes with configuration changes in this application will be stopped when OK is clicked to deploy. If processes deploy successfully, they are restarted automatically if the corresponding checkbox was selected. The dialog allows to add a description and displays information about the application and each service.
5. Click OK if to deploy the application or click Cancel to choose an advanced configuration, different archive file or make other changes.
- If project is complex and multiple Enterprise Archive resources are defined for a single Design project and if each archive includes multiple processes, these archives can be deployed in a single multiple service container.
- A TIBCO BusinessWorks service container can host multiple process engine instances. Multiple EAR files can be uploaded in the same service container. All the processes running in a service container are isolated and independent of each other. So, when there is a need to include a new service or upgrade an existing service in the same project, a new EAR can be deployed in the same service container without bringing down all the running services.
- Reverting to a Previously deployed application. When an application is reverted, a different version of the currently deployed application to deploy is selected. At deployment, service instances and process engines are stopped, updated and restarted. Any component that is removed from a machine as a result of the revert operation is undeployed from that machine.
Reverting an application is only possible if the application has been deployed more than once.
1. Click Application Management
2. Click ApplicationName > Configuration, where ApplicationName is the application created when EAR file was loaded.
3. In the Configuration Builder panel, click Revert. The deployed revisions and the time at which each was deployed display.
4. Click the radio button next to the revision to use
5. Click OK. The application is now shown as ready to deploy in the Configuration Builder.
6. Click Deploy
- Undeploying a Deployed Application. When undeploying a deployed application, TIBCO Administrator stops all rnning process engines and removes them from the list of services that can be started. In fact, it completely removes all traces of the deployment (with exception of the logs). To use an earlier version of the deployment configuration, choose Revert, not undeploy.
1. Click Application Management
2. Click ApplicationName > Configuration, where ApplicationName is the application created when the EAR file was loaded.
3. In the Configuration panel, click Undeploy
4. Click OK to Undeploy or Cancel to stop the operation.
- Undeploy dialog
- Kill services that haven’t stopped after (seconds)
Amount of time to wait before stopping process engines that have not stopped. The default is zero, meaning no time is allowed for a graceful shutdown, if previously set for a process engine.
- Administrator Tasks To Perform
Lists the tasks that TIBCO Administrator will perform for this server if deploying by selecting the OK button
- Remote Tasks To Perform.
Lists the tasks performed on the selected machine (which could be the local machine) in the following fields
- Service Instance
- Service Configuration
- Deployability. Shows whether the application has been deployed before.
- Task. Actions the deployment process performs on the target machine(s).
- Undeploying Applications in a Service Container
If multiple applications related to a single Designer project have been deployed in a service container, those applications can be undeployed from TIBCO Administrator or from command line. TIBCO Administrator allows to selectively undeploy applications from the service container. However, all applications in the service container can be undeployed using the command line.
- Viewing Application Deployment History
1. Click Application Management
2. Select an application
3. Click Configuration
4. Click History
5. Click Details for more information
- If the structure of applications expected to manage is complex, applications can be organized into folders. After creating a folder, other folders can be created or add applications to the folder.
- When a folder is deleted, its content is deleted too.
- To move a folder, Administer permissions must be granted on the source folder (including its contents) and the destination folder.
- Creating a folder
1. Select either Application Management or a previously created folder
2. Click New Folder
3. Provide a folder name and, optionally, a description and contact.
4. Click Save.
- Deleting a folder
1. Select the folder’s parent, either Application Management or a previously created folder
2. Select the folder to delete
3. Click Delete
4. Click OK in the confirmation dialog
- Moving a folder
1. Select the folder’s parent, either Application Management or a previosly created folder.
2. Select the folder to move.
3. Click Move
- Moving an Application to a folder
To move an application, Administer permissions must be granted on the application and the destination folder.
1. Click Application Management or All Applications
2. Create folders if desired
3. Select the application to move
4. Click Move
5. Desired location of the application is prompted
6. Click Save to make the change
- Upgrading an application
If a new version of TIBCO Software is installed on a machine that is part of the administration domain, and the software is used in one or multiple applications,use the Upgrade feature to enable the applications to use the upgraded software. The Upgrade feature remaps properties in the property files of the process engines to use the new software targets. The Upgrade operation is not reversible. Application mst be redeployed after upgrading.
1. Click Application Management
2. Click ApplicationName > Configuration where ApplicationName is the application to upgrade.
3. In the Configuration panel, click Upgrade
4. Select Deploy after upgrade to redeploy the application as part of the upgrade. Redeploying later is possible.
5. Select Start successfully deployed services to deploy and start the service instances and process engines. If Deploy after upgrade is not selected, this option is not available.
6. Select the software to upgrade
7. Review the upgrade summary
8. Click OK
- Upgrading Application in a Service Container
Existing applications in a service container can be upgraded without bringing down all the other applications running in that service container. Using TIBCO BusinessWorks service container, the selected service can be stopped, unloaded and the upgraded service can be reloaded in the same container using the modified EAR file. Similarly, new applications can be added to the same service container in which other applications are already deployed and running.
- When an application is created, the EAR file imported has values defined for global variables. The process engines in the archive have configuration options as well. These values can be changed at deployment time.
- The Configuration console consists of two panes, Configuration Builder and Deployed Configuration. Each pane contains applications, service configurations and service instances.
- Configuration Builder pane allows to deploy, update or revert an application. Only one deployment configuration can be running at any time. Also, deployment history can be viewed. Upgrade button is also available.
- Configuration Builder pane allows to modify configurations. Deployed Configuration contains a read-only description of the properties.
-When TIBCO Administrator deploy an application, it creates an application repository that contains information about the application configuration. Certain aspects of the repository can be changed (i.e. transport)
- If domain was configured to push the application repository to the local machines where the application is run, the default choice is local. If this choice us used, each local machine must have the TIBCO Runtime Agent 5.3 (or later) installed.
- The Reset to Defaults button (Advanced tab) restores all properties to the values defined in the EAR file.
- Changing application properties.
1. Click Application Management
2. Click ApplicationName >Configuration, where ApplicationName is the application created when the EAR file was loaded.
3. In the Configuration Builder pane, select ApplicationName
4. Click the General tab to change the application name, description or contact information.
5. Click the Advanced tab to change global variables or deployment repository instance properties.
6. Click Save
7. After doing the changes, Configuration Builder indicates that deployment is out of date.
8. Click Deploy.
- Any machine in the administration domain can be assigned to run any process. Adding a process to additional machines is useful for fault tolerance. As a rule, it therefore does not make sense to run the same process on the same machine twice.
- A service can be enabled or disabled. Only enabled services are deployed. When a service is disabled, it is not longer deployed the next time the application is deployed, while all other services in the paplication are deployed as before. Only machines that have the software required by the process or service are visible when selecting the machine.
- Enabling a process to run on other machines
1. Click Application Management
2. Select an application and expand it.
3. In the Configuration Builder pane, click a service or process name. A service is named with a .arr suffix. A process is named with a .par suffix.
4. In the General pane enable or disable the process or service by selecting or clearing the Enable Service checkbox.
5. In the Target Machines pane, click Add to Additional Machines to add a selected process or service to another machine.
6. A dialog appears displaying all machines in the domain on which the software required by the process or service is available. Select a machine and then click OK.
7. Click Save
- TIBCO Hawk agent monitors managed objects by processing rulebases, which are named collections of rules that contain management logic. Using TIBCO Hawk Display, rulebases can be created with specialized rules. TIBCO Hawk Display is not included in TIBCO Runtime Agent. Hawk allows to specify a very large number of alert conditions and alert results. Full TIBCO Hawk product must be purchased in order to create TIBCO Hawk rulebases.
- The same rulebases can be loaded on a single service or multiple services. Multiple rules defined in the same rulebase can monitor a particular application or system function.
- Adding a TIBCO Hawk Rulebase to an Application
1. Click Application Management
2. Select the application for which the rulebase has been defined and expand it.
3. In the Configuration Builder pane, click the service or process name for which the rulebase has been defined. A service is named with a .arr suffix. A process is named with a .par suffix.
4. Click the Monitoring tab
5. In the Rulebases panel, click Add
6. Click Browse and in the window that appears, navigate to the directory where the rulebase is stored and select the rulebase (.hrb suffix). Click OK.
7. Click Save
- When the service is deployed, TIBCO Hawk Agent saves the rulebase file in the
- When conditions specified in the rulebase occur, the results display in the Resource Management > Machines View Machine panel.
- Rulebases can be created using the TIBCO Hawk Display rulebase editor. The rulebase file name can be saved without using a naming convention (as was necessary in releases prior to 5.3). TIBCO Hawk Agent creates the appropriate rulebase name and file when the service instance to which the rulebase is assigned is deployed. The rulebase file name should not contain the space character.
- TIBCO Hawk generated a file for each rulebase for each service instance which the rulebase was created for (at deployment time). Rulebase file name format is
- The rulebase file names for each instance are stored in an external property file so the TIBCO Hawk Agent knows where to re-load the rulebase files if it is restarted.
-Rulebase file names are stored in the
- TIBCO Hawk Agent assumes that the input rulebase file name provided when uploading a rulebase file uses the hrb extension. If there is no file extension, Hawk Agent appends .hrb to the rulebase file during deployment.
- Certain variables can be assigned to a rulebase and TIBCO Hawk Agent will substitute values for the variables when the application is deployed. Variable substitution is typically used in a rulebase to change the data source from pointing to a specific service instance to point to a generic service instance.
- Variable supported by TIBCO Hawk Agent.
%%TIBCO_DEPLOYMENT%%-When encountered, Hawk Agent substitutes the application’s deployment name.
%%TIBCO_COMPONENT_INSTANCE%%-When encountered, Hawk Agent substitutes the service instance name.
%%TIBCO_DOMAIN%%-When encountered, Hawk Agent substitutes the administration domain name
%%TIBCO_COMPONENT_TYPE%%-When encountered, Hawk Agent substitutes the component’s type.
- An event type can be defined in order to respond to a service instance failure, or to be triggered when a match occurs for some condition that is reported in the service instance log file.
- Adding an Event to a Service
1. Click Application Management
2. Select an application and expand it.
3. In the Configuration Builder pane, click a service or process name. A service is named with .arr suffix and a process is named with a .par suffix.
4. Click the Monitoring tab
5. Click Add in the Events panel
6. Specify the conditions and the event
a. First choose a condition in the General panel.
b. In case the condition is met, an alert or an email are sent or command executed (or combination).
7. When both condition and event are configured, click OK
8. Click Save.
The event can be sent as an alert, by email or can trigger an operating system command. If the event is sent as an alert, it appears in the View Service Instance dialog under the Active Alerts pane.
- TIBCO Administrator can be used to configure the location where TIBCO ActiveMatric BusinessWorks process engines store internal information.
- Functionality only available when using a database for storing information
- Shared variables passing information across multiple process engines.
- Duplicate detection of messages across multiple engines after a recovery from a checkpoint.
- Using critical section groups across multiple engines.
- Wait/Notify, activities can be used to pass data between services running on different machines.
- Configuring a database for storage
1. In TIBCO Designer, specify a JDBC Connection resource for the database to use, and then build the EAR file.
2. After uploading EAR file and created the application in TIBCO Administrator GUI, select Application Management then select the application in the Configuration Builder pane of the Configuration console.
3. Select the service (.par) in the Configuration Builder pane and choose the Advanced tab
4. In the TIBCO ActiveMatrix BusinessWorks Checkpoint Data Repository pane, select the Database pane.
- When database is selected for storage of TIBCO ActiveMatrix BusinessWorks, tables are created in the database. The administration domain name (first 8 and last 8 characters and invalid characters are converted to underscores) and deployment ID (assigned by TIBCO ActiveMatrix BusinessWorks) are used to guarantee uniqueness of the tables for each domain and each deployment.
- Tables created by TIBCO ActiveMatrix BusinessWorks begin with T_
- The process engine creates database tables used to store process engine information automatically. If it is not permitted, TIBCO ActiveMatrix BusinessWorks also provides templates scripts for the supported databases in the
-
- Manually creating the tables.
1. Create a deployment configuration that specifies a database for process engine storage.
2. Before starting the process engine, examine the deployment configuration file (the
3. Edit the appropriate SQL script template for the database used and replace
4. Change
5. Save the changes to the SQL script.
6. Run the SQL agains the database to use.
7. Start the process engine.
- Depending on the available machine resources, only a limited number of process instances may be able to run concurrently.
- Process instances typically remain in memory as long as they are executing an activity. If the process instance is waiting for an incoming event, the process instance can be paged out to disk and resumed later after the event arrives. New process instances are paged out to disk until there is available memory and resources to accomodate them. TIBCO Administrator can be used to control the execution of TIBCO ActiveMatrix BusinessWorks process instances. This is useful if the system has limited memory or resources or if sequential running of process instances should be restricted.
- TIBCO ActiveMatrix BusinessWorks settings
- Max Jobs. Maximum number of process instances that can concurrently be loaded into memory.
- Use Activation Limit. Specifies that once a process instance is loaded, it must remain in memory until it completes.
- Flow Limit. Specifies the maximum number of concurrently running process instance to start before suspending the process starter.
- Changing process configuration properties
1. Click Application Management
2. Select an application and expand it.
3. Click Configuration
4. In the Configuration Builder pane, click a process name. A process is named with a .par suffix
5. Click the Advanced tab.
6. Change the properties as required.
7. Click Save
- Incoming events may not be evenly distributed over time. To prevent a system from being overwhelmed by incoming events, the Flow Limit field limits the number of process instances created by a process starter. This allows to control the flow of processing so that incoming events are not longer accepted when the limit is reached.
- Controlling the flow of processing is especially useful when protocols can store unsent messages on the server until the receiver is ready to process them.
- When a process engine reaches the specified Flow Limit, it is placed in a FLOW_CONTROLLED state. In this state, process engine can continue executing existing process instances, but new process instances are not allowed. Incoming messages can then be directed to another process engine. A process engine will resume creating new process instances once a sufficient number of its current process instances have completed.
- Typically a process engine comes out of the FLOW_CONTROLLED state when the number of process instances completed is approximately half of the value specified for the Flow Limit property.
- The HTTP Receiver process starter uses a mechanism for controlling the flow of incoming events limited to
- Max Jobs field in Process Configuration dialog allows to specify the maximum number of concurrent process instances that can be stored in memory. Any process instances created once the maximum jobs is reached, should be paged out to disk. Specifying a value for Max Jobs causes the process engine to incur some overhead for managing the paging of process instances to and from disk. If system resources are sufficient and incoming events are not expected to exceed the system limits, specify Max Jobs to 0, which allows the process engine to create an unbounded number of process instances and eliminates the overhead of paging.
- The Use Activation Limit field specifies that once a process instance is loaded into memory, it should not be paged out to disk until it completes. This option is useful if specifying sequential processing of incoming events or limited concurrent execution of process instances is enforced.
- Max Jobs and Use Activation Limit field work together to provide different concurrency limits. The Flow Limit field also affects the concurrency limits.
Max Jobs Use Activation Limit Flow Limit Description
0 Cleared or Selected 0 Unlimited number of process instances can be created and concurrently loaded into memory
0 Cleared or Selected N No paging of process instances. Allows up to N process instances before placing process starter in flow controlled status.
1 Selected N One process instance is loaded into memory at a time and kept there until it completes its execution. This guarantees incoming events are processed in the order in which they occur. Up to N process instances are paged to disk. and then the process starter is placed into flow controlled state.
Note. If incoming events are going to be processed sequentially, use Sequencing Key on the Misc tab of the process starter. Using Max Jobs and Use Activation Limit incurs overhead as process instances are paged out to disk and retrieved from disk.
1 Selected 0 One process instance is loaded into memory at a time and kept there until it completes its execution. This guarantees incoming events are processed in the order they occur. There is no limit on the number of process instances that can be created and paged to disk.
1 Cleared N One process instance is loaded into memory at a time, but up to N process instances are created. Incoming events can be processed in any order because process instances are not kept in memory until they complete execution.
M Selected 0 Unlimited number of process instances can be created, but only M are loaded into memory and processed concurrently. This setting ensures a limited amount of concurrent processing. Setting Max Jobs to a relatively small number and the Use Activation Limit option keeps each service in memory until the service completes. Once a service releases the resource, a new process can be loaded into memory and the corresponding service can use the resource.
M Selected N Same as above except only N process instances are created before the process engine is placed into flow controlled state.
M Cleared 0 Unlimited number of process instances can be created, but only M are loaded into memory and processed concurrently. After M process instances are created, new process instances are paged out to disk. There is no guarantee of the order in which process instances are executed.
M Cleared N Same as above except only N process instances are created before the process engine is placed into flow controlled state.
- Certain properties can be changed for a process engine, as well as Java properties (classpath, heap size)
- Start on Boot
- Enable Verbose Tracing
- Max Log File Size
- Max Log File Count
- Thread Count
- Changing Server settings.
1. Click Application Management
2. Select an application and expand it to view process engines.
3. Click a process engine or service instance.
4. Click Server Settings
5. Change options as required.
6. Click Save.
- The graceful shutdown command causes the process engine to deactivate all process starters and wait (up to the maximum timeout) for all current jobs to either finish or take checkpoint, before shutting down the engine. If Wait For Checkpoints is selected, the engine will wait up to the Kill Jobs Timeout for all jobs to finish even if they take a checkpoint.
- Setting Graceful shutdown properties.
1. Click Application Management
2. Select an application and expand it to view a process instance
3. Create the process engine.
4. Click the Graceful Shutdown tab
5. Change options as required.
6. Click Save.
- TIBCO ActiveMatrix BusinessWorks process engine can be configured to be fault-tolerant. Several engines can be started up. In the event of a failure, other engines restart process starters and the corresponding services.
- If a database is used to store process engine information, a process instance is re-instantiated to the state of its last checkpoint. In the event of a failure, any processing done after a checkpoint is lost when the process instance is restarted by another engine.
- One engine is configured as the master, and it creates and executes services. The second engine is a secondary engine, and it stands by in case of failure of the master. The engine send heart beats to notify other they are operating normally. In the event the master process engine fails, the secondary engine detects the stop in the master’s heartbeat and resumes operation in place of the master. Al process starters are restarted on the secondary, and services are restarted to the state of their last checkpoint. The expected deployment is for master and secondary engines to reside on separate machines. Multiple secondary engines can be set if desired and a weight can be specified to each engine. The weight determines the type of relationship between the fault-tolerant engines.
- A master and its secondary engines is known as a fault-tolerant group. The group can be configured with several advanced configuration options such as heartbeat interval and the weight of each group member.
- Members of a fault-tolerant group can be configured as peers or as master and secondary engines.
- If all engines are peers, when the machine containing the currently active process engine fails, another peer process engine resumes processing for the first engine, and continues processing until its machine fails.
- If the engines are configured as master and secondary, the secondary engine resumes processing when the master fails. The secondary engine continues processing until the master recovers. Once the master recovers, the secondary engine shuts down and the master takes over processing again.
- The Fault Tolerance tab of the Process Engine deployment resource allows to specify the member weight of each member of a fault-tolerant group. The member with the highest weight is the master. Peer can be selected in the first field on the tab to configure all engines as peers. Primary/Secondary can also be selected in order to set the engines as Master/Secondary. Custom can also be selected in order to specify values for the weight of each member of the group.
- When a master process engine fails, its process starters are restarted on the secondary engine. This may not be possible with all process starters. Each process starter has different configuration requirements, and not all process starters may gracefully resume on a different machine. Additional hardware or software may be needed to redirect the incoming events to the appropriate place in the event of a failure. Also, the servers may not have all of the necessary software for restarting all of instances.
- Secondary process engine loading different process definitions than the master is possible. Only process definitions that can gracefully migrate to a new server during a failure may be loaded.
- FT Group Settings panel displays only if the TIBCO ActiveMatrix BusinessWorks process selected has been added to at least two different machines. If the domain includes components that were deployed as part of a fault-tolerant group, the display includes information about the group.
- One or more process engines in the group can be started. If more than one engine has started, only one is displayed as Running and all other engines are displayed as Standing By (or Starting Up).
- Changes on the status of a component part of a FT group affect all other members of the group.
- After deploying the process engines, it is most efficient to select all process engines by clicking the check boxes and then choose Start. After the primary and secondary engines have communicated, the master will display as Running and all other as Stand By. If only primary is started, it will first go to Stand By mode as it checks the status of the other engines. It then changes to Running.
- If a process engine is shut down, the appropriate secondary engine starts automatically.
- Setting a process engine as fault tolerant.
1. Click Application Management.
2. Select an application and expand it.
3. In the Configuration Builder pane, click the process name. A process is named with a .par suffix.
4. Click General tab
5. Select Run Fault Tolerant. Change options as required.
6. Click Save.
- A checkpoint saves the current state of a running process instance. For a secondary process engine to resume running process instances from their last checkpoint, the secondary process engine must have access to the saved state of the process instances from the master process engine. Features that allow communication across process engines require a database for storage. Process engines that do not communicate with each other, can use file system for process engine storage. In this case, primary and secondary engines must point to the same shared location within the file system.
- Due to fault-tolerant engines are expected to be on separate machines, a database for storage for each process engine should be specified. This allows to specify the same JDBC Connection resource for the master and secondary engines, and therefore all engines can share the information stored for process instance checkpoints.
- If all engines share the checkpoint information, then the secondary engines can recover process instances up to their last checkpoint. If engines do not share the checkpoint information, process instances are not restarted.
- Changing checkpoint data repository properties
1. Click Application Management
2. Select an application and expand it.
3. In the Configuration Builder pane, click a process name. A process is named with a .par suffix.
4. Change properties as required. The value defaults to Checkpoint Data Repository. If a JDBC Connection Resource has been configured for the project, there is also an option to choose database.
5. Click Save.
- Changing Runtime Variables for a Process or Service. Some service and process specific runtime variables can be defined in TIBCO Designer and changed in TIBCO Administrator. When defining runtime variables in TIBCO Designer, it is specified wherther the variable should be settable at design-time only, for deployment, or for the service. All variables that were designated settable for the service are then displayed in TIBCO Administrator. Click Reset to Default to reset to the default values defined in the enterprise archive file.
1. Click Application Management
2. Select an application and expand it.
3. In the Configuration Builder pane, click a service or process name. A service is named with a .arr suffix. A process is named with a .par suffix.
4. Click the Advanced tab
5. Change runtime variables as required.
6. Click Save
- Configuration Builder pane.
- Deploy. Click to deploy the application. the deploy dialog appears.
- Revert. Click to select a different configuration of the currently deployed configuration. Deployment of this configuration can be performed.
- Undeploy. Click to undpeloy the application. When an application is undeployed, TIBCO Administrator stops all running services and removes them from the list of services that can be started. In effect, it completely removes all traces of the deployment (with exception of the log files).
- History. Click to view the deployment histoty for this application.
- Upgrade. If a new TIBCO software is installed on a machine that is running process or service instances, the instances to use the new software can be upgraded by clicking Upgrade.
- Show deployed configuration. Select to display the Deployed Configuration dialog box where detailed information about the components deployed in the application.
- Configuration List. Each component and service in the application along with one of the following description in the deployability column.
- Deployable (Remove).
-On Component. The last uploaded EAR file does not contain this component. The component and all service instances will be removed from the application on deploy.
-On Service instance. Service has been deleted. This will take effect on deployment.
- Deployable (New). The component or service has never been deployed successfully. If all service instances are removed and new ones added, the component will be in this state.
- Deployable (Archive Update). The last uploaded EAR file has changes related to this component. Changes will take effect on deployment.
-Deployable (Configuration Changes). Changes have been made to the service instance configuration and will take effect on deployment.
- Deployable (Last Deploy Failed). The last deployment failed. History should have details. Likely problems are the TIBCO Hawk agent needs to be started on the target machine, or TIBCO Rendezvous communication or configuration parameters are not correct.
- Synchronized. Configuration is correct. There have been no changes since last successful deployment.
- Needs configuration. A component or service instance must be selected and then each tab. Workflow in particular requires this for some automatic configuration to be done. Must be remedied or the component must be disabled before deployment can succeed.
- Need to deploy in a Service Container. There are no service instances specified for the component. At least one machine must be assigned to component to enable deployment or it must be disabled.
- Need to bind to a Service. Not currently used.
- Deployable, services require deployment. The undeploy command was run. All services are configured correctly and are ready for deployment.
- Deployable, containers require deployment. The component had a service instance modified, added or removed. The change will take effect on deployment.
- Services require configuration. A component has a service instance that needs to be configured. Deployment can not be done until this is remedied or the component is disabled.
- Disabled. The component is marked disabled and it will not be deployed. If deployment is attempted, the component will be undeployed when deployment is done.
- Disabled. Will remove existing configuration. This component for the deployed service instance was marked Disabled. When deployment is done, the service instance will be undeployed.
- Deployed Configuration Pane. Displays deployed components for this application and their status. Click each component to view detailed information about the deployed component.
- Edit Application Configuration Dialog. Fields can be edited if this dialog is invoked from the Configuration Builder pane. If invoked from Deployed Configuration pane, the fields are read only.
- General Tab
-Application Archive. Provides information about the EAR file including the package name, version, description, creation date and owner.
-Upload New EAR File. Allows to replace the current EAR file with an updated version.
-Application Parameters. Provides information about the application name, associated deployment name, description and contact name for the application.
- Advanced Tab. The Reset to Defaults button resets all global variables to default settings as set in the EAR file.
- Global Variables. Displays the global variables set in the EAR file for this application. Global Variables predefined by default.
- DirLedger. Used by the system when defining the path name of the TIBCO Rendezvous certified messaging ledger file. Default is root installation directory.
- DirTrace. Used by the system to partially create the name for log file used by the adapter. Default is the root installation directory.
- HawkEnabled. Used by the system to indicate whether TIBCO Hawk is used to monitor the adapter. True indicates that a Hawk microagent is defined for the adapter. False indicates the microagent is not to be used. Default is False.
- JmsProviderUrl. A JMS provider URL tells applications where the JMS daemon is located. Setting this value mostly makes sense in early stages of a project, when only one JMS daemon is used.
- JmsSslProviderUrl. Specifies where the JMS Server, running in the SSL mode, is located. Setting this value mostly makes sense in the early stages of a project, when only one JMS Server is used.
- RemoteRvDaemon. Used by the system to identify the TIBCO Rendezvous routing daemon.
- RvDaemon. Used by the system to identify the TIBCO Rendezvous daemon parameter. The parameter instructs the transport object about how and where to find the Rendezvous daemon and establish communication. Default is 7500 which is the default value used by the Rendezvous daemon.
- RvNetwork. Used by the system to identify the TIBCO Rendezvous network parameter. Every network transport communicates with other transports over a single network interface. On computers with more than one network interface, the network parameter instructs the TIBCO Rendezvous daemon to use a particular network for all outbound messages from this transport.
- RvService. Used by the system to identify the TIBCO Rendezvous service parameter. The Rendezvous daemon divides the network into logical partitions. Each transport communicates on the same service.
- RvaHost. Used by the system to identify the computer on which the TIBCO Rendezvous agent runs.
- RvaPort. Used by the system to identify the TIBCO Rendezvous agent TCP port where the agent listens for client connection requests. Default is 7501.
- TIBHawkDaemon. Used by the system to identify the TIBCO Hawk daemon parameter. Default is 7474.
- TIBHawkNetwork. Used by the system to identify the TIBCO Hawk network parameter. Default is an empty string.
- TIBHawkService. Used by the system to identify the TIBCO service parameter. Default is 7474
- MessageEncoding. The message encoding set for the application. The value is ISO8859-1 which only supports English and other western European languages that belong to ISO Latin-1 character set. After the project is deployed in an administration domain, the messaging encoding set at design time is overriden by the domain’s encoding property. All the TIBCO components working in the same domain must always use the same encoding for intercommunication.
- When TIBCO Administrator deploys an application, it creates an application repository which contains information about the application configuration. Some aspects if the application repository can be viewed and changed. In Transport, transport the administration server uses to communicate with the client application. Choose local, rv (TIBCO Rendezvous) or HTTP, or HTTPS if the administration domain has been set up to use HTTPS.
-local. By default the transport is set to local. This means that the application repository will be sent to the target machine. This allows the application to run independently of the administration server. If the transport is changed from local to another value, the application repository will not be pushed to the target machine, and the application will communicate with the administration server at runtime. Local choice is supported only if the target machines have installed TIBCO Runtime Agent 5.3 or later.
- rv. If selected, the client application will use TIBCO Rendezvous to communicate with the administrator server.
- Server Name. administration server name.
- Instance Name. Service instance name, that is, the instance of the service running on a particular machine.
- User Name. UYser authorized for this application repository. Defaults to the user currently logged into Administrator.
- Password. User’s password
- Timeout. Amount of time in miliseconds allowed for completing a task, such as retrieving retrieving information from the server. Defaults to 600 seconds.
- Service, Network, Daemon. TIBCO Rendezvous connection parameters used.
- Discovery Timeout. Amount of time in seconds allowed for the initial connection to the administrator server
- Regional Subject. TIBCO Rendezvous subject prefix used for regional read-operation in the load balancing mode.
- Operation Retry. Number of times to retry after a timeout occurs.
- http. If selected, the client application will use HTTP to communicate with the administration server. If the administration domain is not initially enabled for HTTPS, and there are deployed applications in the domain that use HTTP to connect to the application repository, the service instances will not restart after they are shut down. In this case each service instance must be redeployed after changing the transport to HTTPS.
- Server Name. administration server name.
- Instance Name. Service instance name, that is the instance of the service running on a particular machine.
- User Name. User authorized for this application repository. Defaults to the user currently logged into Administrator.
- Password. User’s Password
- Timeout. Amount of time in seconds allowed for completing a task, such as retrieving information from the server. Defaults to 600 seconds.
- HTTP URL, HTTPS URL.. The URL on which the client attempts to connect to the server. What displays depends on whether you configured the server for HTTPS.
Note. HTTP or HTTPS cannotbe used to connect to a 4.x adapter.
- If rv or http are selected in the Transport field, click the Preview URL button to display the URL that the application uses to access the application repository.
- Edit Service Configuration dialog. Fields can be edited if this dialog is invoked from the Configuration Builder pane. If invoked from the Deployed Configuration pane, the fields are read only.
- General Tab
- General.
- Name. Service Name
- Description. Service Description
- Additional Required Components. Any other components required to run this service. This service cannot be enabled unless this field is empty.
- Enable Service. Only enabled services are deployed. Disabling a service, effectively undeploys just that service while letting all other services in the application run as normal.
- Target Machines.
- Remove from Selected Machines. Click to remove the service configuration from the selected machine(s).
- Add to Additional Machines. Adding services to additional machines is useful for fault tolerance. As a rule, it therefore does not make sense to run the same service on the same machine twice.
- Service Instance. Service instance from the selected machine. The service instance name includes the machine name.
- Software. The software required by this service instance.
- Deployment Status. Deployment required by this service instance.
- FT Weight. The fault tolerance status and weight of the service instance. Appears only if Run Fault Tolerant is selected.
- FT Group Settings. Appears only if a TIBCO ActiveMatrix BusinessWorks process is assigned to additional machines. Note that TIBCO Adapter Services cannot be assigned file tolerant options.
- Run Fault Tolerant. If selected, the selected service instances will run in fault tolerant mode.
- Heartbeat Interval (ms). The master engine of a fault-tolerant group broadcast heartbeat messages to inform the other group members that it is still active. The heartbeat interval determines the time (ms) between heartbeat messages. In the event if one process engine fails, another engine detects the stop in the master’s heartbeat and resumes operation in place of the other engine. All process starters are restarted on the secondary, and services are restarted to the state of their last checkpoint.
- Activation Interval (ms). Secondary process engines track heartbeat messages sent from the master engine. This field specifies the amount of time to expire since the last heartbeat from the master before the secondary restarts the process starters and process engines. The Heartbeat Interval should be smaller than the Preparation Interval, which should be smaller than the Activation interval. It is recommended that Activation interval be slightly over 2 heartbeats
- Preparation Interval (ms). When a master engine resumes operation, the secondary engine shuts down and returns to standby mode. For some situations, it may be necessary to ensure that the secondary engine has completely shut down before the master engine resumes operation. This field is used to specify a delay before the master engine restarts. When the time since the last heartbeat from an active member exceeds this value, the ranking inactive member will receive a hint so that it can prepare for activation.
- Monitoring tab
- Rulebases. Click Add to add an existing custom TIBCO Hawk rulebase. The rulebase must have been configured using TIBCO Hawk Display.
- Events. Click Add to create an event
- Failure Count. When an instance is down unexpectedly, the error count and last failure time are tracked. When error count is greater or equal to the value set for Reset Failure Count, or if the value for Reset Failure Interval expires (whichever comes first), the error count is reset to zero.
- Reset Failure Count. The value in this field defines how many restarts should be attempted before resetting the error counter to zero. When an instance is down, the TIBCO Hawk Agent will attempt to restart the instance the number of times specified in this field. If the instance restarts after the number of times specified, the event defined is triggered.
- Reset Failure Interval (seconds). The value in this field defines how much time should expire before resetting the error counter to zero. If receiving alerts frequently is not desired. Reset Failure Count should be set with a high value. When error count is reset to 0, the last failure time is reset as well. The Reset Failure Interval takes effect only after the first failure occurs.
- Advanced tab. Click Reset to Defaults to use the defaults defined in the EAR file.
-Adapter SDK Properties. Displays if an adapter service is included in the application. Allows to change TIBCO Adapter SDK properties that were defined in the EAR file.
-Runtime Variables. Displays if an adapter service is included in the application. Displays the runtime variables settable for this service. Runtime variable values can be changed as required.
- TIBCO ActiveMatrix BusinessWorks Checkpoint Data Repository. If TIBCO ActiveMatrix BusinessWorks is going to use multiple engines in fault tolerant mode, a checkpoint data repository must be specified. For a true fault tolerance, data must be stored in a database. A JDBC Connection resource for the database to be used is specified when a project is configured in TIBCO Designer. The databse is then one of the available options on the pop-up menu.
- TIBCO ActiveMatrix BusinessWorks Process Configurations. Allows to change process configurations. The Flow Limit parameter always appear in release 5.2 and later and only has meaning when deploying to a TIBCO ActiveMatrix BusinessWorks release 5.2 process engine. If Administrator 5.2 or later is used to deploy a TIBCO ActiveMatrix BusinessWorks release 5.1.3 process engine, the parameter will display, but have no effect on the process engine.
- Edit Service Instance Dialog.
- General tab. Displays the following information
- Software that will run the used by the service instance.
- Machine on which this instance has been set up to run.
- Operating system used by this machine.
- Name of the service instance
- Description for this service instance
- Contact for this service instance.
- Server Settings tab.
- General.
- Start on Boot. Specifies that the service instance should be started whenever the machine restarts.
- Enable Verbose Tracing. Enables verbose tracing. In particular, for TIBCO Activematrix BusinessWorks service instances.
- Max Log File Size (KB). Specifies the maximum size a log file can reach before the engine switches to the next log file.
- Max Log File Count. Specifies the maximum number of log files to use. When log files reach the size specified in the Max Log File Size field, the engine switches to the next log file. When the maximum number of log files have been written, the engine begins writing to the first log file again.
- Thread Count. Specifies the number of threads to use to execute process instances. The number of threads determines how many process instances can execute concurrently. Set the number of threads to a value that is appropriate for the operating system and physiscal machine configuration. Available CPU and memory resources on system should be measured under a typical processing load to determine if the default value of 8 threads is appropriate for the environment. Typical numbers of worker threads range between 4 and 32. Specifying too low a value can cause higher memory use and lower engine throughput even through spare CPU resources exist. Specifying too high a value can cause CPU thrashing behavior or an increase in latency caused by a large number of messages in the message queue.
- Java. Only available for Java applications.
- Prepend to Classpath. Items supplied here are prepended to CLASSPATH environment variable. A Java code editor can be specified, or the jar file from a JNDI provider if TIBCO ActiveMatrix BusinessWorks to receive and process JMS messages.
- Append to Classpath. The items supplied here are appended to CLASSPATH environment variable. A Java code editor can be specified, or the jar file from a JNDI provider if TIBCO ActiveMatrix BusinessWorks to receive and process JMS messages.
- Initial Heap Size (MB). Initial size for the JVM used for the process engine.Default is 32MB
- Maximum Heap Size (MB). Maximum size for the JVM used for the process engine. Default is 128MB.
- Java Thread Stack Size (KB). Size for the thread stack. Default is 128 KB.
- NT Service.
- Run as NT Service. Select to run this service as a Microsoft Windows Service. The engine can then be managed as any other service, and automatic start when machine reboots can be specified.
- Startup Type. Choose one of the service startup types, Automatic, Manual or Disabled.
- Login As. Specify the login account for the service, if any. The domain name must be specified. If the user is defined in the local machine, the domain is “.” (.\lgonzalez).
- Password. Click set to define the password for that service, if any.
- Graceful Shutdown tab. Appears only if this dialog was displayed from an undeployed process.
- 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.
- View Service Configuration.
- General. Displays the name of the service and description provided when the service was deployed. It also displays whether additional components are required and whether the service is enabled. The Target pane displays the service instance, the software used for the instance and the deployment status.
- Monitoring. Displays the TIBCO Hawk rulebases defined for the service, events defined and the failure count.
- Advanced. Displays the TIBCO Adapter SDK properties and runtime variables for the service.
Great information . thanks for sharing .
ResponderEliminarInformative blog.
ResponderEliminarTIBCO BusinessWork ContainerEdition Online Training
Thanks for such a great article here.
ResponderEliminarTIBCO Business Works Training
Such a nice blog, I really like what you write in this blog.
ResponderEliminarTIBCO BW Online Training Course
TIBCO BW 6.X Online Training
TIBCO BW 6.x training in Ameerpet
TIBCO BW 6.x training in Hyderabad
Este comentario ha sido eliminado por el autor.
ResponderEliminarvirtual edge. 28 percent of the time that attendees spend exploring the platform before a virtual event is spent browsing exhibitors and 8 percent is spent looking at exhibitor products. team ice breaker ideas and sample personal biography on yourself
ResponderEliminar