MMS Overview

This topic introduces the TIBCO Streaming Model Management Server (MMS) and explains the concepts of its use.

MMS Concepts

MMS is a platform that helps users manage models and artifacts. It allows users to create projects, save checkpoints for version control, and deploy artifacts efficiently. MMS is a revision control system that maintains current and historical versions of artifacts in its repository, which is, by default, an embedded Git repository. Through a client, users logged in to MMS can edit and create a checkpoint of changes to the repository.

One of the artifact types that MMS supports is Decision Tables which have a set of rules (business logic) built on user-defined conditions and actions. Decision Tables can be deployed into running TIBCO® Streaming applications for on-the-fly updating of rule processing against simultaneous streams.

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

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

In an MMS setup integrated with an external authentication/authorization system, the MMS administrator assigned to an admin role is responsible for managing artifact access and privileges. Users and roles are created and maintained in the external authentication/authorization system, while roles and privileges within MMS define the guidelines for artifact access and management.

For more information, see Logging in MMS.

Artifact Workflow

A user with the appropriate roles and privileges (typically a business user) logs in to the MMS client and begins by creating a new sandbox or selecting an existing one. Within the sandbox, the user creates projects and their associated artifacts or imports existing projects to work on. After changing the project and its artifacts, the user saves the updates locally within the sandbox. The user can then create a checkpoint to capture the state of the changes. Once satisfied, the checkpoint can be published to the backing space. Published projects and their artifacts become visible to other sandboxes or users and are deployed using the deployment workflow.

The user can also perform different operations such as merge checkpoints, reset to checkpoint, discard modifications, and so on.

Workflow Terminology

Sandbox

A sandbox is a private, isolated workspace where the user can create, modify, and experiment with projects and their artifacts without affecting the global or shared environment. It allows users to work on drafts or updates safely and independently before finalizing and publishing changes to the backing space.

A sandbox supports:

Isolation: Changes made in a sandbox are visible only to the user, ensuring a safe environment for experimentation and development.
Versioning: Sandboxes support saving checkpoints, enabling users to track progress and revert to previous states if needed.
Collaboration: While the sandbox itself is private, it integrates into a broader workflow by allowing published changes to be shared with other users and sandboxes.
Workflow Support: It acts as a staging area for creating, editing, testing, and validating projects and artifacts before they are deployed or shared.

Checkpoint

A checkpoint refers to a saved state of a project's artifacts within a sandbox at a specific point in time. It acts as a snapshot of the current progress, capturing all changes made to the artifacts up to that moment. Checkpoints have several purposes, as given below:

Version Control: It enables users to track changes and revert to previous states if needed.
Collaboration: It facilitates collaborative workflows by allowing consistent and shareable points of progress before publishing.
Publication: A checkpoint is always required before changes are published to the backing space. This ensures that only well-defined, validated updates are shared with other users or systems.

Note: A backing space is a common repository or shared workspace in MMS where users can publish their projects, making them available for other users to import and collaborate on.

Publish

Publish refers to the process of making the changes made in a sandbox available to the shared backing space. This allows other users or systems to access, review, and collaborate on the updated projects and artifacts. Each time a user performs a publish operation, the project version must be updated and must be unique within the project's backing space or else the publish fails. The project version can be updated from the Project Properties section.

Some of the key features of publishing are:

Checkpoint-Based: Before publishing, users must create a checkpoint to capture a stable and validated state of the changes in the sandbox.
Version Control: Each publish operation requires the project version to be updated and uniquely identified, ensuring proper tracking and preventing conflicts.
Visibility: Once published, the updated projects and artifacts become visible and accessible to other users, sandboxes, or the broader environment.
Collaboration: Publishing enables synchronization of work among team members, facilitating collaborative workflows.
Deployment Preparation: Published artifacts and projects are often prerequisites for deployment workflows, ensuring that only reviewed and approved changes are propagated further.

Create

Build new artifacts or projects from scratch.

Deploy

A project can be deployed to one or more EventFlow operators in a running Streaming cluster, causing those artifacts to be activated and used in the corresponding operator. The operator specifies the artifact that it requires in its configuration, and the artifact is loaded into the operator once the project is deployed.

Deployment descriptor

A deployment descriptor is a configuration document used to define the parameters and settings for deploying a project or application to a target environment. It serves as a blueprint for deployment, specifying essential details such as the target cluster, deployment options, and scheduling preferences.

Merge

Merge refers to the process of integrating changes from the backing space into a sandbox. This ensures that the sandbox is updated with the latest modifications. It consolidates updates to maintain consistency between the sandbox and the shared environment. Merge operation cannot be done if the sandbox has local modifications.

Discard Modifications

