Skip to Content

Authors: Savi Sharma and Caroline Debattista

The recent MDM service Pack (SP4) brings a useful export and import schema functionality that enables intuitive migration of selected schema objects between repositories. Schema object selection is possible at the table as well as at the field levels.

Key Features of Transport Utility:
  • The source repository is exported as an xml file that can be saved to a hard drive.
  • The import functionality takes the xml file as input, and provides a detailed/exhaustive schema comparison of the source xml and target repository.
  • The Add, Delete, and Modify actions at the table and field levels are identified with different color-coding (Green for adds, Pink for Delete, and Red for Modify) on the compare screens.
  • The schema compare utility permits the user to accept or reject changes at table and field levels.
  • For the schema objects marked for adds and deletes, acceptance at table level automatically accepts the fields.
  • For the Table Modify action, the user is forced to accept or reject changes for individual fields. Thus, accepting a table level modify does not automatically accept the fields of the table that are also involved in a modify action. This subtlety is appreciated as there are plenty of business cases that demand more rigor in a modify action of a table than in a total add or delete.

The attached screen shot shows a table add, delete, and modify in action: image

For a modify action, the schema compare utility is enabled to show the console settings that are different between the source and target. Most console settings are part of the compare utility except unique fields, secondary display fields, and calculated field expressions.

While a schema can be exported out of a live repository, you can import only into an unloaded repository. This is in line with the fact that structural changes can be applied only to a repository in an unloaded status.

Business Cases:

Two important business needs that are easily addressed with this functionality are:

  • Migration of schema objects along the project life cycle path (Development and Quality Assurance) into a production MDM system in a data harmonization scenario.
  • A schema compare and selective merge utility between production support enhancements and mainline project path.

The ability to turn the migration on/off at field level is a key contribution of the transport utility. Objects built, as part of proof of concept or those that are in excess of business requirements need not be deleted before a project is migrated to production.

Content of Transport Utility and Its Underlying Rationale:

In this introduction of transport functionality, MDM has included most of the repository objects that are configured/created using the MDM console. These objects include

  • Table types of look-up, main, qualified, and taxonomy
  • Fields with their specific console settings such as key mapping, field type, length, width, display fields, etc.
  • Calculated fields with their expression.
  • Repository language settings, and .
  • Repository meta data (except for repository description). .

Leaving repository description out of the transport utility is a good choice- you do not want a production repository description overridden with a QA description. The Unique fields (a critical setting) migration is expected to be part of this functionality in a patch in the near future.

The list of objects that are transportable suggests a clear pattern- schema objects that are regarded as the structure of the repository, as opposed to the content, are included in the first release of transport utility. MDM regards all objects configured in modules such as data Manager, Syndicator, and Import Manager as repository content. Hence, taxonomical attributes, import maps, syndication maps, validation expressions, and workflow do not appear as transportable now.

Future Potential:

Of the schema objects MDM regards as repository content, transport utility on validation expressions, maps, and taxonomy would be of great use since errors in manual transport, especially in case of expressions, is high. The transport utility, with the inbuilt schema compare screens that show differences between the source and target, increases efficiency several fold. Other items that would be useful additions to the transport utility include security (roles and users), ports, client systems, and work flow.

TIPS:
  • Once a long list of objects is transported from a source to target, the schema compare utility makes checking for accuracy a snap. The compare should show either no differences or a short list of differences that reflect the user’s conscious choices.
  • In the schema compare screens, it is helpful to sort on type of operation or Merge column to see only those items that have action to be taken.
  • Since the schema import makes structural changes to the repository, a check-repair operation after the schema import helps fix the non-fatal errors as well as warnings. If the import involved field deletes, repair and analyze operations are almost mandatory.
To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Anonymous
    This is a nice introduction to what is coming. However, the bad news is we have to wait for the few important functionalities like transporting Validations, Workflows ! Imagine the pain we had with 1200 validations in our repository.

    Savi: Nice to see you back after a long long time.

    Regards,

    Rajani Kumar

    (0) 
    1. Savitri Sharma Post author
      Thanks Rajani! I can imagine the pain in manually transporting 1200 validations.  What has been implemented so far is still a huge step- I dread manually transporting 10 tables and 100 fields.

      It has been so busy with go-live of one phase and ramp up of the second.  From now on, I will try to be more regular and keep up with you 🙂

      Thanks
      Savi

      (0) 
  2. Tanveer Shaikh
    Its a great relief..Transporting tables and the fields manually is indeed a great problem..
    I recently had answered a question on the forum on similar topic, where i asked the SDN folk posting the question to go ahead with the job manually..
    This shall be really helpful in moving schema from development to sandbox to production..
    Thanks for the blog.
    (0) 
  3. Linda Durant
    The transport utility is a great addition to mdm.  I was wondering if anyone has been able to compare two disparate models.  I’ve tried but I get the following message: “The schemas cannot be merged because the repository schema was modified since the last schema export.”
    (0) 
    1. Savitri Sharma Post author
      Hi Linda,

      Which OS are you using: WIN or UNIX?  Schema transport has some issues on HP-UX platform that SAP will be fixing soon.

      Secondly, what did you mean by disparate models? The purpose of the schema transport functionality is to compare disparate models.  In my example, I have a productive model that has 50+ LKs, and the main table (with default fields).  This is the target.  The development model has main table with 70 fields, 5 qualified models, and a bunch of new LKs.  This is the source.  I was able to take the new structures, and place them in the target with no issues on WIN platform.

      (0) 
      1. Linda Durant
        Savi,
        I am on a WIN environment too.  Are there restrictions or comparisons done against something like the main table name?  Have you seen the message I received before?  I am trying to transfer fields from one repository to another that were developed seperately and have different unique ids under the covers.  Is something like this giving me problems?

        Thanks for responding,
        Linda

        (0) 

Leave a Reply