4.0.0
Release Date : February 12, 2007
Life Cycle Management
- Advanced life-cycle management becomes operational with the notions of branch and version.
A branch is a isolated "home" updatable by multiple users.
A version is a "home" that is a fixed snapshot of a branch.
For more information, please refer to
- The concept of Adaptation edition becomes obsolete since a branch is a more general and more consistent way for storing updates.
- Compare & Merge: Automatic merge of a branch to its parent branch. In version 4.0 the merge process has a limited interactivity (override-all or nothing).
Search & Filters
- Added default end-user search GUI on tables.
Directory and Permissions Management
- A new API for external directory integration is added. This API supports a simple and flexible user-roles model.
- In webMethods Master Data Manager, it is now possible to fully manage users and roles if default directory is used . Default directory provided is indeed based on webMethods MDM repository (Directory is a standard adaptation).
- Version 3.x default directory is transparently migrated.
- In webMethods Master Data Manager, it is now possible to manage extended definition of access rights and action permissions (with a multiple rights and multiple profiles model).
- In webMethods Master Data Manager, it is now possible to change an adaptation tree owner.
- A full permission management is also provided for managing branches and delegating rights.
- Permission resolution is generally based on a restriction principle: the resolved permission that the user has is the minimal right granted by : the branch, the instance and the node.
Miscellaneous
- Some deprecated methods have been removed.
-ProcedureContext.writeAdaptation(Adaptation, File)
-ProcedureContext.writeAdaptation(Adaptation, OutputStream, boolean)
Other (non-deprecated) methods have been removed:
-ProcedureContext.computeChangesForImport(Archive)
-ProcedureContext.doApplyDiff(CfDiffComputer)
-ProcedureContext.doExportAllRepositoryToArchive(Archive)
These methods were probably not used. If this is nevertheless the case, please contact technical support.
- Published API for computing and accessing differences, in package
com.softwareag.mdm.service.comparison
(see javadoc). - Added class
com.softwareag.mdm.instance.Repository
, as a central access point to the repository and its resources. - Published method
refreshSchemas(boolean)
for hot schema refresh, in classcom.softwareag.mdm.instance.Repository
(see javadoc).
Repository and Core Engine
- Optimized caching: webMethods MDM Cache now supports large volumes of data in a constrained memory space.
- Repository persistence: File system persistence is no more supported. Default persistence becomes "HSQLDB standalone".
- Repository migration from File System: A 3.x file system repository is transparently migrated at server startup.
- Repository migration from Relational Databases: if the 3.x repository to migrate is based
on a relational database, it cannot be migrated transparently.
In this case, you must follow the following steps:
- In webMethods Master Data Manager 3.x, release or cancel all the adaptation editions.
- In webMethods Master Data Manager 3.x, export a full repository archive (under "Deployment" tab).
- In a new installation of webMethods MDM 4.0, in the "repository" directory
(specified by property
{mdm.repository.directory}
), delete all files and sub-directories. Then, copy the "repository" directory of 3.x installation to this location. - In the new installation of webMethods MDM 4.0, under directory
{mdm.repository.directory}/Adaptation
, replace all files with the files contained in the archive generated at step 2. - Run webMethods MDM 4.0. The repository migration will be transparently executed when the first request is sent to the server.
Known limitations:
- Optimizations: for large number of tables (in the order of 10,000 tables) and for large number of occurrences (in the order of 10,000,000 occurrences), optimizations are not yet available.
- Merge process: in case of instances' add-add conflict, tables in the source are ignored.
Workaround: first create instances and merge, then tables may be populated and merged. - Comparison and Merge: Header informations are not yet included in the comparison user interface nor in the merge process.
Workaround: for merging header informations, a least one value must be updated on instance. - Comparison and Merge: Permissions defined are not yet included in the comparison User Interface nor in the merge process.
- Repository locking: it is not yet detected when two Java virtual machines share the same physical repository.
Workaround: Repositories' administrator must take care that a repository is not refered by two environments. - Permissions management: a user without the built-in
PROVIDER
role cannot access on adaptation instances above agreements.
Workaround: the user must have the built-inPROVIDER
role. - Access right management: a node can be set as
ReadWrite
even it is not adaptable according to schema definition.