Software Release 3.3.1 July 2017
Document Update: August 2017
SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.
USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE FILE) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THE
SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.
This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written
authorization of TIBCO Software Inc.
TIBCO and Two-Second Advantage are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries.
Enterprise Java Beans (EJB), Java Platform Enterprise Edition (Java EE), Java 2 Platform Enterprise Edition (J2EE), and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle Corporation in the U.S. and other countries.
All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.
THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.
THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.
THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.
THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE,
INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.
Copyright © 2010-2017 TIBCO Software Inc. All rights reserved.
TIBCO Software Inc. Confidential Information
TIBCO Documentation and Support Services. . . .4
New Features. . . .6
Changes in Functionality. . . .13
Deprecated and Removed Features . . . .14
Migration and Compatibility. . . .15
Closed Issues. . . .16
Known Issues . . . .96
Documentation for this and other TIBCO products is available on the TIBCO Documentation site. This site is updated more frequently than any documentation that might be included with the product. To ensure that you are accessing the latest available help topics, visit:
https://docs.tibco.com
Product-Specific Documentation
Documentation for TIBCO products is not bundled with the software. Instead, it is available on the TIBCO Documentation site.
The following documents form the documentation set:
● Concepts: Read this manual before reading any other manual in the documentation set. This manual describes terminology and concepts of the platform. The other manuals in the documentation set assume you are familiar with the information in this manual.
● Development Tutorials: Read this manual for a step-by-step introduction to the process of creating, packaging, and running composites in TIBCO Business Studio.
● Composite Development: Read this manual to learn how to develop and package composites.
● Java Component Development: Read this manual to learn how to configure and implement Java components.
● Mediation Component Development : Read this manual to learn how to configure and implement Mediation components.
● Mediation API Reference : Read this manual to learn how to develop custom Mediation tasks.
● Spring Component Development : Read this manual to learn how to configure and implement Spring components.
● WebApp Component Development : Read this manual to learn how to configure and implement Web Application components.
● REST Binding Development: Read this manual to learn how to configure and implement REST components.
● Administration Tutorial: Read this manual for a step-by-step introduction to the process of creating and starting the runtime version of the product, starting TIBCO ActiveMatrix servers, and deploying applications to the runtime.
● Administration: Read this manual to learn how to manage the runtime and deploy and manage applications.
● Hawk ActiveMatrix Plug-in User’s Guide: Read this manual to learn about the Hawk plug-in and its optional configurations.
● Error Codes: Read this manual to know more about the error messages and how you could use them to troubleshoot a problem.
● Installation and Configuration: Read this manual to learn how to install and configure the software.
● Release Notes: Read this manual for a list of new and changed features, steps for migrating from a previous release, and lists of known issues and closed issues for the release.
How to Contact TIBCO Support
For comments or problems with this manual or the software it addresses, contact TIBCO Support:
● For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this site:
● If you already have a valid maintenance or support contract, visit this site:
https://support.tibco.com
Entry to this site requires a user name and password. If you do not have a user name, you can request one.
How to Join TIBCO Community
TIBCO Community is an online destination for TIBCO customers, partners, and resident experts. It is a place to share and access the collective experience of the TIBCO community. TIBCO Community offers forums, blogs, and access to a variety of resources including product wikis that provide in-depth information, white papers, and video tutorials. In addition, users can submit and vote on feature requests via the Ideas portal. For a free registration, go to https://community.tibco.com.
The following new features have been added in this release.
Jetty Upgrade
Starting with this release, for HTTP Connector Resource Templates, the Jetty version has been upgraded from 6.1.26 to 9.2.15. The Servlet version (javax.servlet) has been upgraded from 2.0 to 3.1.
For more information, refer to the "Changes in HTTP Connector for Jetty 9" section in the TIBCO ActiveMatrix® Service Grid Administration Guide.
New TIBCO Business Studio Version
TIBCO ActiveMatrix 3.3.1 now supports Eclipse 4.4.1. For more information, refer to the "Using TIBCO Business Studio" section in the TIBCO ActiveMatrix® Service Grid Installation and Configuration Guide.
You can now find out the version of TIBCO Business Studio using which a project was created. This information is stored in a hidden .version file which is added to the SOA and Java implementation project folders. This file contains important information about the project, such as timestamp, Studio version, and Eclipse Platform version of creation or modification.
When the user generates the Administrator CLI script for a DAA using the new Studio, a new attribute called propertyType is added to each <Property> element in the
<projectName>.deployment-config.xml file.
TIBCO ActiveMatrix Business Studio also supports adding of Features by extending the Target Platform. As a result, the Debugger can now provision features from the extended Target Platform. A Target Platform can be added or modified using the Windows > Preferences > Plug-in Development >
Target Platform page.
Java 8 Support for TIBCO ActiveMatrix Runtime and Business Studio
Starting TIBCO ActiveMatrix 3.3.1, Java 8 is supported out-of-the-box for both the Runtime, and the Studio. In case of Studio, users can import existing projects created using prior ActiveMatrix Business Studio versions, into the new Studio, and update them to use Java 8 language features. Users can also create new Java Implementation Type (IT) components that avail the Java 8 language feature set.
For more information, refer to the "Upgrading ActiveMatrix Business Studio" section in the TIBCO ActiveMatrix® Service Grid Installation and Configuration Guide.
Host Manager
TIBCO Host Manager now offers new commands to manage TIBCO Runtime Hosts and Nodes in large scale Enterprises. The commands allow the user to start and stop Hosts, and the Nodes managed by them, in various modes.
For more information, refer to the "Host Manager" section in the TIBCO ActiveMatrix® Service Grid Installation and Configuration Guide.
Product/Robust Upgrade
You can now use the new TIBCO Configuration Tool (TCT)-based approach for Upgrading your existing configuration to ActiveMatrix 3.3.1 and Downgrading from ActiveMatrix 3.3.1 to prior ActiveMatrix versions, in a robust and seamless manner. For details on what the Upgrade/Downgrade entails, refer to the "Upgrade and Downgrade" section of the TIBCO ActiveMatrix® Service Grid
Installation and Configuration Guide.
REST Binding Type (BT) is now a first-class citizen of TIBCO ActiveMatrix, that is, REST Bindings can be added in TIBCO Business Studio 3.3.1 and deployed in TIBCO ActiveMatrix Administrator without any additional changes.
Host Lifecycle Management
TIBCO ActiveMatrix Administrator now allows lifecycle management of TIBCO Host instances on remote machines via Administrator. This includes the ability to create, edit, install, start, stop, uninstall and delete TIBCO Host instances.
To use this lifecycle management, you need at least one pre-created TIBCO Host instance on a remote machine that is registered with TIBCO ActiveMatrix Administrator (done via TIBCO Configuration Tool). Then, using this instance, TIBCO ActiveMatrix Administrator can create additional TIBCO Host instances on the remote machine and can perform lifecycle operations.
For details, refer to the "Managing Hosts" section in TIBCO ActiveMatrix® Service Grid Administration Guide
Assessing the Health of Applications
Using TIBCO ActiveMatrix, you can now assess the health of applications in terms of their back-end Services and Shared Resource instances. With this feature, you need not configure a dedicated operation to perform a Health Check, which would require modifying the contract on each Service and Reference.
The Health Check request is invoked on a Service endpoint. The status of the participating Services, References, and Shared Resources is returned in a response.
Health Check includes:
● Status Reporting for Failure Scenarios (example: Health Check Not Supported, EMS Connectivity Issues, and so on.)
● Health Check Specific logging
● Health Check Timeout at global and and granular level
● Caching Health Check Response
● Custom Health Check Operation via Annotations.
TIBCO ActiveMatrix also supports creation of annotated Health Check methods for Java Implementation Type, which can be executed during a Health Check Invocation to provide a customized Health Check Response. Additionally, TIBCO ActiveMatrix Platform also supports Health Check for the SOAP/JMS Binding Type
● Ability to Ping SOAP/HTTP and SOAP/JMS Endpoints
Health Check is supported out-of-the-box on the following Component types:
● Binding Types (BTs): SOAP/HTTP and SOAP/JMS, for SOAP Versions 1.1 and 1.2.
● Implementation Types (ITs): TIBCO ActiveMatrix® BPM (BPM), TIBCO ActiveMatrix
BusinessWorks™ Service Engine (BWSE), Java, Mediation and Spring. Note that only ProcessFlow components from BPM application are applicable for Health Check.
● Shared Resources (RTs): JDBC, JMS Connection/Destination
For more information, refer to the "Service Health Check" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
TIBCO ActiveMatrix now supports Enterprise Deployment Health Check to help you assess the overall health of an Enterprise, with a focus on the TIBCO ActiveMatrix Administrator. With this feature, you can gather comprehensive metadata and runtime configuration information of the ActiveMatrix Administrator at various levels (to include Hosts, Nodes, Environments), carry out real- time test deployments, and review all the collected information in a comprehensive report, to better equip yourself in making decisions about substantial upcoming deployments. For more information, refer to the "Enterprise Deployment Health Check" sub-section of the "Using Diagnostics" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
Exporting and Importing Configuration Data
You can now export and import configuration data from TIBCO ActiveMatrix Administrator using TIBCO ActiveMatrix Administrator.
You can export ActiveMatrix objects such as Environments, Nodes, Applications, and Resource Templates to CLI scripts. The CLI scripts can be modified as needed and then executed using ANT on the same or a different ActiveMatrix Enterprise. This recreates the objects based on the exported archive. You can export data using the Administrator UI (by navigating to Admin Configuration >
Admin Server > General tab and clicking Export Wizard) or using the Administrator CLI with the provided ANT task. For more details, refer to "Export and Import" section in TIBCO ActiveMatrix® Service Grid Administration Guide .
Uninstalling Features using Wildcards
Using the TIBCO ActiveMatrix Administrator CLI, you can now uninstall (mark for uninstall) or disable a feature from a Node by specifying the version as a wildcard (*). For example, specifying a version of 1.0.* uninstalls (marks for uninstall) all features whose version starts with 1.0.
Optimization for Large Scale Environments
The following areas have been optimized for large scale Environments:
● Optimization in notification processing when supporting large number of Hosts and Nodes within an Enterprise
● Optimization in ActiveMatrix Administrator UI to reduce the time it takes to load
● Optimization of ActiveMatrix Administrator CLI to include timeouts to terminate long-running CLI tasks in large scale setups
● Optimizations in updating Notification Transport, Server Configuration, and internal HTTP Connector Configuration
● Ability to View and Download the TRA File of a Host or Node using TIBCO ActiveMatrix Administrator UI
● Ability to create and manage remote TIBCO Hosts
● Ability to manage and update a Host's and Node's JVM arguments
● Optimization in HKAM to reduce the memory usage Editing the Notification Transport Server Configuration
This release provides a more stable approach for updating the Notification Transport Server
Configuration, especially when updating large scale setups. At present, this approach is available only through the TIBCO ActiveMatrix Administrator CLI.
For details, refer to the "Editing the Notification Transport Server Configuration using the CLI" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
Updating Internal HTTP Connector Configuration
The ActiveMatrix Administrator CLI now provides a more stable approach for updating an internal HTTP connector, particularly for a large scale setup. For details, refer to the "Updating Internal HTTP Connector Configuration" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
Reconnecting to the Notification Server
You can now reconnect to the Notification Transport server using ActiveMatrix Administrator UI and CLI. Reconnecting to the Notification Server involves recreating all the connections from ActiveMatrix Administrator to the Notification Server and refreshes the status of all entities.
This feature can be used to fix inconsistent status of ActiveMatrix Administrator and Runtime, and lost status of task execution. For details, refer to the "Reconnecting to EMS" section in the TIBCO ActiveMatrix® Service Grid Administration Guide.
Monitoring Enterprise Status
Using TIBCO ActiveMatrix Administrator, you can now check the status of all TIBCO ActiveMatrix entities (Nodes, Hosts, Applications, and Resource Instances, and the Enterprise) from a single page.
To access this page, open ActiveMatrix Administrator UI and navigate to Infrastructure > Enterprise Status.
For details, refer to the "Monitoring the Status of Entities from a Single Page" section in the TIBCO ActiveMatrix® Service Grid Administration Guide.
List of Plugins in Software Management Feature Tab
A list of plugins for each feature version is now listed in the Feature List. You can see the plugin list under Infrastructure> Software Management > Features tab in TIBCO ActiveMatrix Administrator UI.
Date Display for Features
The date display for node features listed in Feature List for each node in TIBCO Administrator UI under Infrastructure > Nodes > Configuration > Feature tab has changed. New columns (Modified On, Modified By, Deployed On, and Deployed By) have been added to the Node > Configuration >
Features screen.
Viewing and Managing DAA Files
In TIBCO ActiveMatrix Administrator, a new tab under Infrastructure > Software Management enables you to view and manage DAA files. In addition, you can also download DAA files. These capabilities are available through the Administrator GUI as well as CLI.
Optimizing the time taken to load Administrator UI Host Screen
The Infrastructure > Hosts screen now includes a drop down for machine names. If there are more than 10 hosts, you need to select a machine from the Machine drop down. On a large scale setup, this optimizes the time taken to load the screen. The drop down lists the Hosts as follows:
● All : Displays all the Hosts in the enterprise
● Not Installed : Displays all the Hosts which have been created but not installed yet.
● <machinename> : Displays all the Hosts on the selected machine.
Downloading the TRA File of a Host or Node
ActiveMatrix Service Grid Administration Guide.
Restarting a Host or Node
For large deployments, you might need to change the configuration of a Host/Node frequently and then restart the Host/Node to make sure the changes are reflected in the Administrator. You can now restart a Host or Node using the ActiveMatrix Administrator GUI or CLI and easily apply all the changes related to the Host or Node. For details, refer to the "Restarting a TIBCO Host" and
"Restarting a Node" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
Appending the Host Name to the Executable Process
TIBCO ActiveMatrix Administrator now allows appending of the TIBCO Host instance name to the tibcohost executable process. For details, refer to the " Monitoring the Status of Entities from a Single Page" section in the TIBCO ActiveMatrix® Service Grid Installation and Configuration Guide.
Updating the JVM Configuration of a Host and Node
You can modify JVM and all user-specific/Java properties for Hosts and Nodes using the ActiveMatrix Administrator UI or CLI. For details, refer to the "Updating the JVM Configuration of a Host" section in the TIBCO ActiveMatrix® Service Grid Administration Guide.
Creating Multiple Nodes with the Same Name
TIBCO ActiveMatrix Administrator now allows creation of two or more Nodes with the same name on a single TIBCO Host instance, where the Nodes belong to different environments. For details, refer to the "Creating Multiple Nodes with the Same Name" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
"Stand By" State of HTTP Connector
The behavior of HTTP Connector has been enhanced to work better with an external HTTP load balancer. An HTTP Connector stops listening to client connections when there are no service
endpoints or applications available to serve the requests. In other words, if all the applications using an HTTP Connector are stopped (or undeployed), the HTTP Connector also stops. For this case, an external HTTP load balancer can detect the unavailability of the endpoint, mark it as offline, and stop routing requests to it. When applications are started, the HTTP connector automatically starts
listening on its port, such that the external HTTP load balancer can detect the endpoint as online and start routing requests to it. The 'Stand By' state for HTTP Connectors represents the stopped state.
Upon installation, an HTTP Connector appears in the 'Stand By' state. When the first Application using the HTTP Connector starts up, the HTTP Connector changes the state to the 'Running' state.
When the last Application using the HTTP Connector is stopped, the HTTP Connector goes back to the 'Stand By' state.
For details, refer to the "Runtime States" section in the TIBCO ActiveMatrix® Service Grid Administration Guide.
Graceful Node Shutdown
When a shutdown operation is executed on a TIBCO ActiveMatrix Runtime Node, the Node stops gracefully. Nodes can be shutdown gracefully from the ActiveMatrix Administrator UI or CLI. For details, refer to the "Graceful Node Shutdown" section in TIBCO ActiveMatrix® Service Grid
Administration Guide.
Threading Policy
You can now update Threading Policy timeout values during or after deployment time. The timeout values must be specified in milliseconds.
the node’s TRA file for the node on which the application is deployed. For details, refer to the
"Threading Policy" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
Copying PFU (Preparing for Undeploy) Components across BPM Nodes
Typically when the TIBCO ActiveMatrix BPM user adds a new BPM Node to existing BPM setup, the existing BPM Applications are redistributed to the newly added BPM Node, due to the symmetric nature of BPM Applications. The Components of the BPM Applications that are in the 'Preparing For Undeploy (PFU)' state, however, are not automatically redistributed.
TIBCO ActiveMatrix now provides a simplified TIBCO ActiveMatrix Administrator CLI-based solution using which Components in the 'Preparing For Undeploy (PFU)' state can be redistributed in a single, automatic step. The BPM users still have to perform the prerequisite steps of creating the new BPM Node Type and mapping the amx.bpm.app Application to the newly created BPM Node. For details, refer to the "Copying Preparing for Undeploy (PFU) Components across BPM Nodes" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
Stopping of Nodes Configured for Manual Setup
Prior to this release, when a Host was stopped, all Nodes managed by that Host were stopped irrespective of their startup mode, that is, Nodes configured for manual startup were also stopped. To prevent the stopping of Nodes configured for manual startup, a new TRA property
"com.tibco.amx.decouple.Manual.Nodes" has been introduced. This property is used during Host startup and shutdown to determine the behavior of the Nodes configured for manual startup. As a result, the lifecycle of these Nodes is decoupled from the Host lifecycle, and as a result, the Nodes do not get affected when the Host is stopped/started, and their shutdown/startup can be handled manually.
Support for "Never Virtualize" Policy
The "Never Virtualize" policy applies to Service and Reference Virtualization Bindings and ensures that the Messaging Bus is never used for delivering messages. For "Never Virtualize" policy to be applied, the communicating entities must always be on the same Node. Any policy that relies on the use of the Messaging Bus, for example, "At Least Once" policy and "Transacted One Way" policy, cannot be applied in conjunction with "Never Virtualize" policy.
Emitting 'Sender Identifier' Information
For SOAP Service Endpoints, TIBCO ActiveMatrix now emits a field from each SOAP request that identifies the Sender of the request to TIBCO ActiveMatrix Service Performance Manager (SPM). This
"Sender Identifier" field helps SPM gather statistics based on the 'Sender' of the request, for instance, the number of requests the Endpoint has received from a particular Sender.
This feature is supported for SOAP/HTTP and SOAP/JMS Endpoints, for SOAP versions 1.1 and 1.2.
For more information, refer to the "Emitting 'Sender Identifier' Information" sub-section of the "TIBCO ActiveMatrix SPM Dashboard" section in the TIBCO ActiveMatrix® Service Grid Administration Guide.
Schema Validation for SOAP Messages
You can now validate both incoming and outgoing SOAP Messages against the WSDL schema at the SOAP Binding level itself before continuing on to other ActiveMatrix Components.
This feature can be enabled from Business Studio as well as ActiveMatrix Administrator and is
supported for SOAP/HTTP and SOAP/JMS Service and Reference Bindings, for SOAP versions 1.1 and 1.2.
For more information, refer to the "Schema Validation for SOAP Messages" section in the TIBCO ActiveMatrix® Service Grid Administration Guide.
SOAP Headers can now be defined for Declared Faults, using "Message" Context Parameters in Business Studio. The Message Parts corresponding to the context parameters will be mapped to SOAP Headers at Runtime in case of Declared Faults, similar to Request and Response.
Compression Support for SOAP and REST Binding Types
SOAP over HTTP and REST over HTTP Binding Types (BT) now provide Compression Support for Request and Response Messages.
Specifying the Maximum Pool Size
In TIBCO ActiveMatrix Administrator UI, Maximum Pool Size can now be specified for a JMS Connection Factory Resource Template. The new field is available when creating a new JMS Connection Factory Resource Template. The value of Maximum Pool Size can also be updated for existing JMS Connection Factory Resource Templates.
TIBCO ActiveMatrix SPM Dashboard
The TIBCO Service Performance Manager (SPM) Dashboard, that was originally part of TIBCO SPM Server, is now available as a part of the TIBCO ActiveMatrix Platform. It can be installed through the TIBCO ActiveMatrix Installer. A new installation profile has been created to install ActiveMatrix SPM Dashboard separately.
Using the TIBCO ActiveMatrix SPM Dashboard, you can assets, view measurements, and author rules. For more information, refer to the "SPM Dashboard" section in TIBCO ActiveMatrix® Service Grid Administration Guide.
TIBCO ActiveMatrix Updater Tool for Java Runtime Environment (JRE)
The TIBCO ActiveMatrix Updater Tool for Java Runtime Environment (JRE), that was originally available as a separate installer, is now available as a part of the TIBCO ActiveMatrix installation. The tool can be used to update the JRE version of the ActiveMatrix environment.
The following are changes in functionality in this release.
Caching of Authorization Details for an HTTP Connection
Prior to 3.3.1, for an HTTP connection, authorization details were stored in the cache. Due to this, subsequent requests with invalid credentials also passed through. For example, let us say, multiple APIs were invoked sequentially. If correct crendentials were provided for the first API and wrong credentials were provided for the second API. Prior to 3.3.1, the request was passed even for the second API. This happened because, when the first API was invoked, authorization details were cached.
Starting with 3.3.1, each API invocation asks for credentials and prevents unauthorized access by returning the HTTP status 401.
Upgrading Jetty
The value of Content-Type of SOAP response is changed to "Content-Type: text/
xml;charset="UTF-8"" from "Content-Type: text/xml; charset=utf-8"
Execution Environment while Creating a Custom Mediation Task
When you create a model plug-in for a custom mediation task, the default execution environment (RequiredExecutionEnvironment field in the Manifest.MF file) is set to J2SE-1.5. In 3.3.0, this field was empty.
No features have been deprecated or removed in this release.
For instructions on how to migrate from a previous release to the current release, refer to the Installation Guide.
Product Compatibility
TIBCO ActiveMatrix 3.3.1 is compatible with the following product versions:
● TIBCO Hawk® 5.2
● TIBCO Enterprise Message Service™ 8.3.0
● Apache Ant 1.9.9
● TIBCO ActiveMatrix® Runtime UDDI Server 3.1.0
The table lists closed issues in this release.
Key Summary
AMRP-2669 The JMS Transacted One-Way Policy and Threading Policy are now compatible, provided the binding and component services run on the same node without a Virtualize Policy.
AMRP-4445 If you created and installed an HTTPConnector resource instance for a runtime node and assigned it a port that was also used as an external or internal HTTP port of SystemNode, users encountered a 404 error when attempting to log in to TIBCO ActiveMatrix Administrator after the TIBCO Host instance was restarted.
AMRP-4639 It was possible to create ActiveMatrix Administrator with SSL connections with TIBCO EMS Server, but it threw error:
"com.tibco.tibjms.admin.TibjmsAdminException: Unable to connect to server.Root cause: javax.jms.JMSSecurityException: Failed to connect via SSL to [ssl://VM-AMX-74:7234]: Received fatal alert:
bad_record_mac" in SystemNode.log.
AMRP-4732,
AMRP-3721 This applies to applications that directly use the LDAP Connection shared resource. The user application code can now leverage the connection pooling facility of the LDAP shared resource. It enables the application to close a stale LDAP connection and acquire a new and functional connection.
The pool related properties in the LDAP Connection Resource Template do not have the intended effect, and will be removed in a future release.
The connection pooling uses the underlying mechanism provided by the JRE vendor.
To use the LDAP Resource Template connection pool, modify the application code to follow the pattern in the LDAP sample application that is described in the README bundled with the sample. The sample is provided in the directory:
<TIBCO_HOME>/amx/3.3/samples/ldap.
The existing unmodified applications still work, but they do not use the connection pool.
LDAP Connection Pooling
The majority of the applications following the new coding pattern use the pool effectively without changing the default pooling configuration. The pool
properties in the LDAP Connection Resource Template do not have the intended effect, and will be removed in a future release. However, the pooling configuration can be controlled using the system-level properties that can be configured in the node TRA file as "java.property.<property-name>=<property-value>". These properties apply to all LDAP resources in the node. The list of properties is available in the Oracle JDK JNDI/LDAP Service Provider documentation at
http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi- ldap.html#POOL.
AMRP-4776 The session ID issued to a user visiting the TIBCO ActiveMatrix Administrator login page is now changed after the user is authenticated by the system.
AMRP-4780 A HTTP connector resource instance that is associated with a Thread Pool resource instance no longer fails to install. The HTTP Connector can also now be deleted from the TIBCO ActiveMatrix Administrator user interface.
AMRP-4782 XML elements are no longer intermittently lost during JAXB conversion that resulted in values being set to null in the input objects received by the Java implementation.
AMRP-4787 A node restart is no longer required to recover the in-doubt transactions
performed by the TIBCO ActiveMatrix BPM applications. Instead, the transaction manager automatically resolves in-doubt transactions every five minutes (default) while the node is running.
In-doubt transactions are caused typically when a connection to a database or TIBCO Enterprise Messaging Server (EMS) is lost intermittently. The transaction manager periodically looks for in-doubt transactions and tries to resolve them, provided the connection is restored. To change the default interval for automatic transaction recovery, add the following line to the tibamx_<node>.tra file (or add the system property for your nodes from TIBCO ActiveMatrix Administrator):
java.property.amf.node.tx.periodicrecoveryenabled=<time in minutes>
Periodic automatic transaction recovery may be disabled by setting this parameter to 0. Setting the parameter to 0 does not disable recovery on node startup.
When using Microsoft SQL Server, we strongly recommend setting a node level transaction timeout. Microsoft SQL Server does not roll back active transactions started by clients whose JDBC connection is
disconnected after beginning the transaction, but before the 'prepare' phase. Such active transactions can remain in the system indefinitely and disrupt normal TIBCO ActiveMatrix BPM functionality.
To set the overall transaction timeout on the node, add the following line to the
tibamx_<node>.tra file (or add the system property for your nodes from TIBCO ActiveMatrix Administrator):
java.property.amf.node.txtimeout=<value in seconds>
Example:
java.property.amf.node.txtimeout=600 (a 10-minute timeout)
In addition, on Microsoft SQL Server, if a large number of in-doubt transactions (50 or more) are created, it may take several recovery cycles to recover them completely.
AMRP-4793 Service request processing no longer stalls when using the virtualize and threading policies together under concurrent high load. The request processing now uses a dedicated thread pool with the same configuration as the threading policy.
AMRP-4800 The application name enrichment field (_cl.logicalCompId.matrix.application) is now correctly set in the log records of the "com.tibco.amx.messageflow" log.
AMRP-4812 This applies to TIBCO ActiveMatrix BPM. In the BPM node log files, recurring errors "unique constraint violated" reported for database table
'BRM_WORK_ITEMS' no longer occur shortly after recovering from stressed conditions such as database failures. The errors would tend to fill up the log file and looked like below (example for Oracle database):
ORA-00001: unique constraint
(BPMUSER220GAWINDOWS.PK_BRM_WORK_ITEMS) violated
The errors occurred due to improper duplicate messages delivered by TIBCO Enterprise Message Server (EMS) to a BPM node, even when another BPM node had already processed the original messages and created the work items.
To get this fix, you must use this Hotfix in conjunction with at least version 7.0.1 or a higher version of the TIBCO Enterprise Message Server (EMS) that is used for the messaging bus configuration in your BPM environment.
AMRP-4813 A specific use-case that involves a SOAP/JMS or JMS binding with a 'JMS
Transacted OneWay' policy wired to several components and managed by a single transaction is now supported. In this use-case, a transaction starts at the
SOAP/JMS binding and spans several components, and it is expected that if the transaction rolls back, the incoming messages are returned to the external JMS queue. Prior to this Hotfix, this behavior could not be guaranteed because in some cases the TIBCO ActiveMatrix runtime node would use virtualization queues to route messages. In those cases, incoming messages would be left in an internal virtualization queue, and not the external JMS queue.
A new policy called 'Never Virtualize' is introduced to guarantee the desired behavior. This policy can be added in TIBCO Business Studio to a composite, on a service/reference binding, component service or a component reference.
This policy enforces that messages between components (or between a binding and a component) are always routed via in-memory transport, and not via the virtualization queues that use the Enterprise Message Server (EMS). If the target component is not available and hence the message cannot be routed in-memory, the invocation fails with an exception. When used in conjunction with a
transaction policy, this will cause the transaction to be rolled back. As an example, suppose we have a component C1 wired to C2. When C2 is stopped, it will result in an exception, causing the invocation from C1 to C2 to fail. Without the 'Never Virtualize' policy, the message would have been routed to an internal
virtualization queue for future delivery when C2 is back up and running.
The 'Never Virtualize' policy has the opposite behavior of the 'Virtualize' policy. As such, both these policies can be used with or without a transaction policy, and both control the internal message routing.
Comparison between these policies as applied to the example of C1 wired to C2:
'Never Virtualize' policy:
● Forces the use of in-memory transport
● C1 and C2 must be co-located in the same node for this policy to be useful
● Causes C1's invocation to fail when C2 is down/absent on the same node 'Virtualize' policy:
● Forces the use of EMS-based transport using an internal virtualization queue
● Invocations work when C1 and C2 are on the same or different nodes
● Causes C1's invocation to be blocked when C2 is down/unavailable. The message is delivered later when C2 comes back up.
● Cannot be used for the above use-case since virtualized queues are always used Default (neither of the two policies declared):
● Automatically chooses whether to use in-memory routing or EMS-based routing depending on whether C2 is running or not on the same node as C1
● Cannot be used for the above use-case since virtualized queues will be used when C2 is unavailable
When the 'Never Virtualize' policy is used together with a transaction policy,
finite non-zero value. Using the default value of zero implies infinite re-delivery attempts and will cause the system redelivering messages to itself continuously and infinitely when one of the components is stopped or the transaction rolls back due to any other reason.
AMRP-4815,
AMRP-4809 The Hibernate resource adapter now includes TRACE-level logging to help users identify the area of user code where a hibernate session is repeatedly closed. Using this the unnecessary close can be removed.
AMRP-4816 The behavior of HTTP Connector has been changed to work better with an external HTTP load balancer. An HTTP Connector stops listening to client
connections when there are no service endpoints or applications available to serve the requests. In other words, if all the applications using an HTTP Connector are stopped (or undeployed), the HTTP Connector also stops. For this case, an external HTTP load balancer can detect the unavailability of the endpoint, mark it as offline, and stop routing requests to it. When applications are started, the HTTP connector automatically starts listening on its port, such that the external HTTP load balancer can detect the endpoint as online and start routing requests to it.
A new state 'Stand By' is introduced for HTTP Connectors to represent the stopped state.
Upon installation, an HTTP Connector appears in the 'Stand By' state.
When the first application using the HTTP Connector starts up, the HTTP Connector changes the state to the 'Running' state.
When the last application using the HTTP Connector is stopped, the HTTP Connector goes back to the 'Stand By' state.
Behavior for HTTP 404 when an endpoint URI is invalid:
When two or more applications share an HTTP Connector, and even if one of the applications is running, the HTTP Connector appears in the 'Running' state.
However, some of the other applications may be in the 'Stopped' state, and client requests targeted for those applications result in the HTTP error code 404 (Not Found).
Earlier, the response body accompanying the 404 code was in the HTML format and caused the parsing errors for SOAP clients that were expecting a SOAP response. With this hotfix, depending on the request type sent by the client, either a valid SOAP fault is generated, or the HTML content is returned with an error message. For example, a SOAP client trying to invoke a service at endpoint '/
myservice' receives a SOAP fault along with HTTP 404 status code when the URI '/
myservice' is not available. However, when a browser client tries to access '/
myservice', an HTML body is returned indicating that the URI was not found.
Behavior on Node restart:
When a runtime node is restarted, the HTTP Connectors are started first, and then each application starts one-by-one. With the new behavior, the HTTP Connector goes into the 'Stand By' state and as the first application starts, the HTTP Connector changes the state to the 'Running' state. While applications are still starting up, there will be a small time interval when client requests receive the 404 error as previously explained.
Reverting to the old behavior:
While the new behavior should work better in most instances, there may be a case where the old behavior is desired. You can restore the old behavior (that is, no 'Stand By' state) by adding the following line to the runtime node's TRA file and restarting the node:
java.property.com.tibco.jetty.httpconnector.eager.start=true
AMRP-4848 Previously, transactions were not committed for the combination of Global Managed Transaction policy, Threading policy, and Stateless Async policies. As a result, BPM process instances were not created for the application's upgraded version.
With this fix, the transactions for the combination mentioned above are committed and BPM instances are created for the application's upgraded version.
For example, say "version 1" of the BPM process contains an IN-ONLY service (thus configured with a Transacted One-Way Policy), and "version 2" of the BPM process contains an IN-OUT service (request and reply, thus configured with At Least Once policy).
If these steps were followed:
1. Deploy "version 1" of the process
2. Create "n" processes which will remain Active 3. Upgrade to "version 2" of the process
4. Create some more processes Then, before this fix:
At step 4, if "n" processes were created for "version 1", "n" processes for "version 2"
are not seen. This is because requests were previously being sent to both processes of "version 1" and "version 2" in a round-robin fashion. Since "version 1" and
"version 2" have different policies, the requests that went through "version 1" are never committed.
Now, with this fix:
At step 4, if "n" processes were created for "version 1", then "n" processes for
"version 2" are seen, and the transactions are committed as expected.
AMRP-4861 With this fix, generic JDBC connection properties such as defaultRowPrefetch and oracle.jdbc.ReadTimeout can now be set on an Oracle XA data source.
AMRP-4917 Applications with a SOAP/JMS promoted service binding and a JMSTransactedOneWay external policy failed during deployment.
With this fix, applications of this combination of service binding and policy are now successfully deployed.
AMRP-4959 Previously, it was not possible to Set or Override the default value of 20 for the Max Pool Size attribute of the WSS Authentication, Trust Provider and Mutual Identity Provider Resource Templates. With this enhancement, it is now possible to set the "Max Pool size" attribute via TIBCO ActiveMatrix Administrator CLI.
The sample data file ("resourcetemplate_data.xml") in the TIBCO ActiveMatrix Installation has been updated to demonstrate how the new attribute "maxPoolSize"
can be set for WSS Authentication, Trust Provider and Mutual Identity Provider Resource Templates. If a Resource Instance has already been created for the Resource Template, then the Resource Template will first have to be updated via the CLI "Edit" Action, and then the Resource Instance will have to be re-installed.
To introspect the updated Max Pool Size value after the Resource Instance has been re-installed, the "tibcohost" command can be executed with the
"describeDeployedResourcePools" option. For instance, to view the values for the WSS Authentication Resource Instances, the following command can be executed:
"tibcohost.exe describeDeployedResourcePools -nodeName myNode - resourceName java:wssAuthRI"
AMRP-4971 In TIBCO ActiveMatrix Administrator, the node naming syntax did not allow node names to begin with a digit. This restriction is now relaxed.
AMRP-5008 For certain Implementation Types connected over SOAP/HTTP or SOAP/JMS, the ActiveMatrix Message flow logger did not log response events when declared or undeclared SOAP faults were received. This issue has been fixed.
AMRP-5026 Threading policy timeout values are set in TIBCO Business Studio during application design. Per existing system behaviour, no facility was provided to modify these values during or after deployment time. A new functionality has been provided that enables certain modifications to update the timeout values. The units for timeout values must be specified in milliseconds. This is enabled through a set of modifiable system properties. The syntax for these properties is
'java.property.<prefix>.invocationTimeoutInMilliseconds'. The value of the prefix determines the granularity at which the timeout values are applied.
AMRP-5121 In case of TIBCO ActiveMatrix SOAP Reference Bindings, if multiple Message Context Parameters (in the same direction, for example: INPUT) were mapped to the SOAP Header, duplicate Header elements were produced by the SOAP Reference Binding in the outgoing SOAP Request. The content of these Header elements was correct and distinct, but the element names were duplicate.
With this fix, the SOAP Header elements are distinct, with the corresponding distinct element content.
AMRP-5153 In case of TIBCO ActiveMatrix SOA projects containing Java Implementation Type (IT) configured with JAXB Data Binding, if the Port Type(s) used by the Java IT Component were defined using multiple complex WSDLs, the underlying JAXB layer had various memory management issues, leading to high memory usage at runtime. These issues have now been fixed and high memory usage will no longer be seen.
AMRP-5228 Previously, the TIBCO ActiveMatrix Administrator could not be updated with the JVM System Properties set in the Runtime Node's TRA file and the properties were not displayed in the Administrator UI. With this enhancement, any changes made by the Administrator UI or CLI to the Runtime Node's JVM arguments, are
communicated to the Administrator, and the new properties (defined in the format java.property.<property-name>=<property-value>) are displayed in the
Administrator UI.
Also previously, a few properties had to be saved as part of
"java.extended.properties", in the Runtime Node's TRA file. The user can now store all JVM System Properties in the format:
java.property.<property-name>=<property-value>
This behavior can be enabled by setting the JVM property
java.property.com.tibco.admin.nodeservice.split.user.jvmArgs=true in the System Node's TRA file, as follows:
java.property.com.tibco.admin.nodeservice.split.user.jvmArgs=true
To restore the previous behaviour, the user can add the following lines in the TRA files of each TIBCOHost in the TIBCO ActiveMatrix Enterprise, as follows:
java.property.com.tibco.admin.nodeservice.split.user.jvmArgs=false java.property.com.tibco.tibcohost.runtime.tra.disable.split.user.jv mArgs=true
AMRP-5230 Previously, in the LDAP Authentication template and SSL Server Provider
template, there was no option to configure the "maxPoolSize" in the CLI data file or via Administrator UI. This limited the use for large deployments. This is now fixed and a user can set an appropriate maximum pool size as per requirement.
AMRP-5232 Previously in TIBCO ActiveMatrix BPM, when HTTP Compression was enabled from the ActiveMatrix Platform, the BPM RAD/JAD forms were not loading correctly and resulted in the error: java.io.IOException: write beyond end of stream".
The BPM App Management UI did not work if the HTTP Compression was enabled. As an interim solution, a TRA property
(com.tibco.amf.hpa.tibcohost.jetty.disableCompression) was introduced by the Platform to turn off the HTTP Compression Support.
With the new set of fixes, even if HTTP Compression is enabled, no issues are seen in TIBCO ActiveMatrix BPM. The TRA property
(com.tibco.amf.hpa.tibcohost.jetty.disableCompression) is no longer necessary to suppress the errors and the HTTP Compression feature can be used in TIBCO ActiveMatrix BPM.
The TRA property
"com.tibco.amf.hpa.tibcohost.jetty.disableCompression" can still be used to disable the HTTP Compression feature, if required.
AMRP-5235 When an application configured with an SSL-connector was restarted, the pool active size was incremented by 1. As the default pool size is 20, when pool active size becomes 20 during multiple application restart, the application failed to start.
This happened because even if the pool was empty, a new connection was created leading to exhaustion of connection pool. This issue has been fixed. It checks whether the pool is empty, releases the connections, and then assigns one from the pool.
AMRP-5237 Because of a known issue, enabling HTTP Compression for SOAP/HTTP Service Bindings caused the HTTP Connector Resource Instance to throw the error "stdout - java.io.IOException: write beyond end of stream Error". To prevent this until a fix for this defect is made available, HTTP compression needs to be turned OFF.
With this fix, HTTP compression can be disabled by setting the following property in the node's TRA file:
java.property.com.tibco.amf.hpa.tibcohost.jetty.disableCompression=
true
AMRP-5243 When multiple applications had a Threading Policy and a TransactedOneway Policy, and even when the applications shared a common thread pool, the number of "ps_<prefix>_" threads created would still exceed the configured "Max Pool Size"
of the thread pool. This issue has now been fixed; the total number of threads for the multiple applications that share a thread pool will be restricted by the "Max Pool Size" parameter with threads allocated to the applications in the pool on a first come first served basis. This behavior will take effect only upon setting
"com.tibco.amx.cf.threadpool.sharing" to "true", in the Node's TRA file, as follows:
java.property.com.tibco.amx.cf.threadpool.sharing=true
AMRP-5254 Previously in TIBCO ActiveMatrix, the Keystore Provider Resource Template did not support setting of the "Maximum Pool Size" parameter. With this
enhancement, the
user can now set the "maxPoolSize" value in the resourcetemplate_data.xml to control the Pool Size. This file is located in the <CONFIG_HOME>\admin
\<InstanceName>\samples folder.
For example, in the resourcetemplate_data.xml excerpt shown below, the
"maxPoolSize" is set to 45:
<ResourceTemplate
xsi:type="amxdata:KeystoreCspResourceTemplate"
name="KeystoreRT"
description="This is a Keystore RT"
keyStoreLocation="/path/to/keystore.jceks"
keyStorePassword="unique"
keyStoreType="JCEKS"
keyStoreProvider="SunJCE"
maxPoolSize="45"
keyStoreRefreshInterval="3600000"/>
Above CLI Data file changes are applicable to Resource Templates with a 'Global' scope. If a given Resource Template is scoped at 'Application' or 'Environment' level, then 'resourcetemplate_scope_build.xml' and 'resourcetemplate_scope_data.xml' files will have to be updated.
AMRP-5264 Jetty provides a timeout mechanism for session expiry. The default value for the controlling parameter was hard coded to 1800 seconds. This inflexibility resulted in inconvenience for users. With this fix, a session's maximum inactive interval is now configurable by setting the
"com.tibco.amf.hpa.tibcohost.jetty.sessionMaxInactiveIntervalInSecs" TRA property in the Node's TRA file as follows:
java.property.com.tibco.amf.hpa.tibcohost.jetty.sessionMaxInactiveI ntervalInSecs=1800
The default for this property is 1800 seconds.
AMRP-5352 While starting multiple nodes under the same TIBCO Host, intermittent failures were experienced with a spurious error message "TIBCO-AMX-HPA-012272: Node is in automatic start mode." This has been fixed so that if a failure does occur, an appropriate error message is conveyed.
AMRP-5353 TIBCO ActiveMatrix now accepts HTTP requests in which the "Content-Encoding"
is set to "gzip". This behavior is controlled using the
"com.tibco.amf.hpa.tibcohost.jetty.disableCompression" TRA property. If its value is set to "false", a Node can accept gzip-compressed HTTP requests.
The HTTP response sent out is also compressed using gzip encoding. This is the default behaviour. If the TRA property is set to "true", gzip-compressed HTTP requests are not handled and the HTTP response sent out is not compressed. The TRA property can be set in the Runtime Node's TRA file as follows:
java.property.com.tibco.amf.hpa.tibcohost.jetty.disableCompression=
true
AMRP-5354 In case of TIBCO ActiveMatrix BPM, when Process Instances were started using a new version of the process after updating the Reference-side WSDL (for example, to add a new Operation), request messages accumulated in the BPM Component's internal queue, and the following error message was seen in the BPM Runtime Node log: "TIBCO-AMX-CF-010002: Missing target". Specifically, this occurred when the Component Reference was attempting to invoke the newly added Operation but the Promoted Reference was not aware of the Operation and the newly available Promoted Reference version (containing the new Operation).
To address this issue, if the TRA property
"com.tibco.amx.cf.enable.virtualizationAddress.versioning" is set to "true" on the BPM Runtime Node, the error message is no longer seen and Process
Instances of the new version are successfully created. The default value of the TRA property is "false". Please note that the TIBCO ActiveMatrix BPM Application needs to be upgraded after enabling the TRA property.
AMRP-5357 For the caching functionality in the Health Check feature, a new capability has been added. A new parameter "refreshIfOlderThan" has been added to the Health Check request.
AMRP-5370 The reporting capability of the TIBCO Host shell command "describeApplications"
has been enhanced. It now displays the version numbers of the custom features to which the application components are wired.
AMRP-5371 At present, when TIBCO ActiveMatrix Host is stopped, all Nodes managed by that Host are stopped irrespective of their startup mode, that is, Nodes configured for manual startup are also stopped. To prevent the stopping of Nodes configured for manual startup, a new TRA property "com.tibco.amx.decouple.Manual.Nodes" has been introduced. This property is used during Host startup and shutdown to determine the behavior of the Nodes configured for manual startup. As a result, the life cycle of these Nodes is decoupled from the Host life cycle, and as a result, the Nodes do not get affected when the Host is stopped/started, and their
shutdown/startup can be handled manually.
When the property "com.tibco.amx.decouple.Manual.Nodes" is set to "true" in Host's TRA file:
1. Host shutdown will not stop any Nodes running on that Host and only the Host will be stopped that is all Nodes on Host will stay in "RUNNING" state after the Host is stopped.
2. Host startup will reconnect to all its managed Nodes that are running regardless of their startup mode i.e. the Host will acknowledge all managed Nodes that are running including the Nodes configured for manual startup.
If the managed Nodes are not running:
1. Nodes configured for automatic startup will be started.
2. Nodes configured for manual startup will not be started.
When the property "com.tibco.amx.decouple.Manual.Nodes" is set to "false" in Host's TRA file, it will have no effect, that is, the Host and Nodes will continue to behave as before. The default value of the TRA property is "false".
● If existing Host is running as a Windows NT Service, the Service needs to be updated in order for the Host to pick up the property. The Service can be updated by executing the following command: tibcohost.exe --update
● If the Host is stopped with the TRA property set, it is recommended that it also be started with the TRA property set to avoid inconsistent status of Nodes. If this property is not set during Host startup, then Nodes (configured for manual startup and in RUNNING state at the time of Host being stopped with this property set), will go into STOPPED state and will need to be started manually through Admin UI or CLI.
● This TRA property is applicable to Hosts only and has no meaning if set in Node's TRA file.
● The TRA property can be permanently applied the installation by adding it to the tibcohost.tra template file so that the newly created Hosts can automatically inherit it. To achieve this, add the property to tibcohost.tra template located inside TIBCO_HOME/tibcohost/3.3/templates folder. (This template gets overridden with every Hotfix installation. If modified, the user will have to merge the contents of the new template with the contents of template backed up in TIBCO_HOME/backups/pre-amx-3.3.0.HF<version>/tibcohost/3.3/
templates folder).
AMRP-5418 Previously in case of TIBCO ActiveMatrix, for Applications with both Threading Policy and TransactedOneWay Policy applied to a Component Service, with timeout configured by:
● Adding the "invocationTimeoutInMilliseconds" TRA property at an Application level to the BPM Runtime Node or
● Setting timeout as part of the Threading Policy, the transaction failed to rollback when the Invocation Timeout occurred, and as a result, the database connections and the thread used by the Application were not being released.
This resulted in the following exception:
"TIBCO-AMX-CF-888214: Execution stopped because of threading policy timeout on Operation Name".
With this fix, after the Invocation Timeout occurs, the thread is released into the threadpool and the Database connection is released as well, thus no exceptions related to availability of Managed Connections are seen in the BPM Runtime Node log.
AMRP-5425 In case of JMS Connection Factory Resource Templates, the "Maximum Pool Size"
parameter could not be set. Even if the value was overridden using the TRA property "com.tibco.amf.sharedresource.jms.connection.pool.maxsize", the value was not updated and remained set to its default value of 20.
With this fix, the Maximum Pool Size can now be set correctly with the same property, by setting in the SystemNode's TRA file, and the value will take effect as expected:
java.property.com.tibco.amf.sharedresource.jms.connection.pool.maxs ize=<newMaxSizeValue>
● This fix only affects the "Maximum Pool Size" parameter. The "Minimum Pool Size" parameter can still be set effectively using the
"com.tibco.amf.sharedresource.jms.connection.pool.minsize" property as previously documented.
● SystemNode should be restarted after setting the
java.property.com.tibco.amf.sharedresource.jms.connection.pool.maxsize=<new MaxSizeValue> property.
● The "Maximum Pool Size" value will be set for new Resource Template created after setting the property. The value will not take effect by updating existing Resource Templates with new "Maximum Pool Size".
AMRP-5443 Previously, in TIBCO ActiveMatrix Administrator, Node Start Action would hang intermittently in Administrator CLI, due to failure in processing RDA commands by the Runtime Node. This problem has now been fixed, thus preventing the indefinite wait in the TIBCO ActiveMatrix Administrator CLI for Node Start Action.
AMRP-5467 Starting TIBCO ActiveMatrix 3.3.0 Hotfix12, TIBCO ActiveMatrix Administrator began tracking all the Java properties that were set in the Node TRA files, that is, any property set in the format "java.property.<key>=<value>" was read and recorded by TIBCO ActiveMatrix Administrator. With this feature, if a particular
<value> ended with the character "=" (for example in case of an obfuscated password), the character "=" would be missing after the Node was installed.
With this fix, if the <value> of a JVM TRA property ended with the character "=", it will be saved correctly.
AMRP-5478 The error related to Missing Target for Operation when accessing a Target Service occurred when the Namespace of a concrete WSDL used by the Promoted Reference was updated as a part of the TIBCO ActiveMatrix BPM Application Upgrade. As a result, even though the Operation was apparently present, it was different, or missing, since the Operation definition includes the WSDL
Namespace in addition to the Operation name. Updating the Concrete WSDL Namespace makes the Target Service a completely different one and is bound to cause issues in TIBCO ActiveMatrix BPM application upgrade. Please contact TIBCO Support to overcome the issue if it occurs.
For additional information on the "Missing Target for Operation" error, refer to:
https://support.tibco.com/s/article/Understand-TIBCO-AMX-CF-010002-Missing- target-for-operation-error
AMRP-5487 Previously in TIBCO ActiveMatrix, if the "Remove Component" command is scheduled for a Component that no longer exists in the Runtime Node, the Component Framework thread exited when the Runtime Node was restarted.
With this fix, the ComponentFramework thread can process the scheduled
"Remove Component" command even for Components that no longer exist.
AMRP-5498 In TIBCO ActiveMatrix Administrator UI, Maximum Pool Size can now be specified for a JMS Connection Factory Resource Template. The new field is available when creating a new JMS Connection Factory Resource Template. The value of Maximum Pool Size can also be updated for existing JMS Connection Factory Resource Templates. Specifying the Maximum Pool Size is optional. If no value is specified, the default value for Maximum Pool Size is 20. You can override the default value using the property
"com.tibco.amf.sharedresource.jms.connection.pool.maxsize" in SystemNode.tra.
The value can be specified in the TRA file as follows:
java.property.com.tibco.amf.sharedresource.jms.connection.pool.maxs ize=<new_value> and also using the TIBCO ActiveMatrix Administrator UI:
property: com.tibco.amf.sharedresource.jms.connection.pool.maxsize value: <new_value>
When you change the Maximum Pool Size of an existing Resource Template, TIBCO ActiveMatrix Administrator UI prompts you to reinstall all Resource Instances of that Resource Template. After the Resource Instances are re-installed, the new value of Maximum Pool Size is applied to runtime.
While creating a resource template, the value provided using the UI or CLI (via attribute 'maxPoolSize') takes precedence over the value
specified in the SystemNode TRA file. The 'maxPoolSize' attribute can be specified as follows, refer to the following configuration file for details:
<TIBCO_HOME>/administrator/3.3/samples/jmssr_data.xml
<ResourceTemplate
xsi:type="amxdata_jmsssr:JNDIConnectionFactoryResourceTemplate"
name="NewJndiConnectionFactorySharedResource"
jndiName="GenericConnectionFactory"
jndiConnectionConfigurationName="NewJndiConnectionConfigurationShar edResource" description="JndiConnectionFactory" xa="false"
maxPoolSize="20">
AMRP-5502 If a DAA with a JMS Connection Factory Resource Template is deployed, a Resource Template is created with a default Maximum Pool Size of 20. To change the default value for JMS Connection Factory Resource Template, you can set it using the property "com.tibco.amf.sharedresource.jms.connection.pool.maxsize" in the SystemNode TRA file. The value can be specified in the TRA file as follows:
java.property.com.tibco.amf.sharedresource.jms.connection.pool.maxs ize=<new_default_value>
and also using the TIBCO ActiveMatrix Administrator UI: property:
com.tibco.amf.sharedresource.jms.connection.pool.maxsize value:
<new_default_value>
When you change the Maximum Pool Size of an existing Resource Template, the UI prompts you to re-install all Resource Instances of that Resource Template.
After the re-installation of the Resource Templates, the new Maximum Pool Size is applied to Runtime.
AMRP-5514 In TIBCO ActiveMatrix Runtime Node Message Flow logs, Reply Messages were missing the CorrelationID field in scenarios where the Messaging Bus was involved in the communication, that is, when the Components in question are distributed on two different Nodes, or, when Virtualization Policy has been applied. The CorrelationID field was present and correct in the direct invocation (or in-memory scenario), that is, when the Components are collocated on the same Node. With this fix, the CorrelationID is present in the Reply Message logs of the Message Flow logger in scenarios involving the Messaging Bus.
AMRP-5518 TIBCO Host did not have the capability to capture stdout logs in the Host log file.
For example, TIBCO Enterprise Message Service client trace logs are generated as stdout logs and are displayed in Host console window if Host is running as a normal executable however for a Host running as a Windows Service, these client trace logs could not be captured as there is no console window in case of a Windows Service. With this fix, stdout logs can be redirected and captured in the Host log file. This is applicable to both types of Hosts, that is, Hosts running as a Windows Service and Hosts running as a normal executable. To enable redirection of stdout logs, "stdout" logger should also be configured in Host log4j
configuration at "INFO" level.
AMRP-5520 In case of HTTP Client Resource Instances (used by SOAP/HTTP or REST/HTTP Reference Bindings in TIBCO ActiveMatrix), if a cookie was set in the Response Header sent by the target service, it was being passed in the Request Header for all the subsequent requests. With this enhancement, an option has been provided to clear the previously set cookies so that the user does not have to do so manually (in case their implementation is affected by it). To enable, set the following property "com.tibco.amf.httpclient.ignorecookiepolicy" to 'true' in the Runtime node. The value can be specified in the TRA property as follows:
java.property.com.tibco.amf.httpclient.ignorecookiepolicy=true
and also using the TIBCO ActiveMatrix Administrator UI:
property=com.tibco.amf.httpclient.ignorecookiepolicy value=true
When the property is set to true, the cookies are cleared from the cookie store and do not appear in subsequent requests originating from SOAP/HTTP or REST/
HTTP Reference Bindings. By default, the value for this property is set to false, in which case the cookies are not cleared from the cookie store before sending a request.
AMX-6683 Some SOAP client test tools do not generate the right WSDL message when WSDL constructs are of Doc/Literal with the message part referring to type causing unpredictable behavior.
AMX-7988, AMSG-9672, AMX-14828, AMX-14829
TIBCO ActiveMatrix Administrator now provides a data export facility. You can export Administrator objects such as Environments, Nodes, Applications,
Resource Templates to CLI scripts. The CLI scripts can be modified as needed and then executed using ANT on the same or a different ActiveMatrix enterprise. This recreates the objects based on the exported archive. You can export data via Administrator UI by navigating to: Admin Configuration > Admin Server >
General tab and clicking Export Wizard, or via Administrator CLI using a provided ANT task.
