Asset Persistence

MDW runtime data is stored in a MySQL, Oracle or MongoDB database, while process definitions and other design-time assets are saved in a version control repository (Git). This asset persistence approach makes for powerful branching and merging capabilities. This is especially important to ensure the integrity of in-flight processes when multiple versions of an MDW workflow coexist in a production environment.

Motivation

As more and more of an application's business value moves into workflow, it's imperative that users have the tools to: Previous releases of MDW provided multiversion capabilities by keeping track of different versions in the database. However, MDW is a BPM tool and is not especially strong in the area of revision control. A better approach is to hand off the SCM aspects of workflow to GitHub, and let users take advantage of the vast array of tools available for managing their assets in a GitHub repository.

How It Works

When you choose VCS persistence while creating a new workflow project, MDW saves any assets you create as files in your project on the local file system (typically under src/main/workflow).

Workflow packages are simply directories in the workflow project containing a special subdirectory named .mdw. Inside this subdirectory the details of the workflow package is kept in a file named package.json.

While users are working on their own, MDW saves asset version information in a special file (specifically "versions"). When it comes time to share their output, users collaborate through a central, remote GitHub repository by committing and pushing their changes. They can do this using the Git tooling built into IntelliJ or Eclipse.

To make use of shared assets you'll continue to leverage the MDW Asset Discovery mechanism.

Any asset dependencies imported this way are also checked in to GitHub, so that the same specific versions are consistently used in every environment.

Runtime

At runtime workflow assets are cached in memory by the MDW engine. When VCS-based persistence is used, assets are read from the file-system at startup instead of from the database. Older package versions for in-flight processes are kept in the Archive subdirectory.

The master copy of all workflow assets is stored in a shared GitHub repository for the project. VCS-based assets can be installed through a command-line GitImporter provided by MDW. This installation utility pulls the project assets from GitHub and stores them in a root directory designated by the MDW property mdw.asset.location. MDW uses the GitHub library for pulling assets, so no client-side GitHub installation is required. If asset packages already exist on the server file system, the installer moves old versions to the Archive directory so that they'll still be available for in-flight execution.
Note: If no GitHub repository is available, as an alternative to the GitImporter the original XML export/import can still be used with VCS-based assets. Your assets are checked into the VCS tool of your choice, and this just requires the extra step of exporting to XML in Designer.

Runtime transactional data is stored in an Oracle or MySQL database. Every instance-level record has a definition ID field to associate it with the corresponding design-time asset (the PROCESS_INSTANCE.PROCESS_ID column, for example). This asset ID is computed using the Git SHA hash algorithm based on its logical place in the workflow hierarchy, (eg: com.centurylink.mdw.demo.intro/Handle Order v0.19 - same as the asset path in MDW Studio's Assets tree view). So every asset has a repeatable, unique ID that's constant across every environment. For compatibility with the existing data model, computed IDs are abbreviated to fit in a Java long native type. However, the chances of a collision in any real-world project is still so unlikely as to be non-existent. These IDs are displayed in MDW Studio with both their decimal and native hex values.

Remote Projects (Deprecated)

One of the strengths of MDW has always been the runtime view it provides, which overlays the process design with runtime instance information. This is still the case with VCS asset persistence, but this information is now retrieved through a REST service call to the server rather than directly from the database. In fact, with the latest MDW and VCS-based persistence, Designer no longer makes any direct JDBC connections to the database. This has far-reaching benefits with regard to HTML5 and MDWMobile workflow access, and also has implications for Remote projects in Eclipse Designer.

When you access a remote project in Designer (either manually or through the discovery mechanism), MDW asks the server which branch in the GitHub repository contains the assets it has deployed. On the server this is specified in the property mdw.git.branch. This property is the same one used by the install utility, so it's not possible for it to be out-of-sync. In fact, at server startup time the MDW runtime engine confirms that the asset packages on the file system match the branch designated by this property and logs a warning if there's a discrepancy.

Back in Designer, when the remote project is accessed, if its workflow assets don't yet exist locally (or if the server reports a different branch) the matching branch is pulled from GitHub automatically. That way when you open a process instance the design artifact locally is always the same as that used on the server for process execution. The instance runtime data is retrieved from the server through REST, so the server must be running to view a process instance. And since Designer no longer talks directly to the database, this applies to local workflow projects as well.

For more information about remote projects, refer to Eclipse Help > Cheat Sheets > MDW Workflow > Remote Projects.

Note: Any MDW application that is yet to be transitioned to VCS and/or upgrading to MDW 5.5 or higher, please refer to Upgrade Wiki Page