SAP Multichannel Foundation for Utilities: Implement Custom Logic for an Existing Entity

[former_member201526]

The OData Service model delivered in SAP Multichannel Foundation for Utilities is built via the Gateway Service Builder (SEGW) tool. Depending on the business needs, the Gateway service model can be extended on different levels:

1. OData entity structure extension (adding append structure with custom fields)
2. Addition of new OData entities
3. OData entity logic extension (for example, adding additional validations)

In this blog post, we will illustrate the last point, in other words, how to extend the logic of an existing entity.

In a nutshell

Behind each OData Service in the back end, SAP Gateway runtime generates a Model Provider and a Data Provider.

• Model Provider defines a structure of the model.

          It can be enhanced via the Gateway Service Builder (SEGW) transaction.

• Data Provider defines the logic of handling HTTP requests for all entities in the service model.
  It can be enhanced using the development approach introduced in SAP Multichannel Foundation for Utilities.

Please take a look at the diagram to get familiar with a standard processing for HTTP requests in the Data Provider.

To overwrite standard OData entity behavior and introduce custom logic, create a new BAdI implementation with the required filter value. This implementation is then called instead of the standard one. The BAdI definition is based on the interface IF_CRM_IU_UMC_ODATA_BADI. However, there are other interfaces that your implementation needs to support, so you should inherit from the MFU standard class. After that, your implementation can be initiated and invoked successfully by the standard Data Provider class (CL_CRM_UTILITIES_UMC_DPC_EXT).

Example with a step by step explanation

SAP Multichannel Foundation for Utilities delivers an OData Service model which returns all the service contracts for an online user. Since an online user may have many contracts, including cancelled and expired ones, the standard logic removes all those and only returns the currently active contracts. As an example, let’s say that you want to change this logic so all the service contracts will be returned for the online users, and then you can do the following:

1. Find out the current BAdi implementation
2. The current BAdi implementation can be found in Transaction SE19. Note the standard enhancement implementation name is “CRM_IU_UMC_ODATA” and the entity name is “ContractItem” which is used as filter value.
3. Write down the name of the implementation class which is “CL_CRM_IU_UMC_ODATA_CNTRITEM’ in this example.i
4. Create a custom class (say ZCL_CRM_IU_UMC_ODATA_CNTRITEM) which inherits from the MFU standard class identified in the previous step).
5. Overwrite the method “Filter_contractitem” in your custom class to introduce your custom logic.
   • This method is a protected method and it removes all the expired and cancelled service contracts, so in this example, it’s a good place to introduce your custom logic. Note that you need to compile and activate your custom class after modification, as shown below.
6. Use transaction SE19, create a new BAdI implementation for entity “ContractItem” with a filter name set to the entity name, and set the implementing class to the class that you just created.
   • 
7. Set the filter for your implementation
   • 
8. Activate and verify your new implementation is in position.
   • 
9. Test to make sure that the new implementation is called instead of the standard one. You can do that by using advanced REST client or SAP Gateway Client.
   • Alternatively, you can test as well via SAP delivered sample desktop UI application UMCUI5; now expired contracts are returned and displayed as shown in the screen snapshot below:
   •