TIBCO

lunes, 17 de octubre de 2011

TIBCO BW Administration (1-3)

-.hrb
- 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\tra\domain\\startup\.properties file in the rbList property.
- 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___. Storage parameters for these tables can be changed if desired, but table names and column definitions must remain the same.
- 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 /bin directory. In these scripts (internal, jobs, wait, notify, duplicates) and are placed in the SQL code as placeholders.
- is determined by default at deployment time. This prefix can be obtained by locating the Database.Tablename.Prefix property in the deployment configuration file and substituting its value where required in the template SQL script. - is 128, so the value must be supplied in the script.
- 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 .tra file) and locate the property Database.Tablename.Prefix
3. Edit the appropriate SQL script template for the database used and replace with the value of the Database.Tablename.Prefix property.
4. Change to 128
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 - 1
- 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.

miércoles, 5 de octubre de 2011

TIBCO BW Process Design Guide (3 - 3)

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

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

-The schema import tool, allows to import resources such as XSDs or WSDL files into a TIBCO ActiveMatrix BusinessWorks project. The tool can also resolve references to other resources within the imported resources. The tool can be used to import,
-XSD. XML schema definition language for declaring schema components like elements, attributes and notations.
-WSDL. Web Services Definition Language for declaring the interface definition of a web services. WSDL files typically include XSD definitions as well.
-Schema import tool helps to resolve broken references to other resources using import and include statements.
- To invoke the schema import tool, choose Tools>Schema Importer from the TIBCO Designer menu.
- The Schema Import tool stores imported resources in a Location resource in the project. This resource is a temporary holding area for XSDs and WSDL files while importing and resolving references in the resources. The Location resource corresponds to one XSD or WSDL file. The Location resource holds the specified resource and any resources referenced by the XSD or WSDL file. A new Location resource must be created for each XSD or WSDL file to be imported.
- The imported resources remain in the Location resource so that any conflicts or errors can be resolved in the imported resource. Once all conflicts and errors have been resolved, the XSDor WSDL resources can be imported into the project.
- Once resources have been imported into the project, the Location object stores a pointer to where the imported resources were originally located. Location resources can be removed after the desired resources have been imported into the project.
- To import XSD or WSDL resources.
1. Choose Tools>Schema Importer from TIBCO Designer menu or use Control+Shift+L keyboard shortcut.
2. Click the Down arrows button next to the text Add a New Location at the top left of the schema Importer dialog. Select New Import Resolver from the pop menu. Select New Import Resolver from the popup menu. A Location resource appears in the project tree in the Schema Importer dialog.
3. In the URI field, enter a valid URI that specifies the location of the resource to import. Browse button can be used to locate resources in the file system, or HTTP or FTP protocol to locate remote resources.
4. In the Download Folder field, specify the folder in the project in which to place the imported resources once any conflicts or errors have been resolved. Browse button can be used to locate a folder in the current project.
5. Click the Fetch button to retrieve the specified resource. The resource and any referenced resources are stopped temporarily in the Location resource created in step 2. Location resource can expand to view the retrieved resources. Select a resource to view the Information tab or Source tab to see more details about the resource.
6. Any errors are reported on the Errors tab. Select each error and choose the correct option to resolve the error. Ignore the error can also be chosen in order to not resolve the error.
7. Click the Save button to import the resources into the project. The schema import tool does not allow to import any resources until all errors have been either resolved or marked to ignore.

