AMS Overview


Prev		Next

AMS Concepts

AMS is a revision control system that maintains current and historical versions of artifacts in its repository, which by default is an embedded H2 database. Through a web client, users logged into AMS can edit and commit artifacts to the repository, or choose to work on artifacts locally for development and testing purposes.

AMS enables users to build and store a set of rules, which are business logic built upon user-defined conditions and actions. In AMS, rules are packaged as decision table artifacts and stored in project folders. Users can create artifacts from scratch or import artifacts and then modify them within AMS. Rules can then be loaded into decision table EventFlow modules in the separately installed TIBCO StreamBase Studio.

Additionally, AMS supports the management, storage, and deployment of model-type artifacts. See Supported Artifact Types for more information.

From an AMS perspective, an artifact is considered a data file.

	Note
	AMS artifacts are not related to Apache Maven or other third-party artifacts.

Users can be assigned one or more roles within AMS, with different privileges assigned to each role. An AMS administrator who is assigned to an admin role is typically responsible for creating new users and managing their roles and privileges. Roles and privileges set the guidelines for artifact access and management.

See User Roles AMS to learn more about roles.

Artifact Workflow

A user with the appropriate role and privileges (typically this is a business user) signs onto the AMS web client and creates a project and artifact, or checks out an existing artifact to work on. The business user saves the artifact locally and commits the changes for approval. Another user, one with approval privileges, reviews the changes the business user made and decides whether to approve or reject the changes.

If the reviewer approves the committed changes:

The artifact version becomes the official version in the repository.
The changes become visible to any user who has privileges to view the artifact.
The artifact state remains working, allowing the user to continue making changes to it (thus requiring another save, commit, and approval cycle if necessary).
The artifact history is updated and assigned an incremental version number.
Approved artifact changes are also pushed to an source content management system containing the artifact, if an SCM such as Git or Subversion is enabled for AMS.
Users with deploy privileges can deploy decision table or model Artifact Deployment Overview artifacts to TIBCO StreamBase applications.

If the reviewer does not approve the committed changes:

Changes do not become part of the artifact's history nor are persisted to the AMS repository.
Local changes are preserved and remain local to the committing user.
The user can re-commit the artifact (for example, after making additional edits to the artifact).

Workflow Terminology

Approve

A user assigned to a role with the reviewer privileges can approve another user's changes, rendering them visible to other users who have access to the artifact. An approve operation involving multiple artifacts is atomic.

Check out

Prior to working on a set of projects and artifacts, retrieve a local, writable working copy of the items to be worked on by performing a check out. AMS supports single and bulk file checkouts.

Commit

After making changes, the commit operation submits the artifact for storage approval into the AMS repository. This action does not make the changes visible to others; the changes must first be approved. Commits involving multiple artifacts are atomic in that all the artifact updates are approved or rejected together.

If two users check out, modify, and commit the same artifact, what happens? A user whose role is assigned reviewer privileges is notified of the two commits. The first commit to be approved invalidates the second commit. The "losing" user then must synchronize the approved changes with the original checkout and then re-commit the changes for approval.

Create

Build new artifacts from scratch.

Deploy

Loads a decision table artifact to a running decision table EventFlow module in StreamBase Studio, or loads a model file artifact to a model operator EventFlow module in StreamBase Studio.

Diff/merge

Diff/merge is used when synchronizing to apply the approved changes made by another user to the local changes made to the user's checked-out copy of the an artifact.

Discard

Discards your changes in the checked-out copy of the selected artifact. Discard essentially "un-checks out" the artifact.

Edit

Make changes to projects and artifacts.

History

AMS maintains a log of approved changes to each artifact and labels each change with version number. Version numbers start with one and are incremented by one for each new approved revision of the artifact.

Import

Add single or bulk artifacts from a source external to AMS.

Reject

A user assigned to a role with the reviewer privileges can reject another user's committed changes. In that event, changes remain local to the user performing the commit. A reject operation involving multiple artifacts is atomic.

Replace with

Replaces an artifact with one uploaded externally, or a newer or older version stored in AMS.

Synchronize

This command retrieves another user's committed and approved changes. Synchronizing allows the option to apply the changes to your local working copy of the artifacts. This command also applies to externally stored artifacts and update ones stored in the AMS repository with the external versions (such as ones stored in an SCM).

Workflow in Detail

The following scenario describes a typical workflow for a project and artifact management. In this scenario, a user named Amy is assigned the administrator user role, which gives her privileges to manage AMS, including assigning roles and privileges to users. Amy creates a role named business user and assigns it to a user named Bill. The privileges assigned to Bill role allow him to create and modify any project or artifact (in practice, a user with an administrator role can assign user access granularity to any role, including restricting access to specific artifacts). Bill's role does not include artifact reviewer privileges.

Amy also assigns a third user, Rob, the role of reviewer. Using reviewer privileges assigned to his role, Rob can approve or reject commits made by users, including his own changes.

Bill checks out Project 1 and creates Artifact A in that project. Bill's artifact changes are local and are not visible to other users.
Bill saves and commits changes to Artifact A.
The changes remain local to Bill. Bill receives a message in his Notifications area that the commit is pending approval.
As reviewer, Rob receives a message in his Notifications area that a pending commit awaits approval or rejection.
Rob has two options:
1. Approve the commit.
  - Bill receives notification that his commit was approved.
  - A new artifact revision is created, assigned the next version number is sequence, and added to the artifact's history.
  - The artifact becomes available to all users whose roles allow at least read privileges to the project folder.
  - Artifact modifications are pushed to an SCM if the artifact was imported into AMS from one.
2. Reject the commit.
  - Bill receives notification that his commit was rejected.
  - The artifact remains as a working copy local to Bill. Bill can continue modifying the artifact and re-commit for approval.

User Role Examples

User roles are customer-defined, where each role is defined by a set of privileges that set user access control to AMS. The following example shows three user names, their roles, and their assigned privileges. AMS offers the flexibility to assign users as many roles and privileges as needed.

For more information regarding configuring user access, see User Access Control.

User Name	Role	Description
Amy	Administrator	Has all privileges. Can assign users to roles, manage and modify any project or artifact.
Bill	Business User	Can import and modify artifacts.
Rob	Reviewer	Approves or rejects artifacts committed by other users.