Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
parichaypatra
Discoverer
4,519
Business Scenario: - Sometimes business process requires additional validation or activity to be performed after user executes an action from an unmanaged query. It is obvious that users might need a custom screen to input certain attributes for such validation or should be able to perform additional activity only after certain criteria is met. Let us consider one such business case that deals with user substitution.

In our example below, we are creating an application via unmanaged query which facilitates users to create and activate substitutions seamlessly. ‘Create’ and ‘Activate’ appears as two actions on the table toolbar, but unlike ‘Create’, ‘Activate’ provides additional dialog (different from parameter list) for further inputs.

Diagram below shows aforesaid all business process in a nutshell.

For Un-Planned Substitution user does not need to provide any specific date range while creating the substitution.


In Part 1:  We would first create the backed data model, behavior and service using RAP unmanaged query.

In Part 2: We will create the frontend application and extension of the application in BAS.

Backend Data Models, Behavior and Service: -

To understand the technical approach better, please refer below screen (what we are trying to achieve ) .


 

  • Creating Root Custom Entity: -


First we need to create root entity ZDMO_C_SUBSTITUTE with query provider ZDMO_SUBS_QUERY_PROVIDER for the list page. As we have two separate tabs for Planned and Unplanned scenario, selectionpresentationvariants with two separate qualifiers are required. The qualifiers are required to control (example: hide or exclude ) specific fields based on scenario. For example, in case of unplanned, we do not need any specific start and end date. So these fields are to be hidden from UI.

SelectionPresentationVariant looks like this(below) :-



To control the visibility of the fields ( i.e. startdate and enddate ),the qualifiers can be utilized.


In my example, I have used almost all the fields of the persistent table in the root entity. The persistent table looks like below.


Annotation related to global filter also can be put in the root entity.

  • Abstract entities for Actions: -


To facilitate users with selection screen( import parameters) to feed necessary inputs while creating the substitute two abstract entities are created i.e. ZDMO_ABS_PLANNED ( for planned ) and ZDMO_ABS_UNPLANNED ( for unplanned ). These abstract entities are to be tagged to the actions in behavior definition.


The difference between these two entities is only that Unplanned does not have startdate and enddate.

  • Implementing Query Provider Class: -


The implementation of query provider class is simple. Only important point is to identify and distinguish between two scenarios. For that we have set selectionVariant for each qualifier in the root entity as below.


Upon selection of the tabs, these values are passed to the select method of the query provider.

 




  • Behavior Definition: -


We have now created unmanaged behavior for entity ZDMO_C_SUBSTITUTE. Two actions are created for creating planned and unplanned substitutions for subsequent tabs on the list page.


Static function EnableSubstitution is created for the function import with a return structure as the entity. Result is required to send the updated data back to front end after the batch call is completed.

A Note: Visibility of the Actions can be controlled via qualifier from root entity.




  • Behavior Implementation: -


Create Planned & Unplanned Action: -




The only difference between the planned and unplanned action method is that the later does not require validation for dates and the substitution type is different.

Enable Substitution:-

As Can be seen below, results table is population with the updated records.




  • Service Definition & Binding:-


Once we are done with the behavior implementation, let us create the service definition


and then the service binding.


 

Preview gives us the basic overview of the application and confirmation that the service is working fine.


Now we will proceed to the next part, where we will create the application in BAS and extension to implement the function import, we created in previous steps.

Please share your feedback/comments and be connected for any query.

More on this topic, you can refer to below links:-
- Q&A
- Blogs
1 Comment
Labels in this area