- TIBCO ActiveMatrix BusinessWorks can use Secure Sockets Layer (SSL) to provide secure communication. The successor to SSL is Transport Layer Security (TLS), but the term is used synonymously with TLS in this document.
- Secure Sockets Layer (SSL) is a protocol that uses public and private keys to secure communication between parties.
- When an SSL connection is requested, the initiator (or client) and responder (or server) perform a handshake where digital identities or certificates are exchanged to ensure that both parties are who each party expects.
- SSL can also be used to specify an encryption algorithm for the data that is exchanged between the parties.
- TIBCO ActiveMatrix BusinessWorks can act as an initiator or a responder in an SSL connection. Several types of connections can optionally use SSL, such as,
FTP Connection
HTTP Connection
JMS Connection
Rendezvous Transport
In addition, the following activities can also specify SSL connections
ActiveEnterprise Adapter activities using JMS or RV transports
Send HTTP Request
SOAP Request Reply
- TIBCO ActiveMatrix BusinessWorks uses digital certificates to validate the identity of parties in an SSL connection. TIBCO ActiveMatrix BusinessWorks requires that both initiators (clients) and responders (servers) must present certificates during SSL handshake. Typically, only the server is required to present its certificate to the client for verification, but TIBCO ActiveMatrix BusinessWorks enforces a bi-lateral model where both client and server must present certificates.
- TIBCO ActiveMatrix BusinessWorks uses the Identity resource to configure the identity of activities that act as initiators (clients) or responders (servers) in an SSL connection. The Identity resource stores the certificate of the activity (initiator or responder) and the location of the folder in the project that contains the trusted certificates of other parties that can participate in an SSL connection.
- Identity resources contain information that is used to authorize a connection. The responder (or server) in an SSL connection request must have an identity, but the initiator (client) must also have an identity. The identity resource can be used to store one of the following types of identitites,
-Username/Password. Used to store a username and password. Useful when basic client authentication is needed. Typically not used within TIBCO ActiveMatrix BusinessWorks.
-Certificate/Private Key. Used when public key and the certificate are stored in two separate files. Typically certificates are stored in Privacy-enhanced Electronic Mail (PEM) format. The URL for the certificate and key must be provided, as well as the password for the key. This identity can be used when acting as initiator or responder in an SSL connection.
-Identity File. Used when the certificate includes the public key information in the certificate file. The URL and file type of the certificate must be provided as well as the password for the key. The certificate can be on of the following formats
Entrust.
JCEKS. Java Cryptography Extension key Store file format
JKS. Java Key Store file format.
PEM. Privacy-enhanced Electronic Mail file format.
PKCS12. Public Key Cryptography Standard (12) file format.
- Trusted certificates are typically issued by a trusted third party, such as a certificate authority. There are several commercial certificate authorities, such as Entrust or VeriSign.
- Both clients and servers can also store a list of trusted certificates. When a connection is requested, each party presents their certificate and that certificate is checked against the list of trusted certificates. If the certificate is not found, the connection is refused. Checking trusted certificates allows clients to ensure that they are connecting to the correct server. For servers, trusted certificates are used to ensure only the authorized clients can connect to the server.
- Checking a certificate involves checking the certificate of the party that signed the certificate. There can be a hierarchy of intermediate certificates, also known as a certificate chain, that must be checked up to the root certificate to ensure that a certificate is authentic. TIBCO ActiveMatrix BusinessWorks requires that all intermediate certificates are stored in the trusted certificate location so that certificates can be properly verified.
- Adding Certificates to a project. To add a certificate in PEM format to a project
1. Select a folder into which the certificate will be imported
2. From the menu bar, choose Tools > Trusted Certificates > Import into PEM Format.
3. Provide the certificate URL when prompted.
Certificates in PKCS7 and PEM formats (these formats do not store keys). A new certificate copy is created when the import is done. If the certificate to be imported is already in PEM format, a new copy is created as is. Certificates from storage formats that require a password cannot be imported (PKCS12 and KeyStore)
- Storing trusted certificates outside the project. (Avoids re-create EAR file and re-deploy)
1. Create a folder in the file system, where the trusted certificate will be stored. Copy this folder to each machine where the process engine will be deployed, or the location can be shared network area accessible by all process engines.
2. In the TIBCO ActiveMatrix BusinessWorks, create a global variable named BW_GLOBAL_TRUSTED_CA_STORE
3. Set BW_GLOBAL_TRUSTED_CA_STORE to the location of the trusted certificates folder on the file system. The location can either be the same for all deployed engines, or the global variable value can be changed when the project is deployed to the location on the machine where the trusted certificates is placed. The value for BW_GLOBAL_TRUSTED_CA_STORE must be a file URL (file:///c:/tibco/certs)
4. Specify a value in the Trusted Certificates field in the SSL Configuration dialog. When the project runs, the value of BW_GLOBAL_TRUSTED_CA_STORE overrides the value specified with the location provided.
- For connections that allow to use SSL, there is a checkbox on the configuration that, when checked, allows to click the Configure SSL button which brings up an SSL configuration dialog with specific options for the type of activity or connection that is being configured. Potential configuration fields,
FTP Connection. Used to specify FTP server. TIBCO BW acts as an initiator
-Trusted Certificates folder. Folder in the project containing one or more trusted certificates. This folder is checked when an FTP activity connects to ensure that the responder’s certificate is from a trusted authority. This prevents connections to rogue servers.
- Identity.Identity resource that contains the client digital certificate and a private key.Optional
- Verify Host Name. Specifies to check that the host name of the FTP server against the host name listed in the server’s digital certificate. If it does not match, the connection is refused. If a hostname equivalent is specified in the Host field, but it does not match the host name, connection is refused.
- Strong Cipher Suites Only. When checked, this field specifies that the minimum strength of the cipher suites used can be specified with the bw.plugin.security.strongcipher.minstrength custom engine property. Default value of the property disables cipher suites with an effective key length below 128 bits. When this field is unchecked, only cipher suites with an effective key length of up to 128 bits can be used.
HTTP Connection
- Requires Client Authentication. Checking this field requires initiators to present their digital certificate before connecting to the HTTP server. When this field is checked , the Trusted Certificates folder becomes enabled so that a location containing the list of trusted certificates can be specified.
- Identity.Identity resource that contains the client digital certificate and a private key.Optional
- Verify Host Name. Specifies to check that the host name of the HTTP server against the host name listed in the server’s digital certificate. If it does not match, the connection is refused. If a hostname equivalent is specified in the Host field, but it does not match the host name, connection is refused.
- Strong Cipher Suites Only. When checked, this field specifies that the minimum strength of the cipher suites used can be specified with the bw.plugin.security.strongcipher.minstrength custom engine property. Default value of the property disables cipher suites with an effective key length below 128 bits. When this field is unchecked, only cipher suites with an effective key length of up to 128 bits can be used.
JMS Connection
Basic tab
-Trusted Certificates folder. Folder in the project containing one or more trusted certificates. This folder is checked when an JMS activity connects to ensure that the responder’s certificate is from a trusted authority. This prevents connections to rogue servers.
- Identity.Identity resource that contains the client digital certificate and a private key.Optional
Advanced tab.
- Trace. Specifies whether SSL tracing should be enabled during the connection.
- Debug Trace. Specifies whether SSL debug tracing should be enabled during the connection
- Verify Host Name. Specifies to check that the host name of the HTTP server against the host name listed in the server’s digital certificate. If it does not match, the connection is refused. If a hostname equivalent is specified in the Host field, but it does not match the host name, connection is refused. Note: The default context factories for TIBCO EMS automatically determines if host name verification is necessary. If custom implementation of the context factories is used, custom implementation must explicitly set the verify host property to the correct value.
- Expected Host Name. This name provided in this field must match the name in the responder’s certificate.
- Strong Cipher Suites Only. When checked, this field specifies that the minimum strength of the cipher suites used can be specified with the bw.plugin.security.strongcipher.minstrength custom engine property. Default value of the property disables cipher suites with an effective key length below 128 bits. When this field is unchecked, only cipher suites with an effective key length of up to 128 bits can be used.
Rendezvous Connection
- Daemon Certificate. Folder in the project containing one or more trusted certificates. This folder is checked when connecting to a daemon that is trusted. This prevents connections to rogue servers. A daemon’s certificate can be retrieved using the administration interface in TIBCO Rendezvous. Once retrieved, a folder in the project can be selected to import this certificate in the folder using the Tools > Trusted Certificates > Import into PEM Format menu item.
- Identity. An Identity resource used to authenticate to the TIBCO Rendezvous daemon. The Browse button allows to select from a list of appropriately configured Identity resources. Only Identity resources whose Type field is set to Identity file or Username/Password are listed.

- A process definition can be packaged into a custom activity that hides the implementation details of the process from the user. Custom process starters can also be created.
- Custom activities can appear in a custom palette.
- Process definitions referenced by a custom activity are referenced by name. A convention that ensures uniqueness of process definition names should be developed in order to avoid naming conflicts.
- Start activity for a process definition can optionally specify an input schema.
- Only process definition that do not have a process starters can be referenced by a custom activity.
- Global variables used within the process definitions referenced by custom activities are automatically added to the clobal variable list of the project when the activity is added to a process definition. Thus a naming convention for Global variables should be specified.
- WSDL or XSD files are not automtically included when the process definition is placed in a custom activity. WSDL and XSD files must be made available to any user of custom activity.
- Creating a custom activity.
1. Create a folder (uniquely named is strongly recommended)
2. Create a process definition
3. Optionally, create output schema to the process definition Start activity.
4. Implement business logic for process definition.
5. Optionally, specify input schema for the End activity in the process definition and mapping
6. In the project panel, click on the root node of the project, then select the General Activity palette in the palette panel.
7. Create a Custom Activity resource
8. Specify a name and an custom icon
9. Click on Browse button to select the process definition
10. Click Apply
- Any resources referenced by the process definition in a custom activity are automatically included in the custom activity. Dynamically called subprocesses are not known at design time, and therefore are not referenced by the process definition. Therefore, dynamically called subprocesses cannot be used by a process definition within a custom activity.
- Creating a Custom palette with Custom activities.
1. Create a Custom palette
a) Select Palettes > My Palettes > New Palette from TIBCO Designer menu.
b) Specify a nam in the dialog that appears
c) Custom palette appears in palette panel.
2. Drag and drop custom activity to custom palette.
3. Save the project
- Distributing custom palette
1. Locate the file(s) containing the custom palette(s) which, by default, are stored in the location specified in the User Palette Directory foeld of the General User Preferences dialog. The file extension of the custom palette is .mypalette.
2. Copy the .mypalette file to the custom palette directory on the machines to use the custome palette. An installation program may be created to perform this step so that users can easily install the custom palettes.
3. Start TIBCO Designer and click the MyPalettes tab to see the custom palette. If TIBCO Designer is already running, click on Palettes > My Palettes > Reload Palettes from the menu to retrieve the new custom palette.
- Custom activities behave like any other activity in TIBCO ActiveMatrix BusinessWorks. The name of the Custom Activity and the name of the process definition in which the Custom Activity is included should be unique. If names are the same, input and output schemas are not displayed.
- Global Variables used in Custom Activity are automatically added to the Global Variable list in the project (if they are not included yet).
- When tracing is enabled, the trace information for activities executing within a custom activity is written to a log file.
- The Java Event Source process starter allows to create a custom process starter based on Java code.
- Java Event Source provides the features (such as Sequencing key) of other process starters without the need to write extra code.
- Java Event Source provides an abstract class to extend to create a process starter. The abstract class describes the methods that interact with the process engine. Custom code must provide implementation for the methods,
- init(). Called when the process engine starts. Can initialize any resource connections. Specify a Java Global instance on the Advanced tab that initializes resource connections. Java Global instances are loaded and initialized during process engine start up. this.getJavaGlobalInstance() can be executed to obtain the Java Global Instance resource in process starter code.
- onStart(). Called by the process engine to activate the process starter. This method must activate any event notifier or resource observer code. The notifier or observer code can then call the onEvent() method to start a process instance.
- onStop(). Called by the process engine to deactivate the process starter. This method must deactivate any event notifier or resource observer code.
- onShutdown(). Called by the process engine when the engine shuts down. The method should release any resources and resource connections and perform any required clean up operations.
- Methods already implemented.
- onEvent(Object object). Called when a listener or resource observer catches a new event. Input to this is a Java object containing the event data.
- getGlobalInstance(). Returns an object reference to the Java Global resource specified on the Advanced tab of the process starter. Useful when initialization code is placed in a Java Global Resource instead of the init() method.
- onError(). Throws the exception specified in the input parameter. Used to propagate an error to the TIBCO ActiveMatrix BusinessWorks process instance when a listener or resource observer fails to generate an event.

