SAP is moving to the cloud and advancing RAP, CAP, and BTP. However, certain utility T-Codes are only available through SAP GUI. Ideally, SAP should have released corresponding SAP Fiori applications for these utility T-Codes, but it seems that SAP expects its implementation partners and vendors to handle this themselves. One such frequently used T-Code is SM30. If you’re wondering how to Create SM30 Like Table Maintenance T-Code in SAP RAP, it’s important to note that once clients experience the convenience of SAP Fiori, they no longer want to revert to the traditional SAP GUI. As a result, they often request SM30 to be available on their Fiori tiles.
In this instructional exercise, we will advance Bit by bit, How to Create SM30 Like Table Maintenance T-Code in SAP RAP Relaxing Application Programming Model.
TMG or SM30 transactions are commonly known and used to maintain table entries, and they have been heavily utilized in SAP GUI. Have you ever thought about using similar functionality in SAP Fiori applications? Well, you can build it in a freestyle SAPUI5 application and use it as a Fiori app, but if you’re curious how to create SM30 like table maintenance T-Code in SAP RAP, the good news is that you can achieve a similar result without needing to write any SAPUI5-specific code. In this series of blog posts, we will explore how to develop TMG-like applications using the ABAP Restful Programming Model.
In our RAP based application, following functionalities will be achieved:
- Creation of new entries
- Deletion of existing entries
- Copy from excel and paste
- Multiple records editable in the table ( Multi In-Line Edit )
- Copy an existing record
Following features will be achievable from FIORI UI application from BAS environment:
- Inline Creation
- Skip list Page
Application in ADT Preview mode will be look like as follow:
When we click on the Alter button, all lines in the table will be editable.
Prerequisites:
- Fundamental RAP
- Information on Cds Perspectives (Definition, View Element, MetaData Augmentation)
- FIORI Components Rundown Report Format
Overview:
Essential FIORI Component based Rundown Report Application comprises of a rundown report page on which all occasions of root view element are shown. From any occasion, we can explore to its article page . Rundown of youngster occurrences can continuously be altered in multi-inline-alter mode however we can’t alter all root cases immediately as multi-inline mode. Subsequently, we want to demonstrate a root element with a solitary occurrence which will have organization to the view substance of the table for which Expert Information must be kept up with. Along these lines, table information will be editable as multi-inline on the article page. In RAP, this conduct is called Singleton.
Modeling and Publishing UI Service:
Step 1 : Data Model and BO Structure
To begin with making a RAP based help, we will characterize the Information model.
In each RAP based help, we want to characterize a root hub. In our situation, Root substance ought to just have a default single instance(to be shown as Rundown Page) and kid element ought to be planned with genuine Information Base. In this manner, we will characterize the root substance view in such a manner which would continuously return one substantial occasion naturally. Such a substance can be characterized as follow:
1. Root Entity:
- We have made the Singleton Root View Substance on standard Discs view I_Language by giving a where condition current logon framework language.
- We’ve characterized OrderSingletonID as the critical field for this root view element with default esteem as 1.
- Field LastChangedAtMax will be utilized as all out etag (to be utilized for Draft empowered application)
- Piece to kid elements has been made which would make a connection between Root Substance and Substance on the genuine DB table.
2. Child Entity:
- We have created an Interface View Entity on top of master data Table ZPBDEMO_ORDERS for which maintenance generator app will be created.
- Key field for this view is a UUID-based field so that records with the same OrderNo can be entered in draft mode.
- Additional field OrderSingletonID has been added with default value 1 so that It can be used as projection condition.
3. BO Modeling:
Next step would be to create the RAP Business Object with Transactional Behavior. Please follow the steps as below:
- Create Behavior definition(BDEF) by using context menu on the root entity created in step 1.
- Choose Implementation type Managed since we want the RAP framework to take care of CUD operations.
- Add mapping definition in child node since child entity uses different field names in the CDS view than on the database table.
- The root entity instance can never be modified. Therefore it does not need an ETag. The ETag master is defined on the child entity as
etag master LocalLastChangedAt
- For UUID in Child Entity, RAP framework can generate the IDs automatically using the numbering feature on the UUID field. Add in child node as follow:
field ( numbering : managed, readonly ) OrderUUID;
Singleton-Specific Behavior
- For Singleton behavior, we don’t need standard CUD operations on root node therefore, remove create, update, delete operations from root node.
- We need to provide persistent tables for each entity in case of Managed implementation. Since there is no persistence required for root entity due to Singleton behavior, remove persistent table and define unmanaged save for the root entity using with unmanaged save
- Provide persistent table for child entity persistent table zpbdemo_orders.
RAP framework will persist the records from the UI application in this table. We don’t need to write any specific logic for standard operations.
Draft-Specific Behavior
- Add with draft in BDEF header. It requires a draft table for each entity in the BDEF.
- Add draft table in root entity zpbdemo_sglton_d and use ADT quick fix to create it.
- Add draft table in child entity zpbdemo_order_d and use ADT quick fix to create it.
- Add total etag LastChangedAtMax in the root node as draft BO always requires a Total Etag field on the root node.
- Add the addition with draft to the associations association _Order
{create;} and association _OrderSingleton; - Define all five draft actions in the behavior definition section of the root entity.
draft action Edit;
draft action Activate;
draft action Discard;
draft action Resume;
draft determine action Prepare{ };
By projecting the draft Edit action, application will provide edit functionality on root instance even though standard update operation has been disabled.
Behavior Implementation:
In the BDEF header, we need to provide a class name. Once BDEF is defined completely, we can use ADT fix to create this class also called BIL(Behavior Implementation) in RAP. For Managed implementation, this class will be used to implement additional Determinations, validations and actions implementation.
Step 2 : Projection Layer
Projection Layer will be designed to expose the artifacts on the UI. We will create Consumption Views for root and child entity and also,a projection BO. It will project operations from base BO which requires in UI.
1. Root Entity:
- Projection View substance on view ZPBDEMO_I_SINGLETON has been made.
- Essentially, a projection view on Request view(Child Element) must be made and it ought to be added as structure for affiliation _Order
2. Child Entity:
- Projection View element on view ZPBDEMO_I_ORDER has been made.
- Add parent route on affiliation _OrderSingleton.
- Add Worth Assistance Comment on CurrencyCode to show esteem help for currencycode.
Use I_CurrencyStdVH as worth assist information with obtaining
@Consumption.valueHelpDefinition: [{entity:{ name: ‘I_CurrencyStdVH’,
element: ‘Currency’ },
useForValidation: true }]
3. Metadata Extension:
FIORI application design can be characterized in the RAP BO utilizing @UI comments.
These UI explanations are then uncovered with the metadata of the UI administration and are applied for characterizing a UI.
Metadata augmentation can be made as an expansion of Discs projection view in the event that its permitted on Albums header with appropriate explanation as:
@Metadata.allowExtensions: valid
Root Entity
- @UI.facet is utilized to make a segment for showing youngster elements (Orders)
Child Entity
- @UI.lineItem is utilized to show Table section. Position trait will be section list
- dataAction comment is utilized as type #FOR_ACTION and activity name made in RAP BO will be alloted.
- @UI.facet is utilized to show fields in sub object page for every kid occasion.
4. BO Modeling:
In the past step , we characterized the conduct meaning of RAP BO with conditional way of behaving which comprises of conduct qualities and tasks. To involve these properties in a UI application, we really want a projection of Conduct definition very much like we made for sees.
For making Projection BO, utilize the setting menu of the root projection view and select New Conduct Definition
We can utilize the default projection BO made as every one of the tasks from base BO ought to be presented to UI.
Step 3 : Defining and Publishing UI service
With past advances, we have characterized a RAP BO with conditional way of behaving and its projection curios. With this step, we will uncover as UI administration for utilization through Fiori components UI application.
1. Service Definition:
- Characterize which curios are remembered for the help normally looked at as EntitySet definition.
- For making administration definition, utilize the setting menu of the root projection view and select New Help Definition
- Incorporate projection view for the youngster element.
2. Service Binding:
- Administration Restricting is typically the OData administration which Fiori application will consume in the UI. In RAP, it’s tended to as administration restricting.
- For making administration restricting, utilize the setting menu of the help definition made above and select the suitable restricting sort.
For our application, we can pick OData V4 UI
3. Activate and Publish the service:
When administration restricting is enacted, we can distribute it and review the Fiori component application locally without making a genuine UI5 application.
- Service URL can be checked after publishing the service binding.
- Select root entity and click on Preview
- It will open the Fiori application List Page as below:
- In the wake of squeezing the Go button, It will show the Rundown record with a solitary occurrence as 1.
- Click on the main line showed and Article Page will be shown comprising Request list:
- Once Alter is clicked, we can see that every one of the occasions of the Request Support Table will be editable and Multi-Inline Alter abilities are accomplished:
- We can check that Line No. 2 and 3 are altered as inline altering without exploring to its sub object page.
- Draft Life Cycle is additionally empowered. Draft occurrence has been made and furthermore refreshed with the substance of changed cells
- Glue button from Fiori components is empowered to take the contribution from succeed.
- We can likewise make new elements, erase existing passages and glue the substance duplicated from a succeed . Overall we have accomplished to make SM30 like Fiori application in RAP with no single line of UI code.
In the following parts, we will see the expansion of approval and activity (Duplicate as usefulness), UI Application steps and Empowering inline making of the Request records.
Trust this would be helpful for you sooner or later of time. Cheerful learning!
YOU MAY BE INTERESTED IN
ABAP on SAP HANA: ATC – ABAP Test Cockpit Setup & Exemption Process
Create and Consume Business Add-in(BAdI) in ABAP
WhatsApp us