This topic summarizes the history of significant changes in TIBCO® Artifact Management Server releases 1.1.0, including features, enhancements, and corrections.
TIBCO AMS 1.1.0 added the following updates and new features:
AMS now supports the downloading of a project as a .zip file. The Download operation zips all artifacts in the project (which must first be in the repository) and downloads to user's file system. The operation does not maintain any project folder structure.
When starting the AMS server, JVM arguments can now be supplied by preceding them with a -J argument and a space. Each JVM argument requires a separate -J argument. See Starting and Stopping the AMS Server.
AMS now supports the option to deploy artifacts to multiple nodes (which must reside on the local machine) using the StreamBase Service Name option. Please see the known limitation that affects this feature. Otherwise, see Artifact Deployment Overview for more information regarding deployment options.
The artifact editor includes a new column for assigning individual rule priority. See Building Rules Using the Artifact Editor for more information.
The AMS now supports transparent upgrades of its database schema as well as on-demand initialization of the database for new AMS installations. As a result, the initdb option of the ams-server command was removed. Before upgrading the schema of an existing database, AMS makes a backup copy of the database with the name <original-name>.<date>.bak<n> (for example, ams-h2-persistence.mv.db.2017-01-10.10.26.55.bak0).
For convenience you can now read (but not edit) .sbdt artifact file types using a text editor by right-clicking on the artifact and selecting Open with > .
AMS now has a query permission REST API. The endpoint takes a query parameter called permissions consisting of one or more comma-delimited permission strings and returns a set of records, one for each permission string, indicating whether the logged-in user has that permission. See Querying the AMS API for User Permissions.
The following functionality was changed in this release.
AMS 1.1.0 introduced several changes to AMS permission checking:
Artifact-level permission checking now includes the project name in artifact resource strings. For example, MyFolder/MyArtifact is now MyProject/MyFolder/MyArtifact.
The decision_table permission type is deprecated (but still supported for backward compatibility) and was changed to artifact.
DEPLOY is no longer a valid project-level action.
CUSTOM is no longer a valid permission type.
When * is present in resource strings, AMS performs regex matching rather than exact string matching to allow it. For example, a permission artifact:read:test/* to grant read access to all artifacts in the test project or artifact:write:foo*/bar* to grant write access to all artifacts whose names start with bar in projects whose names start with foo.
The decision_table permission type is deprecated (but still supported for backward compatibility) and was changed to artifact.
There are no known migration issues when upgrading from AMS 1.x to AMS 1.1.0.
This section describes known limitations in the current release of the TIBCO Artifact Management Server. Each item includes a tracking number, description, and whenever possible, one or more workarounds.
| SB‑30256 | Cannot deploy rules using service name. | |
| Description | An issue prevents AMS from deploying decision table rules to a running decision table EventFlow module, when configured to push rules via a StreamBase Server's service name. | |
| Workaround | Deploy rules using the StreamBase Server's URI as described in Deploying Artifacts. | |
This section describes resolved limitations in the current release of the TIBCO® Artifact Management Server. Each item includes a tracking number and a description.
| Fixed in 1.1.0 | |
|---|---|
| Number | Resolution |
| SB‑30478 | In previous releases, AMS looked for its configuration file only in the $AMS_HOME/conf directory. The AMS start script now prepends the user's classpath to the classpath it uses in starting the server. Thus, a user can place a site-specific copy of AMS.conf in any directory, add that directory to the classpath, run the ams-server script, and have the site-specific AMS.conf file used instead of the copy of AMS.conf installed in the $AMS_HOME/conf directory. |
| SB‑30255 | Prior to StreamBase 7.6.7, the mechanism to deploy decision tables from an Artifact Management Server to StreamBase was incompatible with the Decision Table operator. The operator was modified in 7.6.7 to correct this incompatibility. |
| SB‑29540 | As a previously known limitation, using the keyboard combination Ctrl+C and Ctrl+V did not copy and paste decision table rules from corresponding table cells. This was fixed. See Building Rules for Decision Table Artifacts for information on usage. |