- TIBCO ActiveMatrix BusinessWorks provides a testing environment for stepping through a process model and determining the sources of errors. Entering the testing environment starts a TIBCO ActiveMatrix BusinessWorks engine. The engine starts process instances based on the process definitions stored in the project. One running process instance can be selected in order to display in the design panel and the currently executed activity is highlighted as the process instance runs.
- Testing a process definition,
1. Select the process definition to test from the project panel.
2. Set breakpoints in the process definition where to stop running process and examine its state.
3. Provide input data to the process if it has an input schema defined.
4. Click the Tester tab on the left of the project panel.
5. Examine the data of the process by selecting any of the activities in the process. The current state of the process is displayed on the Process Data tab of each activity.
6. Use the toolbar buttons (Pause, Step to Next Activity and so on) in the test panel to either continue through the process instance or to stop the current process instance.
- Once in testing mode, changes are not reflected in the running process instance. Return to design mode before changing process definitions.
- Breakpoints allow to suspend a running process instance at a specific point so that process data can be examined. breakpoints persist after a project is closed.
- Breakpoints should be set before or after activities execute (except for before Start and after End activities).
- A breakpoint can also occur based on a given XPath condition. In order to set a condition to the breakpoint, Set Breakpoint button must be used. To set breakpoints with no condition, select from right-click menu the Set/Clear Breakpoint Before/After options.
- When a breakpoint is set on an activity, a red octagon (a stop sign) appeards next to the task’s icon to indicate the task has a breakpoint. A breakpoint before appears to the top left of the activity. A breakpoint after the activity appears to the top right of the activity.
- When a process instance is stopped at a breakpoint, the breakpoint becomes a stop sign inside a triangle (rombo) to indicate where the process instance has stopped.
- The Start Testing Vioewed Process button allows to create a process instance for the currently viewed process definition and all of its dependent subprocesses. Othe process definition can also be selected to load.
- If the loaded process begins with a Start activity that requires input, input to the process starter can be supplied by clicking on the Supply input Data to Starter button on the TIBCO Designer toolbar. This button is not required for processes that do not require input data on the Start activity.
- Once the Start testing Viewed Process button is clicked, the Select Processes to Load dialog appears. Process Definitions to load into the test engine can be selected in this dialog.
- The Advanced button on this dialog allows to specify any arguments to use when starting the test engine. This is useful when using custom engine properties. A database to use for storage of process engine information can also be specified. The Test Engine Database field specifies the JDBC Connection resource to the database to use.
- If the loaded process begins with a Start activity, one process instance is created to execute the process definition. Processing continues until the End activity is reached. If the loaded process begins with a process starter, the process engine waits for an incoming event before creating a process instance. Each incoming event causes a process instance to be created, and each process instance is listed in the test panel.
- New process of any loaded process instances can be created using the Create a Job button. The process instance can also be created by selecting in the right-click menu the option Create a Job.
- Each process instance is independent in the test panel. Each process instance can be started, stopped, stepped through individually. When a process instance is running, its description is (running) in the test panel. Once a process instance completes its processing (End activity is reached), its description is changed to (completed job) in the test panel. If a process instance fails to complete, its description is charged to (failed). Any running, completed or failed job can be viewed.
- Execution of a process instance can be stopped by selecting it and clicking the Stop the Current Job button in the test panel.
- Any completed or failed process instances can be deleted from the test panel by selecting it and clicking the Delete a Completed Job button.
-Changes performed during testing will not take effect during current testing session.
- Colors in test mode
- Black transition arrow. Transition not evaluated yet
- Green transition arrow. Transition evaluated and condition evaluated to true
- Red transition arrow. Transition evaluated and condition evaluated to false.
- Red activity. The activity encountered an error while processing.
- Bright yellow activity. Process definition is paused at this activity (Breakpoint or Step to Next Activity or Run To This Resource). Activity has not been executed yet, but it is the next activity to execute when process instance continues
- Yellow activity. Activity is currently executing, but the focus is not on the activity. This can occur if there are many paths in process definition and focus is not on the current path.
- Toolbar icons for testing (Also available by View > Test Options)
- Set Breakpoints. Brings up the Set Breakpoint dialog that allows to specify which activities should have breakpoints
- Add Input Data. Allows to specify data for the process starter’s input schema. Only enabled for process that start with a Start activity and it has an input schema.
- Test Mode. Information icon displayed when a process engine has been started for testing process definitions.
- Go To Started Process. This item is only available on the View > Test menu and displays the process definition that began this testing session.
- Moving Ball Options. Brings up a dialog that allows to set whether the moving ball is displayed. Moving ball shows the current execution path. Speed of the moving ball can also be set.
- Test panel icons.
- Start. Allows to load the viewed process and select any other processes to load. All dependent subprocesses for any loaded processes are also loaded. The process definitions are loaded into a process engine.
- Resume. Resumes any process instances that are paused or stopped at a breakpoint.
- Stop. Kills the current engine and exits testing mode. All process instances are removed from the test panel. In some situations, this button might not stop the process immediately because TIBCO ActiveMatrixmight be waiting for the current operation to be completed.
- Pause. Temporarily suspends the process instance. Resume the process instance with the Resume button.
- Step Over. When a process is paused on an activity, click this icon to step ahead in the process definition and execute the next activity.
- Step Into. Once a Call Process activity is reached, this icon allows to display the process definition of the called process and step through it. Only available when Call Process is the next activity to be processed.
- Step Out. After stepping into a subprocess, this toolbar icon can be used to return to the process that called the subprocess. Only available when in a subprocess.
- Show Current Job Location. When a process instance is paused at a breakpoint or any other point, focus can be changed to display or edit other resources in project. This icon and menu item allows to return focus to the process definition for the currently running process instance. Focus returns to the highlighted activity in a process where the process instance is paused.
- Delete. Deletes the selected jobs marked as (completed job) from the test panel. Only completed jobs can be deleted.
- Create Job. Creates a New Process Instance for the selected process definition.
- Stop Current Job. Stops currently executing process instance, but does not exit test mode. This is useful to examine the data of the process instance but not want to continue running the process
- Run To This Resource. Menu item that executes the running process instance up to the selected activity.

