Show TOC

Function documentationGovernance Application Programming Interface

 

For greater flexibility you want to be able to develop new UIs that enhance your Master Data Governance applications and are consistent with the existing software. A number of developments in the Master Data Governance Application Framework (MDGAF) allow you greater freedom to build UIs for applications.

  • Governance API

  • Convenience API

  • Application Context API

  • Communicator

  • Change Request UI Building Block (CRUIBB)

The configuration of components is shown below:

All interactions between applications and MDGAF are now handled by either the Governance API or the Convenience API. It is not possible to use the Convenience API and the Governance API at the same time for the same model. This restriction is introduced to prevent misuse of the both APIs.

Features

Governance API

The Governance API covers the entire governance process, handling processes that are not UI-related, and background services such as master data load and data replication.

The Governance API is designed to handle multiple change requests simultaneously. At any time, one instance of the Governance API can exist in the system per data model.

The Governance API also provides services to the convenience API. There is less grouping of functions than in the Convenience API so that you can combine a greater range of individual methods to meet the needs of the application. The Governance API also provides services for UI issues, but the applications access these services through the Convenience API, which then calls the Governance API.

The Governance API Class ID is CL_USMD_GOV_API (IF_USMD_GOV_API).

Convenience API

The Convenience API provides the functionality needed for an application to work with a change request. It can handle one change request for a single data model at a given time. The Convenience API takes over all governance-relevant logic such as managing change request data, handling change requests, and routing change requests to the Governance API. The Convenience API groups together some of the methods of the Governance API ensuring tighter control of the change request-handling capability available to the applications, and simplifying the use of UI services for applications. The application manages only the application data.

The Convenience API Class ID is CL_USMD_CONV_SOM_GOV_API (IF_USMD_CONV_SOM_GOV_API).

Application Context API

The Application Context API stores context-specific runtime information at a central point so that this information is accessible for other parts of the application and can be used to control the program-flow. Previously the system did not provide application context information such as what change request is being processed and whether the master data object is to be created or updated. The Application Context API provides a consistent, reliable solution to this problem.

The following context information is available:

  • Data model

  • Business activity

  • Workflow information

    • Change request

    • Change request type

    • Change request step

    • Change request index (relevant for parallel processing)

    • Workflow item

  • Application parameter data (stored in the Workflow Container, not accessed by MDG)

The Application Context API offers the following advantages:

  • Allows existing UIs to access the application context without using the complete Governance API

  • Keeps existing interfaces stable

  • Increases flexibility.

    While, for example, the Governance API or Convenience API can only be instantiated for a data model, the Context API is directly available to MDGAF components such as a UI application or background process.

  • Manages application-specific context data

    Application-specific context data is stored within the workflow container. This enables you to provide application-specific context data throughout the workflow.

The Application Context API Class ID is CL_USMD_APP_CONTEXT.

Communicator

The Communicator allows the user to work with the change request and ensures consistency of change request handling prerequisites, such as change request type, change request ID, and work item ID. When a user begins working with a change request, the Communicator recognizes missing parameters and initiates user interaction accordingly, for example, requesting the user to specify a change request type if none has yet been specified.

Change Request UI Building Block (CRUIBB)

This UI component is included in application-specific UIs and handles the presentation of change request data in Web Dynpro applications, ensuring a consistent UI layout for change request data across all applications. The CRUIBB contains data such as CR description, priority, reason for CR, notes, and attachments. Applications need to manage the application data only.