Discard Modifications refers to the process of rolling back changes in a sandbox. If a checkpoint exists, the discard operation deletes all changes made since the last checkpoint, restoring the sandbox to that state. If no checkpoint is present, the discard operation completely deletes all changes, reverting the sandbox to its original state. This ensures that unwanted modifications do not impact the project.

Edit

Update projects and artifacts.

Import

Add one or more projects from the backing space or local system to MMS. The Import option allows importing only projects, and not individual artifacts. Artifact contents can be imported from the local file system during new artifact creation only.

Reset Sandbox

Reset sandbox refers to the action of reverting a sandbox to its state before any checkpoints were created. This operation removes all checkpoints and synchronizes the projects in the sandbox with their corresponding versions in the backing space. Changes associated with current checkpoints are preserved as pending changes, which can be discarded manually after the reset is complete. This operation is irreversible for checkpoints and ensures that the sandbox aligns fully with the backing space.

Reset to Checkpoint

Reset to checkpoint refers to the process of reverting a sandbox to the state captured in a specific checkpoint. This operation is useful for undoing unwanted modifications or returning to a previously validated version of the project within the sandbox. Reset to a checkpoint operation discards all the local modifications. The user is prompted to create a new checkpoint before resetting to save the changes.

Compare with Backing Space

It refers to the process of identifying and reviewing the differences between the current state of a sandbox and its corresponding state in the backing space. This comparison highlights changes made in the sandbox that are not yet published. This feature cannot be used if there are any modified projects in the sandbox.

This feature helps the users to:

Understand the scope of changes before publishing or merging.
Ensure consistency and alignment between the sandbox and backing space.
Identify potential conflicts or discrepancies.

Compare with Checkpoint

It refers to the process of reviewing the differences between the current state of the sandbox and a specific checkpoint. This comparison highlights the changes made in the sandbox since that checkpoint was created.

This feature helps the users to:

Track modifications made after a specific checkpoint.
Review progress or validate changes before publishing or resetting.
Identify and resolve discrepancies between the current sandbox state and the checkpoint.

Workflow in Detail

The following scenario describes a typical workflow for project and artifact management in MMS.

In this scenario:

User and Role Configuration: The MMS administrator is responsible for configuring users and roles in the external authentication/authorization system. Privileges, such as access to specific features or artifacts, are assigned to roles within the external system which are mapped to specific roles in MMS.
Amy's Role: A user named Amy is assigned the administrator role. This gives her the ability to manage MMS settings and ensure that roles and users are appropriately configured in the external system.
Bill's Role: A role named business user is configured for a user named Bill. The privileges assigned to the business user role allow Bill to create and modify projects or artifacts but do not grant him admin privileges.

The steps for the workflow are given below:

1. Sandbox Setup: Bill logs in to MMS and either creates a new sandbox or selects an existing one from the list.

2. Project Management: Within the sandbox, Bill either:

Creates a new project or
Imports an existing project from the project backing space.

3. Artifact Changes: Bill works on the project and modifies the artifacts. After completing the changes, he saves them locally within the sandbox.

4. Checkpoint Creation: Bill creates a checkpoint to capture the current state of his changes. Checkpoints act as a reference point for tracking progress or reverting if needed.

5. Publishing Changes: The changes made in the sandbox remain local to Bill until he publishes them with a unique project version. Bill should have publish permission/write access to the backing space or else his publish fails. When Bill publishes his changes, they are saved to the backing space. Each publish operation needs a unique project version, which can be managed from the project Properties section.

6. Collaboration: Once published, the changes are available to other users. These users can import the published changes into their own sandboxes for further work or review.

7. Deploying: After publishing the project, Bill can deploy it by creating a deployment descriptor. The deployment descriptor allows Bill to define the specifics of the deployment, including:

Target Cluster: Bill selects the target streaming cluster where the EventFlow application is running. This field is mandatory.
Description: He provides a brief description of the deployment for clarity.
Options: Bill configures options such as setting a run duration, restricting visibility to only himself as the deployer, sealing the project after deployment to prevent further changes, or enabling tracing for monitoring and debugging.
Schedule: Bill can also schedule the deployment by specifying the timing using cron syntax, defining the minute, hour, day, and month for automated execution.

Note:

A project needs to be Approved for a cluster before it can be deployed. You can approve a project from the Project Properties section.
The cluster must be accessible (either have a node that is STARTED or STOPPED) and Bill (or his role) must have permissions to access it. The deploy descriptor for a project can be created only when a cluster is running.

This workflow ensures collaboration, version control, and proper management of projects and artifacts across users in MMS.

User Role Examples

User roles are customer-defined, where each role is defined by a set of privileges that set user access control to MMS. The following example shows two usernames, their roles, and their assigned privileges. MMS offers the flexibility to assign users as many roles and privileges as needed. For more information on user roles, see Local User Management.

Username	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.