- TIBCO Designer allows to create alias to resources that are to be reused in other projects. Alias are used in two resources,
- AliasLibrary. Allows to specify aliases to files stored in the file system into the project. Before including a file, an Alias is created that specifies the file’s location. An alias is part of the preferences and is common to all of the projects. Aliases are created and managed under the File Alias tab in the Preferences dialog.
- LibraryBuilder. Allows to build a design-time library that includes resources defined in one project that can be shared with other projects. A LibraryBuilder resource can be maintained using a revision control system or placed in a shared directory. If the LibraryBuilder is to be shared by many project developers, the resource should be managed in a revision control system where users can sync regularly to get updates. In a smaller environment, LibraryBuilder resource can be placed in a shared folder.
- If the LibraryBuilder resource changes, the resource must be reloaded into project. The best practice is to minimize changes to the resource. It should be built and tested, then updated infrequently.
- Designer uses aliases to specify libraries locations as projects are exported or deployed to different machines and different environments. Before using a library, an alias is created that specifies its location.
- When an EAR file from a project containing a LibraryBuilder is created, all resources renferenced in LibraryBuilder resource are included in the archive, just as resources in local project are included.
- Creating an Alias. After creating an alias, it can be used in AliasLibrary or LibraryBuilder.
1. Click Edit > Preferences
2. Click File Aliases tab
3. Click New
4. Under the Alias column, double-click and provide an alias name.
5. Under the File Path column, double-click and navigate to the design-time library location. Select the file name and click Open.
6. Click OK.
- Exporting an Alias.
1. Click Edit > Preferences
2. Click the File Aliases tab
3. Click Export to save the alias list so others can use it.
4. Navigate to a location that others can access.
5. Provide a name for the alias.
6. Click Save.
- Importing an Alias.
1. Click Edit > Preferences
2. Click the File Aliases tab
3. Click Import to add a previously exported alias list to your preferences.
4. Navigate to the location of the alias file and select it.
5. Click Open.
6. Click OK.
- Resources in the project can reference aliases in the AliasLibrary to resolve external file dependencies that they may have at runtime or debug time.
- When an EAR file is built, the files referenced by the aliases defined in an AliasLibrary included in the project, are included in the EAR file.
- Creating an AliasLibrary
1. Select the top level folder and locate the AliasLibrary resource (General palette)
2. Drag the AliasLibrary resource into the design panel
3. Under Configuration tab, provide a name and description for the AliasLibrary
4. Click the Aliases tab and add files or directories to the list of aliases. The dialog allows to choose a Folder or All Files. If a folder is selected, all files in the folder become part of the alias as well as any other sub folders. A warning appears if the selected folder or files exceed a certain size. The warning can be customized. Deleting aliases from Alias tab, does not remove the alias from Edit > Preferences alias tab.
5. Whether aliases within AliasLibrary should be included in the CLASSPATH can be specified. This may be required for a TIBCO ActiveMatrix BusinessWorks Java Activity that loads a jar file in order to find its executable or its supporting code.
6. Click Apply.
- Creating a LibraryBuilder resource.
1. Select the top-level folder and locate the LibraryBuilder resource (General palette)
2. Drag the LibraryBuild resource into the design panel.
3. Under the Configuration tab, provide a name for the LibraryBuilder resource.
4. In the File Location field, provide the absolute path and name for the library file. The directory should be accessible by other developers.
5. Click the Resources tab and click the browse icon to select resources to add to the LibraryBuilder. The list can be limited to resources matching a filter term entered in the Filter Name field.
6. Click Apply
7. Click Build Library.
- A LibraryBuilder resource is the basis for a design-time library. Before creating a design-time library, access to a LibraryBuilder resource alias is required.
- Aliases are used to manage access to LibraryBuilder resources.
- When a LibraryBuilder resource is imported to a project, an alias to it can be created when loading the library , or pick an alias and load the corresponding library.
- If working from a different machine, or are not the user who created the alias, an alias can be imported to the alias list.
- Click New when adding a LibraryBuilder resource allows to define an alias and load the LibraryBuilder resource in one operation. The alias is then added to the list.
- To update a LibraryBuilder resources, delete the alias to it, then add it back.
- To delete a LibraryBuilder resource from a project, delete the alias to it.
- Creating a design-time library
1. Open the project to which the LibraryBuilder will be added.
2. Click Project > Save
3. Select the project’s root folder
4. Click the Design Time Libraries tab
5. Click Pick if there is an alias defined for the library. Click New and navigate to the location of the design-time library. After clicking Apply, a new alias for the library is added to alias list.
6. Click OK
7. Click Apply
- Updating a Design-time Library
1. Open the project in which the design-time library will be updated
2. Select the project’s root folder
3. Select the Design Time Libraries tab
4. Select the File Alias for the design-time library to update.
5. Click Delete
6. Click Apply
7. Click Pick.
8. Select the file alias for the design time library to update
9. Click OK
10. Click Apply.
- Deleting a Design-time library
1. Open the project in which the design-time library will be deleted.
2. Select the project’s root folder.
3. Click the Design Time Libraries tab
4. Select the File Aliases for the design-time library to remove.
5. Click Delete
6. Click Apply.
- When a LibraryBuilder resource is added to a project, the resources defined in it, can be used. The resources deisplay in the project view like other resources but, they cannot be modified, they are greyed out and not editable.
- Design-time libraries added to a project can be hidden. When design-time libraries are hidden, resources in the libraries are not available to a project. If a resource in design-time library is used and have hidden the library, when an EAR file is built, the resource will not be part of the archive.
- Hide/Show Design-time Libraries
- Click Project > Hide Library Resources
- Click Project > Show Library Resources
- If there is a name conflict, the resource in the local project is always used. If there is a name conflict among the design-time libraries loaded, there are these choices,
- Use arrows on the left to reorder the libraries. Libraries are ordered according to when they were imported. The earliest imported library is at top of the list. The library at the top of the list has precedence over those in the list.
- If reordering does not resolve the conflict, design-time library can be re-built or create another one.
- A resource cannot be renamed in a desgin-time library to break a conflict.
- Each resource with a conflict is marked so can easily be seen

- For multiple developers to work in the same project, it can be used file sharing/locking or a revision control system (multi-file project). Changes from User A don’t show up or User B until User B syncs.
- TIBCO Designer creates a file that can be shared and locked for each top-level resource, such as an adapter configuration or process definition. It does not create a file for each resource. TIBCO Designer also creates folder for folders created in the project. Each folder can be locked as needed.
- Revision control options are available
- File Sharing. In Windows, project located in a folder accessible by all TIBCO developers (r+w access). In UNIX, the project must be located on a mounted drive accessible by all TIBCO developers.
1. Create a Unix group for the TIBCO developers
2. Create a Unix account for each developer. Each account must have its Primary Group ID set to the group “tibdev”.
3. For each account, the umask must be set to 002 to ensure the entire group has write permission on resources (folder and file) in Designer projects. Set the umask in the .login or .profile file.
- Microsoft Visual SourceSafe. Not supported under UNIX.
1. Instal Microsoft VSS 6.0 Client on each machine from which to use TIBCO Designer in conjunction with a VSS database.
2. To make the VSS database available, set the ssdir environment variable to the location of the VSS database (containingthe Srcsafe.ini).
- Perforce. Perforce has comprehensive software configuration management capabilities built around a scalable client/server architecture. Perforce Server must be installed and running. Perforce client must be installed on machine where TIBCO Designer runs.
- XML Canon. XML Canon/Developer (XCD) is a comprenhensive development platform that allows organizations to store their XML assets in a central repository that facilitates adaptability, collaboration and management. XML Canon is a persistence system that has some RCS capability but not a multi-file project per se.
- Clearcase. Tracks the file versions used to build a product release and helps to organize the work of groups of engineers.
- CVS. Version Control System that records the history of source files used to build a software product. CVS also allows engineers to work in their own directory, and merges each engineer’s work into a source tree.
- PVCS. PVCS allows developers to manage software development by controling access and revisions to source code. It automates and simplifies access to development objects including source code, ASCII files, graphics, documentation and binary data files, allowing developers to share archive information and manage projects, even in cross-platform development environments.
- TIBCO Designer allows interaction with revision control system to check who owns the lock for each locked resource.
- Icons Used by RCS Projects.
- A lock icon indicates that the resource was checked into the revision control system. Other users might be making changes. Checking out the resource is required to safely make changes.
- A yellow square icon indicates that the RCS does not know about this resource or its state. If the resource is new, it has to be added to the RCS. If it has been checked in before, it has to be checked in again.
- A red square indicates, on systems that support that functionality, that another user has locked the resource.
- If no special icon is displayed, the resource has been checked out and is in the same state as the corresponding RCS resource.
- Deleting RCS projects
1. In the startup panel, click the Delete project button
2. In the Delete Project dialog that appears, supply the information about the project.
- For projects that use File Sharing, use either the None or File Sharing Revision Control System and any user name, supply the project location.
- For Visual SourceSafe and Perforce make sure that the project listed in the Project Directory field corresponds to the project checked into RCS.
3. Click OK.
- To acquire a resource Multi-User > Acquire-Checkout Resource
- To release a resource Multi-User > Release-Revert Resource
- Global Variables are acquired through the Acquire-Check out Global Variable group option of the right-button menu.

Archivo del blog

lunes, 17 de octubre de 2011

TIBCO BW Administration (1-3)

miércoles, 5 de octubre de 2011

TIBCO BW Process Design Guide (3 - 3)