SAP Community - NW ABAP Gateway (OData)

Problems with zero dates

2023-04-13T12:27:08+02:00

Introduction:

There is a very common problem, that while doing a post request or any kind of update containing empty dates are not allowed by default via SEGW based OData-Services.

How to enable this is described here: DateTime field in OData entity – Points to take care when the UI is throwing run-time error. | SAP Blogs

Problem:

But maybe you struggle here anyway, even when using the workaround as described before - but why? Take a look here at the column DEL_DATE:

It looks fine in the ADT Data-Preview, even if 0000-00-00 is not a very nice date.

But testing the OData-Service based on this CDS View returns an error "the Value ____ is no valid Date according to XML-formats for ABAP":

Error in /IWFND/ERROR_LOG

Rescue from the past - thank you SE16:

The solution can be found via our old tooling like the good, old SE16 - here we see the true value of DEL_DATE:

The field does not contain any value - its empty, space or even null, but not 0000-00-00 as shown in ADT! And "space" or "empty string" can't be interpreted as a date! How to fix it? Simply extend your CDS with an easy CASE-Statement, that sets a value OData can handle - like the one mistakenly shown in ADT:

define view entity ZABC

  as select from toa01

{

  key sap_object                 as SapObject,

      @UI.hidden: true

  key object_id                  as ObjectId,

      @EndUserText.label: 'Content Repository'

  key archiv_id                  as ArchivId,

  key arc_doc_id                 as ArcDocId,



      case del_date

      when '' then '00000000'

      else del_date end          as DelDate

}

This should normally not be necessary and is clearly due to a program error, but still: some kind of solution.

Enjoy!

RAP EML Dynamic Operations: Dynamic EML Requests

2023-06-05T11:46:19+02:00

Introduction

In the world of ABAP development, the RAP framework has revolutionized the way we build robust and flexible applications. One of the key features of RAP is the ability to dynamically generate EML (Entity Manipulation Language) requests. In this blog post, we will explore the dynamic form of MODIFY ENTITIES OPERATIONS, which allows us to perform operations on multiple business objects within a single statement.

Understanding MODIFY ENTITIES OPERATIONS

The MODIFY ENTITIES OPERATIONS statement in RAP enables us to manipulate entities by performing various operations such as CREATE, UPDATE, DELETE, or EXECUTE (Actions). What makes the dynamic form of this statement particularly powerful is its ability to handle operations on multiple business objects simultaneously. Operations expects an internal table of the type ABP_BEHV_CHANGES.

The ABAP Documentation you can find here: https://help.sap.com/doc/abapdocu_754_index_htm/7.54/en-US/index.htm?file=abeneml_modify_entities_op.htm

Here you will find my example in the business partner context (based on the CDS root view entity I_BusinessPartnerTP_3).

DATA:

  _BP_ROOT           TYPE TABLE FOR CREATE I_BusinessPartnerTP_3,

  _BP_ADDRESS        TYPE TABLE FOR CREATE I_BusinessPartnerTP_3\_BusinessPartnerAddress,

  _BP_IDENTIFICATION TYPE TABLE FOR CREATE I_BUSINESSPARTNERTP_3\_BusinessPartnerIdentification,

  _BP_ADDRESS_USAGE  TYPE TABLE FOR CREATE I_BusinessPartnerAddressTP_3\_BusinessPartnerAddressUsage.



MODIFY ENTITIES OPERATIONS

  VALUE ABP_BEHV_CHANGES_TAB(

    ( VALUE ABP_BEHV_CHANGES(

        OP = IF_ABAP_BEHV=>OP-M-CREATE

        ENTITY_NAME = 'I_BUSINESSPARTNERTP_3'

        INSTANCES =  REF #( _BP_ROOT )

    ) )

    ( VALUE ABP_BEHV_CHANGES(

        OP = IF_ABAP_BEHV=>OP-M-CREATE_BA

        ENTITY_NAME = 'I_BUSINESSPARTNERTP_3'

        SUB_NAME = '_BUSINESSPARTNERADDRESS'

        INSTANCES = REF #( _BP_ADDRESS )

    ) )

    ( VALUE ABP_BEHV_CHANGES(

        OP = IF_ABAP_BEHV=>OP-M-CREATE_BA

        ENTITY_NAME = 'I_BUSINESSPARTNERTP_3'

        SUB_NAME = '_BUSINESSPARTNERIDENTIFICATION'

        INSTANCES = REF #( _BP_IDENTIFICATION )

    ) )

    ( VALUE abp_behv_changes(

        op = if_abap_behv=>op-m-create_ba

        entity_name = 'I_BUSINESSPARTNERADDRESSTP_3'

        sub_name = '_BUSINESSPARTNERADDRESSUSAGE'

        instances = REF #( _bp_address_usage )

    ) )

  )



  MAPPED DATA(_MAPPED)

  REPORTED DATA(_REPORTED)

  FAILED DATA(_FAILED).

The Structure of Operations

Operation Structure

Important: The name/value of ENTITY_NAME and SUB_NAME should be in upper case. Otherwise you will get an unknown shortdump. This seems to be a bug in the standard SAP operation. Normally the upper case conversion could be done in the standard functionality.

But how should the instances (here e.g. _bp_root, _bp_address) be filled?

Instances

The %cid attribute is the content ID which are used as unique and temporary ID for RAP BO Operations. In this case, we assign the %cid "bp_root" to the root object, which must be assigned as %cid_ref for the underlying object address.

The attribute %data is self-speaking for the transfer of the data to be created.

"Usual" equivalent

This would be the "usual" equivalent of the dynamic EML call:

MODIFY ENTITIES OF I_BusinessPartnerTP_3

  ENTITY BusinessPartner

    CREATE

      SET FIELDS WITH _BP_ROOT

    CREATE BY \_BusinessPartnerAddress

      SET FIELDS WITH _bp_address

    CREATE BY \_BusinessPartnerIdentification

      SET FIELDS WITH _bp_identification

  ENTITY BusPartAddress

    CREATE BY \_BusinessPartnerAddressUsage

      SET FIELDS WITH _bp_address_usage

  MAPPED DATA(_mapped)

  FAILED DATA(_failed)

  REPORTED DATA(_reported).

Dynamic Flexibility

One of the significant advantages of using the dynamic form of MODIFY ENTITIES OPERATIONS is the flexibility it offers. By allowing operations on multiple business objects within a single statement, developers can streamline their code and enhance efficiency. It eliminates the need for repetitive operations and simplifies the overall development process. It offers the possibility to create a generic EML concept in case of dynamic requests regarding the operation (CRUD) or the entity or associations.

Conclusion

In this blog post, we delved into the dynamic form of MODIFY ENTITIES OPERATIONS. Leveraging the power of RAP's dynamic EML requests opens up new possibilities for building advanced applications in ABAP development. By harnessing this flexibility, developers can achieve greater productivity and maintainability in their projects. So, go ahead and explore the dynamic world of RAP EML Dynamic Operations and take your ABAP development to the next level!

Overcoming Technical and System Constraints: Exposing an ABAP Calculated Field with OData

2023-07-06T13:18:30+02:00

Firstly, the requirement of this post was originated from quite a basic problem; however it later became really complicated due to the following constraints which we were restricted to.

technical constraints of ABAP CDS object

SAP system constraints in terms of the technology stack and version

Let me first talk about the actual requirement and then I will write down all the possible solutions I tried out and why I ended up with the current one. Our initial requirement was to expose an SAP field with OData and consume it from a Fiori application. This field was the well-known WBS element field, which is a concatenation of a couple of other fields separated by a '-' symbol. Of course, I was supposed to split this field into different strings and extract the components of the original field. It might sound like a problem with a quite straightforward solution. However once I started researching to find out the possibilities, it was quite frustrating.

Of course, I started with the CDS built-in functions. I have checked them and find out a couple of useful functions including "instr", "substring", "left" etc. However, none of them has completely resolved our problem without certain assumptions (making an assumption on the number of characters for each part of the string for instance). Therefore, unfortunately there is no built-in function, which we could utilize to split up a string into multiple strings at a certain character, '-' in our case.

Second option I came up with was to use some of the powerful tools in ABAP stack, for instance, CDS table function or AMDB, that I can plug our custom ABAP code. That way, I could enhance/enrich our CDS object with some custom ABAP coding, which contains the ABAP command SPLIT ... AT ... INTO ...

@AccessControl.authorizationCheck: #NOT_REQUIRED

@EndUserText.label: 'Demo Table Function Parse'

@ClientDependent: false

define table function Z_DEMO_TF_PARSE_WBS

    returns {   

                wbs_element   : string40 ,

                component1    : string10  ,

                component2    : string10  ,	

                component3    : string10  ,					

            }

                implemented by method

                Z_Cl_AMDP_PARSE_STRING=>SPLIT;

That way I planned to implement the parsing of the WBS string with custom Z_Cl_AMDP_PARSE_STRING class. Unfortunately, that also did not work out because our system had a SAP_ABA 750-0010 component version, which this feature is not yet supported.

The final option I could think of was to manually add an extra implementation into the OData runtime artifacts, which was generated by adding the CDS as a reference object to the SEGW service.

I did that extra implementation inside the data provider extension class. In order to implement the parsing of WBS field, I should have first created dummy fields in my CDS object, which was only possible with the CAST command. Hence, I extended my CDS view with the three field from the result of parsing.

@AbapCatalog.compiler.compareFilter: true

@AccessControl.authorizationCheck: #NOT_REQUIRED

@AbapCatalog.preserveKey: true

@EndUserText.label: 'Demo CDS Parse'

@VDM.viewType: #BASIC



define view Z_DEMO_CDS_PARSE_WBS as select from prps

  {

     key wbs_element ,

     cast(' ' as abap.char(3) )  as component1  ,   

     cast(' ' as abap.char(10) ) as component2  ,     

     cast(' ' as abap.char(8) )  as component3        

   }

Afterwards I started to overwrite some of the methods of the DPC_EXT class, which were necessary for my requirement. For instance I implemented the custom logic to split the WBS by overwriting the GET_ENTITYSET method of the respective CDS entity. This method already has a reference to the super method inherited from DPC class. Because the SEGW service was built on top of the reference to the data source which points to the CDS view. I preserved it and finally added my extra code to split the WBS element and hence the returned entity set is updated.

  METHOD Z_DEMO_CDS_PARSE_WBS_GET_ENTITY_SET.

    TRY.

        CALL METHOD super->Z_DEMO_CDS_PARSE_WBS_GET_ENTITY_SET

          EXPORTING

            iv_entity_name           = iv_entity_name

            iv_entity_set_name       = iv_entity_set_name

            iv_source_name           = iv_source_name

            it_filter_select_options = it_filter_select_options

            is_paging                = is_paging

            it_key_tab               = it_key_tab

            it_navigation_path       = it_navigation_path

            it_order                 = it_order

            iv_filter_string         = iv_filter_string

            iv_search_string         = iv_search_string

            io_tech_request_context  = io_tech_request_context

          IMPORTING

            et_entityset             = et_entityset

            es_response_context      = es_response_context.

      CATCH /iwbep/cx_mgw_busi_exception .

      CATCH /iwbep/cx_mgw_tech_exception .

    ENDTRY.



    LOOP AT et_entityset REFERENCE INTO DATA(lr_entityset).

      SPLIT lr_entityset->wbs_element AT '-' INTO lr_entityset->component1

                                                  lr_entityset->component2

                                                  lr_entityset->component3.



    ENDLOOP.



  ENDMETHOD.

I want to emphasize a few points what I have learned from the solution of this issue.

Whenever CDS toolset is not adequate for my requirement , I can still use CDS to expose data by referencing it as data source and then exploit the DPC_EXT class to implement own coding. This makes it a hybrid solution whereas on one hand, I can take advantage of CDS features (performance, annotations etc.) and on the other hand, I can still make manual interventions to the entity set that I expose through OData by overwriting the related DPC_EXT class methods.

Second thing is that CAST operator is the only option to create dummy fields since CDS is not a database object but actually a view on real database objects. This could be its side role in addition to its actual role, which is casting some data types into some other types.

Performance testing of Independent OData using HDB

2023-07-21T05:50:10+02:00

Hello ,

This blog will walk you through the concept of

Performance Improvement: $batch Parallelization

The performance optimizations for $batch processing described here are only available for a hub system NW release 7.0x or 7.3x SP08 or NW release 7.4x SP06 and backend system NW release 7.0x or 7.3x SP08 or NW release 7.4x SP06.

In older support package stacks, the SAP NetWeaver Gateway framework issues one separate Remote Function Call (RFC) for each retrieve operation or each change set.

In the newer support package stacks described above only one RFC is used to send all operations contained in a batch request to the backend system (batch at once). Due to the till now implementation of the etag handling in the REST/OData library and gateway framework, all modifying operations using etag in a batch request are delivered separately to the backend system. Based on the configuration settings in the backend system (via IMG, transaction SPRO see below), all consecutive retrieve operations are parallelized to improve the processing performance. The parallelization is active per default.

The processing performance increases with more number of consecutive retrieve operations in a $batch request.

The following performance trace summary shows the performance statistics and also illustrates how a $batch request is processed in the backend system.

The $batch example contains

3 consecutive retrieve operations

1 changeset with create, update and execute action

2 consecutive retrieve operations

1 changeset with delete

1 single retrieve operation

From within a backend system you can use the SAP project reference object (transaction SPRO) to activate or deactivate the parallelization as follows:

SPRO -> SAP Reference IMG -> SAP NetWeaver -> Gateway Service Enablement -> Backend OData Channel -> Configuration Settings -> Define Parallelization of Batch Queries.

Changesets in Multiple Origin Composition

Changeset is a collection of one or more modifying operations having the feature "all or nothing" when processing (same meaning as Logical-Unit-of-Work in an ABAP system).

Multiple Origin Composition (MOC) is the ability to collect data from different backend systems, aggregate them in one single service and updating different backend systems while using the same user. Thus a service can be made available for several system aliases.

In the context of multiple origin composition, not only retrieve operations such as read entity, read entityset but now also changesets are supported. All operations of a changeset must be defined for one and the same system alias (SAP__Origin=<xx...x>). They are collected and sent to the backend defined by the system alias and via one RFC. You can find an example in SAP Note 1890049.

A changeset containing operations for different system aliases will be terminated with error text "Changeset containing different system aliases not supported".

SAP Fiori Apps are based on OData Services, One SAP Fiori application shall have one dedicated OData Service.

We continuously thrive to optimize Fiori applications/. functionality to run within sub-second timeframe which generates huge value addition to our customers when using SAP software to run their critical business scenarios

Developers who wish to develop new OData can easily run performance tests on their local Env to validate prior to pushing it into new/existing development or publishing it to SAP API Hub. During the test/delivery phase this solution/framework will have flexibility to configure the tests and then ODATA services are fired according to the user scenarios.

To independently measure the Performance of an OData for S4HANA to build faster optimized applications : this solution approach through an application facilitates to automatically identify and performance test OData independently during a release. It can further be leveraged to be used only by Developers who are interested to test only API class use cases. The results of performance metrics are validated against the defined thresholds

The parameters used in sap-statistics=true ( response headers of the HTTP request)

SAP NWGateway (OData request processing)

GW Total = gwtotal

GW DB= gwappdb

App time = gwapp

Other metrics

E2E Client time = Client specific time

Content length

Status: Calculated after the excel is generated

Sample values:

"totalTime":"44","count":1,"elapsedTime":249,"icmTotal":"58","wdTotal":"63","gwapp":"10","gwappdb":"","contentLength":"556"

Solution (iTOP 1.0)

iTOP : independently test OData Performance

As users constantly need to validate the performance of an OData prior to deployment/during development our implementation addresses this requirement. The solution works together seamlessly and offers a consistent end-to-end experience.

OData calls are executed for these iterations = Main runs (10) + Buffered runs (3)

To test an OData call which leads to Performance identification, developers can start with this solution which helps them in identifying or pointing towards RCA

The proposed model captures ODataServices automatically under test

Users have a provision to add new OData/modify any existing

The resulting performance metrics are validated against the thresholds and rendered back to UI and downloaded as an Excel

Identify and Report OData behaviour across releases

Fiori PO Approver app Forward button customization from ECC backend

2023-08-25T22:43:06+02:00

Hello Fellow Developers,

Let me directly dive into the requirement, We are currently hosting Fiori on top of ECC backend. The requirement came while enabling the PO approval using My Inbox.

The first part of customization comes on the Forward Button. As per the approval matrix the approvers were maintained in the PPOME structure. The problem occurred when the approver was forwarding the PO to another approver. However, on clicking the Forward button it was displaying all the list of Users from SU01. This was creating a lot of confusion for the approvers. So the initial requirement came as to fix the list that was appearing on clicking the Forward Button.

I will be displaying the 2 possible approach for Forward Button customization from the Backend.

Approach 1 – Creating the custom class and attaching it in Service Implementation.

Approach 2 – Implement the BADI to change the values fetched from the Standard.

Let’s start with the first approach.

The standard ODATA for PO approval is GBAPP_POAPPROVAL.

Step 1 . Open your Gateway system -> Execute /IWBEP/REG_SERVICE and maintain the service details

Step 2 Maintain the Class name in DPC.

Note : Creating of the class would be in the Backend System

Step 3 Open Backend System and Create the class maintained in Gateway system.

You can copy/maintain the redefinition of the methods as per your need. Super class should be maintained as the /IWBEP/CL_MGW_PUSH_ABS_DATA. This will redirect the data flow of standard Odata call into the Custom Implementation.

I have copied all the methods from the standard class into my custom class to avoid any discrepancies. My requirement is also very small that’s why I didn’t wanted to touch other functionality so copying worked for me.

Just for showing from where the whole list of users were displaying. Please follow through as this is kind of RCA.

If you drill down into the GET_ENTITYSET. You may find this
WHEN cl_gbapp_apv_po_mdp=>cty_entities-agent.

This gets triggered for the event of Forwarding the work item to another approver. However, if you go into GET_AGENT_LIST method. You may find

CALL METHOD lo_cmn->get_users_for_forwarding.

This method is responsible for displaying all the lists of user from SU01 which is kind of misleading in our case.

Step 4 Modify the Approver List

So to suffice this requirement you can write your own logic and bypass the GET_AGENT_LIST method at the following place and the new list will be forwarded to the UI again as the output.

Create the list of approvers which you want to show and pass the list in lt_forward_users.

This is a long way approach where a lot of customization can be done as per your requirements.

Approach 2 – BADI Extensibility Approach

Normally for any custom enhancements we can directly enhance the ODATA however for the case of PO Approver app SAP has provided an option for BADI Extensibility for PO Approve application.

Step 1

Go to SE18 in the backed system.

Step 2 Create Implementation under Definition GBAPP_APV_PO_RDP

If you are not familiar with creating implementations follow through / skip to next step.

Right click on implementation -> Create Badi Implementation -> Specify the Enhancement Implementation & Short Text.

Once you specify the Enhancement Implementation system will ask for BADI Implementation.

Maintain them.

Note : You can reuse the same enhancement implementation for other requirements as well related to PO approve applications extensibility . No need to create every time.

Step 3 – Implementation of Class

In the Implementing class you may find all the lists of methods present.

The first method IF_GBAPP_EX_APV_PO_RDP~CHANGE_AGENT_LIST_API is the one which is used to modify the list of Approvers. Modify this method as per you requirement.

Incase of my requirement the approvers were maintained in PPOME under the Organizational structure. The data is maintained in HRP1001 table. I have deleted the approvers which are not maintained in PPOME here .

It is easier to go for 1st approach however I chose this because there are furthermore modification as part of different requirement in various methods present here. So I thought to consolidate all my changes at once for ease of understanding.

METHOD IF_GBAPP_EX_APV_PO_RDP~CHANGE_AGENT_LIST_API.
* Intended use:
* Customer uses the BAdI Enhancement Framework for own content / logik

* Here you can change/enhance the data, which is retrieved for the GET call for
* the results list of the Search for Forwarding Agents.

* Note:
* If you want to have a employee image to be displayed on the UI list
* of Forwarding Agents you need to do the following steps.
* - In this method:
*   Fill the field MIME_TYPE with the MIMETYPE of the image.
*   This will trigger the execution of method 'get_image_binary_file'
*   for retrieval of the binary data for the image.
* - In method 'get_user_image_binary_file':
*   Implement the retrieval of binary image data.
*  BREAK-POINT.
TYPES : BEGIN OF gty_usr,
SOBID TYPE HRP1001-SOBID,
END OF gty_usr.

data : lwa_user TYPE GBAPPS_APV_USER_FORWARDING,
lwa_ppome TYPE hrp1001,
lt_ppome TYPE STANDARD TABLE OF hrp1001,
lt_usr TYPE STANDARD TABLE OF gty_usr,
lwa_usr TYPE gty_usr.

LOOP AT ct_user INTO lwa_user.
lwa_usr-SOBID = lwa_user-USER_ID.
APPEND lwa_usr to lt_usr.
CLEAR lwa_usr.
ENDLOOP.

select * from hrp1001 into TABLE lt_ppome FOR ALL ENTRIES IN lt_usr
where SOBID = lt_usr-SOBID.

sort lt_ppome by SOBID.

LOOP AT ct_user INTO lwa_user.
READ TABLE lt_ppome INTO lwa_ppome with key SOBID = lwa_user-USER_ID BINARY SEARCH.
IF sy-subrc ne '0'.
delete ct_user where USER_ID = lwa_user-USER_ID.
*        delete ct_user from lwa_user.
ENDIF.
ENDLOOP.

ENDMETHOD.

This is a Series of Blogs. Please find the below post for further details.

Part 2 : Accept & Reject Button Customization

Amount field decimal places display issue in Fiori Elements list report

2023-09-06T15:49:32+02:00

Background:

SAP generally stores all the amount values with two decimal places in tables like VBRP, VBAP and so on. This is because most of the currencies have 2 decimal places by default. But there are a lot of currencies that have decimal places no equal to two. Mostly for large currency markets, the default number of decimal places for the currency is not 2.

For example, for VND (Vietnamese Dong), the default number of decimal places is 0 and this is stored in the table TCURX.

For example, a billing invoice (with currency VND) has net value with 0 decimal places, but it is stored with 2 decimal places in SAP Table VBRP because SAP shifts the decimal place in tables so as to not change the data type of the amount and maintain a standard throughout SAP.

This invoice has no decimal places for VND but below shows how it is stored in SAP table.

Moreover, when we display this amount in a Fiori elements list report through a CDS view or normally it displays with 3 decimal places by default.

Issue: Display the amount according to the correct decimal places as maintained in TCURX table in the list report

Solution:

Create an extra entity in your OData service (CDS data source). The data source exposed should be I_CURRENCY, an SAP standard CDS View.

This CDS view has the number of decimal places for currencies maintained in TCURX table.

Add the same CDS view I_Currency in your main data source CDS view as an association.

Add a foreign key annotation for the above association to the currency field in the main CDS View.

Do not forget the add the annotation @Semantics.amount.currencyCode: 'waerk' to your amount field.

Last step would be to add the below annotation to your annotation file in your Business Application Studio List report project.

</Record>

</Annotation>

</Annotations>

The list report will now show the appropriate number of decimal places in the Amount field along with the Currency.

For example, it shows 0 decimal places for VND now.

SAP EarlyWatch Alert Dashboard - New statistics about "Used SAPUI5 Applications"

2023-09-11T08:59:40+02:00

New content has been released for the User Experience section of the EarlyWatch Alert (EWA) Dashboard!

Several weeks ago we already extended the chart "Usable SAPUI5 Applications" with an additional default view about the number of used applications. You still have the option to switch to the legacy statistics regarding the number of configured apps by selecting 'Number of Activated Apps in the last 5 weeks' from the dropdown menu:

Alongside these enhancements, the chart now includes an additional button, providing you access to our new detail page where you can gain valuable insights into the UI5 Fiori apps in use.

The new page follows the familiar structure found in the 'OData Service Requests' or 'Transactions' detail pages:

The statistics for the selected apps in the table are represented as a line on the right side of the page. For each app, you can display the number of OData requests, the average OData request time, and the number of distinct users. You can easily switch between these three measured values in the line item chart using the dropdown field.

You can utilize the filters in the page header to narrow down the list of displayed apps. It's important to note that the current 'SAP Standard Business Role' filter includes standard business roles through which SAP standard apps are distributed, rather than customer-specific roles. We are in the process of replacing this filter with a more appropriate custom role filter.

The 'Application Name' and 'Fiori ID' columns are equipped with clickable links. Clicking on the 'Fiori ID' will direct you to its corresponding entry in the Fiori Apps Reference Library. On the other hand, clicking on the application name will open a pop-up window containing supplementary details such as its Application Component, ICF Service, and SAP Standard Business Role.

Clicking the 'OData Service Details' link will open the 'OData Service Requests' detail page, where you will find specific details related to the selected app.

IMPORTANT for SAP on-Premise and SAP S/4HANA private cloud systems:

The accuracy of the statistics displayed on the page improves as your ST-PI and ST-A/PI versions increase.

We strongly recommend applying the latest version of SAP Note 2603238.
If the metric for the number of distinct users is missing, then check in the chapter "Service Preparation Check (RTCCTOOL)" of the latest SAP EarlyWatch Alert Report if the usage of Online Data Collectors is allowed. Setting the permission for this type of collector is explained in SAP note 69455 .

IMPORTANT for all system types including SAP S/4HANA Public Cloud:

As some applications utilize the same OData service and ICF service, it may not always be possible to identify app usage with complete precision. To address this, we have introduced aliases for such apps. For example, several non-identifiable Smart Business (KPI) apps have been designated as 'Smart Business Runtime App'. Please refer to SAP KBA 3441199.

How to modify filters in GATEWAY DPC EXT class before GET ENTITY_SET

2023-09-26T23:35:57+02:00

In some cases we need to modify the filter options in DPC EXT class before it execute GET ENTITY_SET method,

so how to modify the filter options and make them work? follow the following steps:

( you could find sample code in class method /US4G/CL_METERREAD_DAT_DPC_EXT => XUS4GXC_METERR02_GET_ENTITYSET and /US4G/CL_METERREAD_DAT_DPC_EXT => XUS4GXC_MALO_MEL_GET_ENTITYSET )

1) cast the object io_tech_request_context to type of /iwbep/cl_mgw_request:

DATA(lo_tech_request_context) = CAST /iwbep/cl_mgw_request( io_tech_request_context ).

2) get the structure of request details by calling lo_tech_request_context->get_request_details( ) into a local structure ls_request_details:

DATA(ls_request_details) = lo_tech_request_context->get_request_details( ).

3) writhe your own logic to construct filter options, and fill them into structure ls_request_details-technical_request-filter_select_options,

important: clear the structure ls_request_details-technical_request-filter_expressions ls_request_details-technical_request-filter_functions if your are query root entity;

clear the structure ls_request_details-technical_request-navigation_path if your are query a navigation entity set to avoid query root entity again.

them must be cleared otherwise the modified filters won't work.

*** modify the structure ls_request_details-technical_request-filter_select_options *** 

CLEAR cs_request_details-technical_request-navigation_path. 

CLEAR: cs_request_details-technical_request-filter_expressions, cs_request_details-technical_request-filter_functions.

4) create an new lo_model object by calling method /iwbep/cl_mgw_med_provider=>get_med_provider( )->get_service_metadata, passing the service name and version:

DATA(lo_med_provider) = /iwbep/cl_mgw_med_provider=>get_med_provider( ). 

DATA(lo_model) = lo_med_provider->get_service_metadata( 

  EXPORTING iv_internal_service_name = '****SRV' 

            iv_internal_service_version = '0001' ).

5) create an new lo_new_tech_request_context by using constructor of class /iwbep/cl_mgw_request, and passing the ls_request_details and lo_model:

ro_tech_request = NEW /iwbep/cl_mgw_request( 

  ir_request_details = REF #( is_request_details ) 

  it_headers = VALUE #( ) 

  io_model = CAST #( lo_model ) ).

6) finally pass the new object lo_new_tech_request_context to super class's GET ENTITY_SET method:

TRY.

        CALL METHOD super->xus4gxc_malo_mel_get_entityset

          EXPORTING

            iv_entity_name           = iv_entity_name

            iv_entity_set_name       = iv_entity_set_name

            iv_source_name           = iv_source_name

            it_filter_select_options = it_filter_select_options

            is_paging                = is_paging

            it_key_tab               = it_key_tab

            it_navigation_path       = it_navigation_path

            it_order                 = it_order

            iv_filter_string         = iv_filter_string

            iv_search_string         = iv_search_string

            io_tech_request_context  = lo_new_tech_request_context

          IMPORTING

            et_entityset             = et_entityset

            es_response_context      = es_response_context.

      CATCH /iwbep/cx_mgw_busi_exception.

      CATCH /iwbep/cx_mgw_tech_exception.

    ENDTRY.

SAP API OData Security Part I - Terminologies

2023-10-04T23:39:49+02:00

This blog series will explain how to secure your outbound OData services (created in SAP ABAP system) with the Basic and OAuth 2.0 authentication mechanism.

Assumptions:

You have an overview understanding on Fiori OData Service

You have a basic idea to create roles and how to add IWSG & IWSV services. If not please follow this document

How to create user in SU01 and assign roles. Follow this blog

Part I is about general terminology used in OData/API authorization.

Part II gives you details on basic authentication and the flavor of OAuth mechanism.

Part III will guide you to the OAuth2.0 Authorization Code Flow setup.

In today’s rapidly changing world, the need for sustainability and security has grown exponentially. Companies need to create an ecosystem where their codes or developments are interchangeable across the application, or you can say the code should be so robust that it should be as easy as plug and play. Well, SAP ABAP ECC, S/4 systems are not far behind such development by using its component SAP Gateway Foundation SAP_GWFND with OData protocol.

What is OData →

The Open Data Protocol (OData) is an open protocol, which allows the creation and consumption of query-able and interoperable RESTful APIs in a simple and standardized way. Retrieval and modification of data is done with URL based service calls. They can be easily built and used.

What is API →

API stands for application programming interface, which is a set of definitions and protocols for building and integrating application software. APIs let your product or service communicate with other products and services without having to know how they’re implemented.

Question1: How is API different from SAP web services which are available under SICF from ages.

A web service is a software component that can be accessed and facilitates data transfers via a web address. Because a web service exposes an application’s data and functionality to other applications, in effect, every web service is an API. However, not every API is a web service.

APIs are any software component that serves as an intermediary between two disconnected applications. While web services also connect applications, they require a network to do so. Where some APIs are open source, web services are typically private and only approved partners may access them.

Though there are different types of API’s available, but we would talk about REST API. Reason being OData model is built on RESTful API.

What is REST →

REST (REpresentational State Transfer) is a software architectural style that defines how to send messages between two different systems using the HTTP protocol. REST defines a set of functions like GET, POST, PUT, DELETE, etc. that clients can use to access server data using HTTP.

OData builds on top of the REST framework to define best practices for building REST APIs

Well, we spoke some terminology and definitions (received from various sources) but don’t limit yourself to explore more on such. I’m trying to make this blog series as much crisp I can.

How to create REST API in SAP →

It is same as creating OData services under SEGW transaction. With my experience an ABAP or Fiori Developer will help you create one. Although its not a rocket science, being a naïve, you can create a basic SAP API on your own. You can follow other blogs available over web however I found this as easiest.

Now, lets go bit technical and focus on our agenda to secure OData Service

How to secure OData Service / SAP REST API →

When we call about security SAP always believe to secure its user logins in two ways – One with Authentication and other with Authorization. At this stage, I’m believing you understand the difference between two.

Let us see how authorization & authentication is setup in SAP for OData Services in next series with a use case.

SAP API OData Security Part II - API Basic Authentication

2023-10-10T22:43:54+02:00

Welcome to the second part of our SAP API Security journey. If you want to learn more about terminology, I recommend you read Part I.

Today, we take it a step further. In this installment, we will accelerate into the practical applications with a Use Case.

Use Case: ASDF, a pharmaceutical company, wants its customer to create records in its custom table ZOVBAK using an external tool or application via API. The development should meet these minimum criteria:

Since ASDF has various customers around the world, the development should be robust enough to create records in the ZOVBAK table using one or more applications.

For the ASDF company, the ZOVBAK table is critical, so only authorized and authenticated users are allowed to create records.

Created OData service and add service under /iwfnd/maint_service transaction. For this exercise we created ZTEST_API_TEST_SRV service. The purpose of this service is to update a custom table record ZOVBAK in local SAP system

Figure 1: Activate and Maintain OData Service

Authorization → As we know, we grant permissions to users of SAP in the form of roles. At this stage, we only need to create two roles:

Authorization to modify the table ZOVBAK Table

Figure 2: SAP PFCG Role to maintain ZOVBAK Table

Authorization to access the OData service ZTEST_API_TEST_SRV

Figure 3: SAP PFCG Role to access OData service

So we have created minimum authorization to provide to a user in order to perform action in table ZOVBAK.

Authentication → API supports various Authentication, and each have its own pros & cons however I would be covering Basic Authentication mechanism and OAuth 2.0 mechanism in this series.

Basic authentication is an HTTP-based authentication approach and is the simplest way to secure REST APIs. It uses a Base64 format to encode usernames and passwords, both of which are stored in the HTTP header. This is an effective approach to set up various API access credentials when the priority is for an application to remain lightweight and simple.

Before I explain OAuth2.0 mechanism, lets deep dive under Basic Authentication –

Let’s look at the use case again: Criterion #1 is met by using Basic Authentication, where the developed API is robust enough to connect to any end application that supports REST. Let us assume Mr. John Doe, ASDF's non-technical customer, is given a front-end application (for this exercise, let us assume it's Microsoft SharePoint). He is expected to enter the required details into MS SharePoint so that records are created in the ZOVBAK table.

For such a configuration, the SharePoint developer asks for generic SAP user credentials that will be used to perform the action in SAP on behalf of the user or, say, Mr. John.

Question 2: Why is a generic user used and why not Mr. John his SAP account?

Basic authentication requires you to pass application’s usernames and passwords (see Basic Authentication Definition) in header with Base64 encoding.

If Mr. John’s SAP account is used, the SharePoint application must store Mr. John’s SAP credentials to encrypt and send in the header. The same is true for all other business users who will use the SharePoint application to update SAP table. Remember that each business user must enter their SAP credentials into a form and that the SharePoint application stores them, encrypts them, and then sends them to the API in the HTTP header. It is very riskier that the SharePoint admin can get hold of the users' SAP credentials of users and misuse it.

Created ‘APPUSER01’ generic system user (GUI login not possible) with the access we created to run OData service successfully.

Figure 4: Basic-Authentication Generic user SAP profile

In the SharePoint application, let us look at the configuration for calling and sending information from SharePoint to SAP. (You can also use Postman to make calls to SAP API).

Now, the logical or configuration part of SharePoint is done in the Microsoft Power Automate tool. Just don’t get carried away by the name, since you are in SAP and don’t have to worry about configuring the front application. However, the most important part is the HTTP connection. In the given use case, we will perform GET & POST operation.

Figure 5: Microsoft Power Automate workflow Configuration

GET operation is to view information from given API. POST operation is used when you want to create a new data to API application.

There is additional validation stein in POST operation along with Basic Authentication to pass x-csrf-token value in header and this token expires after certain duration. Easiest way to retrieve x-csrf-token is from GET operation and the retrieved value needs to pass in POST operation.

Mr. John is equipped with a SharePoint front-end application. He has entered the following data:

Figure 6: Microsoft SharePoint Form to maintain ZOVBAK Table

Field Label Vbeln is key attribute in OData service and same in SharePoint we have set it as mandatory field. As soon user Save the information the Power Automate workflow will trigger the logic –

Figure 7: Microsoft Power Automate workflow real time flow result

In API you get various status code which helps to troubleshoot. Status ‘201’ means ‘Created’

Let’s see in SAP Table –

Figure 8: SAP ZOVBAK Table entry

You may notice that the remark entered in SharePoint form is different from the one that appears in SAP. Let’s explore the reason while understanding the OAuth logic.

With this, we have established that the #1 criterion of the use case for the ASDF company is met. But now there is an additional requirement, i.e. #2, to be met - only authorized & authenticated user only should be allowed to create records.

With the basic authentication mechanism, the information is posted from a generic account, causing SAP to lose traceability of who changed what. If the SharePoint form is accessible to unauthorized users, SAP still allows them to post the data to their ZOVBAK table because the data is posted by a generic user. SharePoint Admin can control this access, but let SharePoint handle their restriction, our goal is to protect the SAP with our controls.

This problem can be solved by other authentication mechanisms in the API world. However, we will see how the OAuth2.0 mechanism solves this problem.

What is OAuth →

It is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password. OAuth doesn’t share password data but instead uses authorization tokens to prove an identity between consumers and service providers. At present OAuth1.0 is deprecated and Oauth2.0 is redesigned with enrich features.

In a day-to-day life you have been using OAuth2.0 without realizing it, like – when you browse a random webpage, and it asks you to sign in using Google or Facebook or others. Say you choose Google and then it prompts you with Google login credentials, after successful authentication Google asks your permission to Authorize sharing blah-blah information with webpage you are browsing. Well, its OAuth2.0. Here is the architecture –

Figure 9: OAuth2.0 Architecture

The best thing about technology is that – people are given options. Basically, OAuth2.0 options differ in the way an access token (step 7 in the figure) is obtained from the OAuth 2.0 client application. Till date, SAP supports two types of OAuth2.0 flows –

Authorization Code Flow

SAML 2.0 Bearer Assertion Flow

We may discuss SAML 2.0 Bearer Assertion Flow another time, but in the next series we will accelerate on the Authorization Code Flow but this time we will see practical on our favorite tool Postman. Happy Learning!!

SAP API OData Security Part III – OAuth2.0 Authorization Code Flow

2023-10-11T09:39:05+02:00

Welcome to the third part of our SAP API Security journey. In second series, we learnt about Basic Authentication, OAuth definition and OAuth flows that SAP supports. Now lets gear up to OAuth authentication with some screenshots.

SAP got one of the best documentations in market. Wiki will give you end to end guide for OAuth implementation with SAP tailored made use case.

But for our use case, let's see how to enable OAuth in the OData service we created and implement the OAuth authorization code flow.

Select the OData service under transaction /iwfnd/maint_service, click on OAuth from available menu. Once your services is under OAuth scope then a check mark will appear beside OData services.

Figure 10: Activate OAuth in OData Service

Create a generic user that will be used for all OAuth flows, to be specific it will be used to exchange tokens between consumers and service providers, but NOT for posting which is our goal.

At this point no need to assign any access/roles to this user. And this user must be setup as SYSTEM user type.

Figure 11: OAuth Generic user SAP profile

Now execute transaction SOAUTH2 to create OAuth client here is how it looks –

Figure 12: OAuth configuration in SAP

Client ID: It is generic user you created in earlier step “SECTEST99”

Client Authentication: User “Client User ID and Password” so that front-end application needs to provide generic user account id and password to exchange token.

Resource Owner Authentication: Select checkbox “Grant Type Authorization Code Active”

With that you must provide “Redirect URI”.

Question 3: What is Redirect URI

It is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it's important you register the correct location as part of the app registration process.

Redirect URI: It is given to you by front-end application admin. For this exercise we will use Postman web as our front-end application, as like for Basic-Authentication we used Microsoft SharePoint. Postman has static Redirect URI for developers. Remember, Postman web has different redirect uri than Postman native app. For this exercise we are using Postman Web.

Refresh Allowed: It is another key feature in OAuth2.0 that SAP supports as well. In this blog series we are not going to use this feature so you can keep it unchecked.

Scope Assignment: Add the OData service that you created. Pre-requisite to appear your OData Service here to add under OAuth scope under transaction /iwfnd/maint_service. You can add multiple OData services under one client id.

Note: Remember Client ID is case-sensitive. I’ll recommend use upper case wherever it is prompted.

Now we will create an authorization role (Z:API_TEST_ROLE_OAUTH) with OAuth related object. This role is added to the user who uses this service as an OAuth and generic user, who has access to the service

Figure 13: SAP PFCG Role to access OAuth Client and Scope

Assign this role to generic OAuth user SECTEST99 and NO other access is needed as the purpose of this generic user is to exchange access token.

Figure 14: OAuth Generic user access

In this case, as data will be created in SAP using Mr. John’s account and not by any generic user, he must have SAP account with required permission. Required permissions are – OAuth role itself along with OData service role and permission to modify table ZOVBAK.

Figure 15: Business User account to access OData, OAuth scope and modify ZOVBAK Table

Let’s see practical in Postman app by calling OData service using “Get” Method.

For “Get” method we are using Basic-Authentication (although OAuth can be used as well), our goal is to get the x-csrf-token from Get method which we will utilize in “Post” method. For that under Headers I’m requesting (x-csrf-token = fetch) from OData service. After Status is 200 Ok then under response section of Header, we will get the x-csrf-token value.

Figure 16: Postman GET configuration

Let’s see “Post” Method configuration with OAuth2.0 authentication –

Figure 17: Postman OAuth2.0 configuration to fetch Access Token

Token Name: Give random name

Grant Type: Authorization Code

Callback URL: This url should match with redirect URI that is configured in SOAUTH2 transaction in SAP.

Auth URL: https://<hostname>/sap/bc/sec/oauth2/authorize

Access Token URL: https://<hostname>/sap/bc/sec/oauth2/token

Client ID: SAP ID of generic account

Client Secret: Password of generic account

Scope: Name of the OData service to generate token

Now hit on “Get New Access Token” button that will open a pop-up for you to authorize.

Figure18: End User step to authorize request

Figure19: Access Token details post end user authorized request

Figure20: POST headers and body configuration

Figure21: Result of POST operation

Status 201 means – entry is created.

These configurations made in Postman are technical specifications that we (SAP team) must provide to the administrator of the front-end application (be it SharePoint or ServiceNow or any other application). With that, the frontend administrator must deploy the configuration to the respective application to make a successful connection.

As far as Mr. John (or any business user) is concerned, he will simply enter the required details in the front-end application form and authorize the transaction using his SAP credentials, which should then publish the details in the SAP ZOVBAK table.

Figure 22: SAP ZOVBAK Table entry

You will notice that REMARK, which is added to the body of Postman or during Basic Authentication of SharePoint, is also changed. I have set up logic to update REMARK as SAP ID of the user creating a record in the table. This logic changes the REMARK specified in Body or SharePoint with the person creating the record.

The Outcome

With basic authentication, the table record is created by a generic service account, while with OAuth authentication, the record is created by Mr. John’s ID. By using OAuth authentication method ASDF's both requirement is fulfilled:

Since ASDF has various customers around the world, the development should be robust enough to create records in the ZOVBAK table using one or more applications.

“https://<hostname>/sap/opu/odata/sap/ZTEST_API_TEST_SRV/SOHEADERSet” OData service is robust to utilize in any application that supports REST calls.

For the ASDF company, the ZOVBAK table is critical, so only authorized, and authenticated users are allowed to create records.

OAuth2.0 will ensure that only authorized, and authenticated users are creating records in table

This was the final series and ThankYou for reading it. I'll be happy to answer your query or if you have any feedback for me.

Extension of Standard Task Summary View with Custom fields

2023-10-26T18:07:35+02:00

Hello All,

I Hope everyone doing well! 🙂

Introduction:

Recently, we got a requirement to enhance standard Fiori application with custom fields for one of the tile, when the tile is clicked we will have access to My inbox application. In this application the window is divided into main & detail window. Please refer to the below screenshot.

From above screenshot we have a option for Multi selection(Multi select button). When approver clicks on multi-select for bulk approval, the following is displayed with standard fields (Title, Created by and Due on).

In this blog, I am going to explain you how to extend the Task Summary View with custom fields in My inbox application.

When multi-select check box is selected and requests are checked/selected either via Select All or individually selecting the requests, Task Summary section should display the details of the selected requests with below custom fields.

Name

Period

Requested

Type

Comments

In order to achieve the above requirement I have followed below steps.

OData extension in Gateway System:

Step 1: Created a new project in SEGW transaction code and redefine the standard OData service (/IWPGW/TASKPROCESSING) as shown in below.

Click on next button then following screen will be displayed. Just select all the properties and click on finish button. Step 2: Now, we need to extend the “TASK” Entity type with custom field as per requirement (NAME, PERIOD, REQUESTED, TYPE, COMMENTS).

Note: Here we need to add one more property “SAP__Origin” as KEY along with above new custom fields.

This “SAP_Origin” field would play important role while extending the TASK entity this field will capture the system alias.

Step 3: Extension of Entity Type- TASKDEFINITION as shown in below.

Step 4: Once project is generated, Redefined the ENTITYSET_TASK method in DPC_EXT and added new custom code to fill new fields.

Here, I have created a new RFC function module in ECC system as there is no data in Gateway system and calling that RFC in ENTITYSET_TASK method and filling the Custom fields data.

Passing “Workitem” (LT_TASKS) information to RFC FM and get the data From ECC System.

Getting “SAP__Origin” information from table /iwfnd/c_mgdeam by passing Service_ID.

Step 5: Redefined the ENTITYSET_TASK_DEFINITION method in DPC_EXT and getting data to “SAP_Origin” from table /iwfnd/c_mgdeam.Step 6: Go to transaction code: /iwfnd/maint_Service and add the service and System alias.

Note: Here system alias should be ECC system alias.

Frontend application UI5 Extension:

View Design:

To add new columns in Task Summary, extension point is not available so replaced the Multiselectsummary View as Multiselectsummarycustom and added new columns as below.

Controller Extension:

To retrieve the data of new properties added new properties to select in the hook method extHookGetPropertiesToSelect by extending S2 controller as below.

To refresh the Master data modified sendMultiSelectActionSuccess function in S2Custom Controller, and sendAction function in S3Custom controller.

Added the code (this.oDataManager.refreshListOnAddInboxDone()) as below.

S2Custom Controller:

S3Custom controller:

Result:

Summary:

By following the above steps, we can enhance the standard Fiori application with custom fields.

Hope this blog will be helpful 🙂

Thanks for reading .

Please provide your valuable feedback on comment section.

-Please follow Puligilli Mahesh for future posts.

-Ask or follow questions about SAP NetWeaver .

-Read other SAP NetWeaver and follow blog posts.

Thanks & Regards

Mahesh

Request S/N from External System and respond to Corporate Serialization

2023-11-06T23:36:34+01:00

1. Introduction:

In this article, I will describe the way for serial number management. Basiclly, there are four variants. I would like to emphasis following two patterns. Both of them management S/N at Exteral System(e.g. Non-SAP) but in different way. I will focun on the differences on setting and operation.

SAP CorS Managed (External)

SAP CorS Tracked (with MD reference)

In addition, I will also introduce encoding/decoding Badi for well explain how S/N can be request from external and integration to CorS by utilizing customer own numbering rule.

2. Contents:

Pattern1. SAP CorS Managed (External)---Take SAP CorS as subordinate management system

Approach1: Request of Serial Numbers from Cors -> External

Approach2: Upload Serial Number from CorS directly

Pattern2. SAP CorS Tracked (with MD reference)---S/N is not management at SAP CorS, take CorS as S/N tracking system

Approach: Posting S/N with EPCIS event directly from using Warehouse Toolbox

3. SAP CorS Managed (External):　

Serial Number Request and Distribution | SAP Help Portal

Request Serial Numbers from an External System | SAP Help Portal

Upload Serial Numbers | SAP Help Portal

Serial Number Request Services | SAP Help Portal

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

●Approach1: Request of Serial Numbers from External -> CorS

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

■Operation ※Take "List Managed S/N" as Example

1. <External> Generate S/N at External System（e.g. 300 List Managed S/N）
2. <SAP CorS> Request S/N from Cors -> External（e.g.10 List Managed S/N）　　　
Trcd:「/CORS/SNR_REQUEST - Request of Serial Numbers」
3. <External> S/N will be sent from External -> CorS（e.g.10 List Managed S/N）

=>As a result, CorS will recieve S/N and S/N Status：１－Create

4. <SAP CorS> Encoding S/N for GTIN
Trcd: DataCockpit->Serial Numbers Node->Create Serial Number Request
BAdi here is possible.

=>As a result, S/N Status：２－Assign

5. <SAP CorS> Decoding S/N for Serialization Object
Trcd:「/CORS/POSTEVENT - Post Manual Event 」or using Warehouse Toolbox.
BAdi here is possible.

=>As a result, S/N Status：３－Commission

■Setting

1. Set up Range Definition/Range (＝Range Definition is must in this Pattern)

① Rng.Def.Origin.Ind=1(External)
② Ener External System Name into Range Definition Origin tab

2. Assign External Range to Product, Serial Number Management Type＝E

3. Maintain External System Master

4. Set up Web Service Binding

-For SAP CorS system

Following SAP standard web service is used for external S/N request, which need to be setup by SOAMANAGER.

Service Definition: /CORS/SERIALNUMBERREQUEST

Consumer Proxy: /CORS/CO_SNR_REQUEST

You need to Import WSDL Binding in SAP CorS as well.

Go to SE80 -> Enterprise Services Browser

Select a package and right click to "Create a new object"

Select "Service Consumer"

Select "External WSDL"

Select "WSDL source"

-For external (e.g. Non-SAP) system

external(e.g. Non-SAP) system needs to facilitate a WebService binding for the SerialNumberRequest

The WebService binding includes the endpoint where SAP CorS will direct its S/N Request towards

-How to confirm what WSDL Binding at SAP CorS needed

Open Trcd-SOAMANAGER

Click「Web Service Configuration」 menu

Click and open Service: /CORS/SERIALNUMBERREQUEST

Click “Earth” mark and find「Binding WSDL Generation」tab

Execute「WSDL URL for Binding」button, then we will see the exact payload and well format WSDL, which contain the required S/N infromation CorS needed from External.

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

●Approach2： Upload Serial Number from CorS directly

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

■Operation

1. <SAP CorS> Upload S/N
Trcd:「/CORS/SNR_REQUEST - Request of Serial Numbers」

=>As a result, S/N Status：１－Create

2. <SAP CorS> Encoding S/N for GTIN
Trcd: DataCockpit->Serial Numbers Node->Create Serial Number Request

=>As a result, S/N Status：２－Assign　

3. <SAP CorS> Decoding S/N for Serialization Object
Trcd:「/CORS/POSTEVENT - Post Manual Event 」or using Warehouse Toolbox

=>As a result, S/N Status：３－Commission

■Setting

※Same with Approach1 and No need web service setting up.

■BAdi

For example, in case customer require EWM HU number to be used as a GRAI serial. GRAI serial number has a limit of 16 characters or less, EWM HU may have a lenth of more then 16 characters, in that case, a Badi implementation for encoding and decoding with customer own numbering logic is recommended.

・Pre-requisite

Using Trcd: /CORS/C_OBJENCTYPE - Maintain Object and Encoding Types
①XXXXXX・・・Define Customer Z* Encoding Type
②XX・・・Define Customer Z* Object Type
③Assign①to②

・Badi Enhancement Spot

Enhancement Spot: /CORS/ES_ID_ENC_DEC
BadI Definition: /CORS/BADI_ID_ENC_DEC
Interface: /CORS/IF_BADI_ID_ENC_DEC
Method: ENCODE or DECODE

・Badi Sample

4. SAP CorS Tracked (with MD reference):

※Take "List Managed S/N" as Example

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

●Approach: Posting S/N with EPCIS event directly from using Warehouse Toolbox

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

■Concept
１. Customer do not use CorS to manage S/N, Range/Range definition is not required.
Instead, "Serial Number Management Not Used" flag must be set on the detail tab of CorS product or BP master.

２. No need to request or upload external S/N from CorS.

３. It is possible to manage S/N events in CorS. S/N from an external system can be recorded directly and tracked within CorS by posting EPCIS event.

For information on how to post an EPCIS event, you can use Warehouse Toolbox(Trcd:/STTPEC/WHS) , which is always used for register EPCIS event that related to warehouse task, or you can directly register EPCIS event with manual posting.

The advantage of this pattern is that if S/N can be managed centrally in an external system, there is no need for double management within SAP CorS. We use SAP CorS only for tracking and tracing S/N by posting EPCIS event to a partical serialization object.

■Setting Up Point

1. Set up “Serial Number Management Not Used” flag on the detail tab of CorS Product or BP Master.

2. Register EPCIS Event (Commission) by Warehouse Toolbox (Post Manual Event is also worked)

3. Here is the posting result at DataCockpit.

END.

Service Consumption Model 2 for OData Client Proxy

2023-11-06T23:45:15+01:00

Updates

16/11/2023: ADT wizard robustness, see section "What comes next?".

13/12/2023: Hint for error log integration in section "Tips for developers".

Introduction

This blog post will describe the Service Consumption Model 2 for OData. I will describe its benefits, provide a description of the model, take a look at the OData Client Proxy at runtime and also dive into the ABAP cross trace integration as well.

If you want to receive or send data to an OData V2 or V4 service within SAP BTP, ABAP Environment or SAP S/4HANA ABAP Environment, you can use the "Service Consumption Model 2" for OData. As of release 2311, it is possible to consume Complex Types, Complex Collection, Action (bound) and Functions (bound). Of course, the consumption of Entity Types and Entity Sets is also possible.

In addition you get fewer generated artifacts. The persistence of the underlying model has changed completely. In the first version you get an abstract CDS View for each Entity Type. For large services with multiple Entity Types, you could end up with a lot of artifacts. Now only one class with type definitions is created.

Many artifacts in the first version of the Service Consumption Model for OData

Use case

If you have an SAP BTP, ABAP Environment or SAP S/4HANA Cloud, ABAP Environment system you can use the Service Consumption Model for OData. From here you can connect to a Cloud or an on-premise system.

Scenario

In my scenario I am consuming the /dmo/travel service from another Cloud system. A call to the Entity Set Travel returns the following data:

GET /sap/opu/odata4/dmo/api_travel_u_v4/srvd_a2x/dmo/travel_u/0001/Travel

{

    "@odata.context": "$metadata#Travel",

    "@odata.metadataEtag": "W/\"20230919122803\"",

    "@odata.nextLink": "/sap/opu/odata4/dmo/api_travel_u_v4/srvd_a2x/dmo/travel_u/0001/Travel?$skiptoken=100",

    "value": [

        {

            "@odata.etag": "W/\"SADL-202305191948080000000C~20230519194808.0000000\"",

            "AgencyID": "70041",

            "AgencyName": "Maxitrip",

            "BeginDate": "2023-06-03",

            "BookingFee": 40.0,

            "CurrencyCode": "USD",

            "CustomerID": "594",

            "CustomerName": "Ryan",

            "EndDate": "2024-03-31",

            "LastChangedAt": "2023-05-19T19:48:08Z",

            "Memo": "Vacation",

            "SAP__Messages": [

            ],

            "Status": "P",

            "StatusText": "Planned",

            "TotalPrice": 1889.0,

            "TravelID": "1"

        },

        ...

Service Consumption Model 2 for OData

As of release 1808, you can use the Service Consumption Model for OData. From release 2311 on, the wizard in the ABAP Development Tools (ADT) will automatically use the new version.

Wizard

Select File --> New --> Service Consumption Model and choose OData as Consumption mode in ADT.

The consumption system requires a representation of the remote service. This knowledge is used to create the URL, write and read the JSON form the HTTP requests and responses. Therefore, the wizard needs the EDMX file (a service metadata document that describes the data model exposed by the service as an HTTP endpoint). OData uses EDMX as the format for this description of the remote service. You can get this by adding $metadata to the end of the service document, in my case it is the following URL:

GET /sap/opu/odata4/dmo/api_travel_u_v4/srvd_a2x/dmo/travel_u/0001/$metadata

I saved this file on my computer to use this in the wizard. In addition I chose ZBG_TRAVEL_SCM as the class name. This class is the model representation and will contain all the types for my client.

EDMX import and class name

The EDMX file is analyzed beforehand to identify potential problems. It could be that certain artifacts are ignored, for example, parts of them violate the OData metadata rules. In my case, the EDMX file describes several Entity Types, Entity Sets, a Complex Type and a Bound Action.

Analysis of EDMX file

The next step looks for the OptimisticConcurrency annotation of the Org.OData.Core.V1 vocabulary. If an Entity Set has this annotation, modifying requests must use an ETag. If an Entity Set does not have this annotation, you can select the ETag support here.

ETag support

Finally, I get the Service Consumption Model 2 for OData:

Service Consumption Model 2 for OData

In the upper left section, you can see the model class that describes the /dmo/travel service. I use the code snippets from Travel EntitySet and Read list as operation, as a starting point for my OData client.

Model class

The model class has the following parts:

Type definitions that can be used in my client code. I use a table of zbg_travel_scm=>tys_travel_type to retrieve the travel data.

To find the corresponding types, constants are created for Entity Sets, Entity Types, Complex Types, Actions and Functions. Here is the ABAP doc for the Entity Type constant, including the link to the type:

The model definition is done in several method implementations. The types are used to define all the artifacts of the remote service. In addition a mapping between the ABAP and the EDMX name is done here. ABAP artifacts are limited to 30 characters. In EDMX they can be up to 128 characters long in camel case.

If you need to customize the result of the wizard, for example because you need to adapt to certain naming conventions, you can modify the source code of the generated class and adapt it to your needs.

Support for Action and Functions

To call an action or a function, structures and tables for the parameter are generated. With release 2311 the ADT integration is still missing. So I can't select a bound action, an action import, a bound function or a function import and use the code snippet from the ADT. However, the parameter structure is there and I can use it at runtime to call the operation. You can find examples in SAP Help portal.

Connecting to a Remote Service

In a cloud system I need an outbound communication scenario, an outbound service and a communication arrangement for the http connection. Tutorial: Prepare Consuming System and Service Consumption Model describes the steps to achieve this.

OData Client Proxy at Runtime

For my client, I have used the code snippet from ADT (right hand side in the Service Consumption Model) to read the Entity Set Travel. The client code uses the type from the model. I changed three things after that:

Established the HTTP connection using the communication scenario and the outbound service.

Changed the IV_RELATIVE_SERVICE_ROOT parameter of the factory (line 56 in the screenshot below) to point to the OData service. This path depends on the communication system.

Added the out->write() statement at the end (line 81).

And voila, the GET request and transformation of the JSON response to ABAP was done for me.

OData Client Proxy at Runtime

Conclusion

The Service Consumption Model 2 for OData supports more OData features and generates fewer artifacts. The model class can be adapted to my needs, if the result of the wizard does not meet my expectations. It would be great to get feedback from you, so that we can further improve the wizard if this is indeed the case.

What comes next?

~~Make the ADT wizard more robust when importing EDMX files. Skipped elements will be part of the generated model to identify them later.~~
- As of release 2405, the ADT wizard skips elements that violate the OData specification (for example trying to create a key property inside a complex type). You find skipped elements in the gcs* constants.

Full support for actions and functions in the ADT, including code snippets.

On-premise shipping of the Service Consumption Model for OData.

Multiple namespace support for SuccessFactors services.

OpenAPI importer to support REST services.

Links

For more details on the OData Client Proxy, Service Consumption Model and communication scenario, see Developing External Service Consumption: OData Services

Feel free to ask me questions, provide feedback or to share this blog with others. Thank you.

Tips for developers

Error log integration

You can see errors in the SAP Gateway error log of ADT. To configure the feed, you can follow Andre's blog:: how-to-use-the-sap-gateway-error-log-in-adt

Cross trace integration

Sometimes it is good to know what the OData Client Proxy does under the hood. Especially connecting to another system can be tricky. Therefore the OData Client Proxy is part of the ABAP Cross trace (ADT Windows --> Show View --> ABAP Cross trace):

Activate OData Client Proxy in cross trace

In the trace result you can see for example the response payload and the CSRF token fetch:

HTTP payload in cross trace

Understanding Authorization in OData

2024-02-01T14:38:15.118000+01:00

Introduction:

Authorization refers to controlling access to resources and operations within an OData service. OData is a protocol that standardizes the way data is exposed and consumed over the web, typically using RESTful APIs.

OData(Open Data Protocol) is a widely adopted standard for building and consuming RESTful APIs. It simplifies data sharing across disparate systems, making it easier for developers to expose and consume data in a standardized manner. However, with great power comes great responsibility, and securing OData services is paramount to protect sensitive information. In this blog post, we'll delve into the intricacies of authorization in OData and explore best practices for securing your OData services.

Role-based authorization is a common practice in securing OData services. Assigning specific roles to users and granting permissions based on these roles helps control access to different resources. This approach ensures that users only have the necessary privileges required for their tasks.

Authentication vs. Authorization

Before delving into OData authorization, it's crucial to distinguish between authentication and authorization:

Authentication: Verifying the identity of users or systems making requests. Common methods include OAuth, API keys, or username/password.

Authorization: Determining the actions and data access permissions granted to authenticated users or systems.

Here I am creating a Odata project in Tcode SEGW by providing Project name and Description.

Import the Database table to the project by following the below steps

Provide the name of Database table in ABAP Structure.

Here Check out the Required fields for your Requirement and Click on Next.

Here Check on the Key fields present in the Table and click on finish.

Then Generate the OData Service, After Generating Components and methods will get Generated.

Here in Get Entityset I'm writing select Query to fetch the data.

To Provide Authorization to OData we need to follow below Steps.

Step 1: Go to Tcode :- SU20, Create Authorization field as shown below

Then Create Authorization Object in Tcode SU21 and Assign Authorization field to the Authorization Object.

Step 2: Create authorization for the role Tcode : PFCG

we'll see how to Provide Authorization to ODATA by Assigning roles.

Go to Tcode : PFCG and Provide Role and Description.

Then Select the Role as per your Requirement, Here i am Selecting Single Role.

After selecting Single Role New Page will get displayed, Here click On Menu Tab.

In Transaction Arrow symbol, choose Authorization default.

Choose the SAP Gateway Business Suite Enablement - Service

Then choose your service

Here we can see that our Service is Added to the role.

Then Click on Authorization Tab

Then Click on Change Authorization Data.

Click on Manually and provide your Authorization Name and select the Action and Click on Generate.

After Generating will get the Message 'Profiles were Updated'.

Then Go to Transaction Code ‘SU01’ to set role for the User.

Enter your Role name and click enter.

Then in Profiles click on generate which is located next to the Role name.

By Performing this we can Provide Authorization to ODATA Service.

Output for the HANAUSER18(My user). When Authorized user try to access.

Output for HANAUSER24 (Other user) When Non authorized user try to Access it will throw error.

SAP Learning Journey – Building OData Services with SAP Gateway

2024-02-29T15:30:09.480000+01:00

Since it was announced at SAP TechEd 2021, SAP offers digital learnings free of charge to everybody interested in SAP products on https://learning.sap.com. In this blog post, I want to present to you the learning journey Building OData Services with SAP Gateway and keep you up to date on the latest additions.

If you are more interested in a customer course for SAP Gateway, please read my blog post:
Customer course GW100 (SAP Gateway – Building OData Services) available for SAP S/4HANA 2021

Latest Additions

2023-11 Learning journey available

Introduction

This learning journey is based on the customer course GW100 (SAP Gateway – Building OData Services). The course structure was reworked to provide a clear path following the learning goals of each unit. Many animations and videos support the digital learning experience inviting you to interact with the material.

Nearly every lesson provides at least one exercise showing steps in a written form. Some can be performed directly by using some public resource like the SAP Gateway Demo System, but most exercises are based on SAP S/4HANA 2021 FPS02. In addition to the written form, these exercises provide a simulation of the steps in an SAP Learning system.

The units in the current version are the following:

SAP Gateway Overview
OData Overview
SAP Gateway and CDS Views

Content

1. SAP Gateway Overview

Unit 1 first describes SAP Gateway in general showing examples of where and how it is used in todays SAP solutions. The second lesson digs deeper in the releases and the components of SAP Gateway culminating in the deployment options for on-premise and SAP Business Technology Platform (BTP).

The following is exercised:

Prepare the SAP Learning System

2. OData Overview

Unit 2 covers the OData standard from the perspective of SAP Gateway. A short introduction to REST is followed by a comprehensive explanation of the OData protocol, how to perform OData operations and how to handle OData queries.

The following is exercised:

3. SAP Gateway and CDS Views

Unit 3 jumps to the world of Core Data Services (CDS) and shows the four ways an SAP Gateway service can be generated based on CDS views. This includes a short excursion to the ABAP RESTful Application Programming Model (RAP) but without getting into the details. The focus is to provide SAP Gateway services first by mapping or referencing a CDS view as data source in the SAP Gateway Service Builder (SEGW). Publishing a CDS view as SAP Gateway service or defining business services are performed in the ABAP Development Tools (ADT).

The following is exercised:

Summary

If you have read so far, it seems that you are really thinking about consuming the learning journey. Don’t hesitate and jump right in:

https://learning.sap.com/learning-journeys/building-odata-services-with-sap-gateway

If you are more interested in a customer course for SAP Fiori, please visit https://training.sap.com. The GW100 (SAP Gateway – Building OData Services) is a 5-day-course offered as physical and virtual event:

https://training.sap.com/course/GW100

For any other questions around the offerings of SAP Learning Services, please jump to our community page and get in contact with us:

https://pages.community.sap.com/topics/training-certification

Happy learning
Stefan

Customer Course GW100 (SAP Gateway – Building OData Services) Available for SAP S/4HANA 2021

2024-02-29T15:33:56.276000+01:00

Now that I finished the course development of the GW100 (again), I thought it is time to summarize all the new and updated topics in a central place. I decided that a blog post here would be a good way to share this to fellow ABAP developers. So welcome to my first blog post about the customer training GW100 (SAP Gateway – Building OData Services).

If you are more interested in a digital learning for SAP Gateway, please read my blog post:
SAP Learning Journey – Building OData Services with SAP Gateway

Introduction

Starting in 2014, this is now the seventh incarnation of how to develop OData services with SAP Gateway. The course shows all parts of SAP Gateway, which are available since SAP NetWeaver Application Server 7.0 (SAP Gateway 2.0), as well as parts added up to SAP S/4HANA 2021. The whole bandwidth of SAP Gateway covering all releases is shown.

The units in the current version are the following:

SAP Gateway Overview
OData Overview
SAP Gateway Service Implementation
SAP Gateway Service Generation
SAP Gateway Service Redefinition
SAP Gateway and CDS Views
SAP Gateway Hub Functionalities
Advanced OData Options
SAP Gateway Security
Further Information

If customers are interested, they can order a customer specific version of the course including only those topics suitable for their release or purpose.

System Landscape

Let’s start with the system release: SAP S/4HANA 2021 FPS02. Our system landscape – we call it universal target – is used in many technology courses and offers full access for the participants from the SAP Fiori launchpad (FLP) in the browser down to SAP HANA on the SUSE Linux Enterprise server (SLES). Everything is set up following the newest guidelines of SAP so that it can really act as a template for customers.GW100 System Landscape (Screenshot from System Setup Guide)

In addition, we offer an instance of the SAP Business Application Studio (BAS) to show the consumption of OData services. If you want to know more about this topic, check out our courses for SAP Fiori development.

OData

The unit explaining the OData foundation was greatly increased to cover all aspects of the protocol including OData V4. Many more slides were added to visualize the structure of an OData service. Here is an example about function and action imports:Function and Action Imports (Screenshot from GW100)A new section covering ?sap-ds-debug=true was added to explain the features of this debugging query option. Although it was always part of exercises, there was only one slide showing it. Now the following one is just the first one:SAP Debugging Query Option for Any Browser (Screenshot from GW100)The lesson about performing OData requests was enhanced in its visualization and some additional slides were added like this one for batch processing:OData Option $batch (Screenshot from GW100)

Implementation

The structure of the units covering code-based implementation got refined to better fit the current state of development. This includes more graphical explanations of how the source code is structured in the system like this one:Data Provider Base Class – Source Code (Screenshot from GW100)Other slides were enhanced using semantical colors consistently throughout the material. In this example, you see blue used for ABAP code, gold for HTTP requests, and green for (successful) HTTP responses:Create Operation Essentials (Screenshot from GW100)But of course, at the end of the day, it is all about source code. There are now more code snippets outside of exercises and the code is explained in more detail on slides:Implement Paging (Screenshot from GW100)

CDS Views

The evolution of CDS views was driving SAP Gateway from the beginning. That is why there is an own unit keeping track of all possibilities to generate SAP Gateway services based on CDS views:OData Service Development with CDS – Comparison (Screenshot from GW100)The decision, which generator is the right one for your project, does not only depend on the release you are using. Especially in a brown field approach, the data source reference in the SAP Gateway Service Builder (SEGW) is still a viable option for reusing existing source code in SAP Gateway services based on CDS views: How to Reference a Data Source (Screenshot from GW100)The newest generators are Business Services, which are part of the ABAP RESTful Application Programming Model (RAP). They are recommended by SAP as soon as they are available in your system and include the generation of OData V4 services:How to Create a Service Definition and Binding (Screenshot from GW100)

Summary

If you have read so far, it seems that you are really thinking about attending the course. Don’t hesitate and check out the physical and virtual events we offer:

https://training.sap.com/course/GW100

If you are more interested in a digital learning, please visit https://learning.sap.com. Some parts of the GW100 are already available free-of-charge:

https://learning.sap.com/learning-journeys/building-odata-services-with-sap-gateway

For any other questions around the offerings of SAP Learning Services, please jump to our community page and get in contact with us:

https://pages.community.sap.com/topics/training-certification

I hope even if you won’t attend the GW100 in any kind, you found some useful information around SAP Gateway in this blog post.

Happy learning
Stefan

Inbound Interface to receive the UUID, PDF and XML details through ODATA - MEXICO

2024-03-15T11:00:09.958000+01:00

Requirement

In Mexico, it is necessary that all companies receive tax authority validated XML and PDF files that contain the details of the payment made to vendors.

Its mandatory to extract the UUID number from the file that is received from the vendors and save it in a way that makes it easily accessible, in S4 it would be easier to store it in a custom table.

The importance of this interface is to store UUID in S4 system in order to facilitate users identify which invoices were payed to which vendors as well as reconciliation between EDICOM Portal and S4 system. The risk of not having this interface, is that files (PDF and XML) and UUID data will only be stored in EDICOM Portal and reconciliation to corresponding payments would be time consuming for users.

Technical Requirement

Interaction of SAP with EDICOM portal where SAP CPI is the middleware which sends the XML, PDF to S4. The technical requirement was to create a ODATA which can receive XML and PDF, also should extract UUID details from XML structure and update it to the respective document.

Simple flow chart:

Detailed Flow chart:

Technical Solution

To receive and extract the details from XML file, ODATA interface is developed and the received XML and PDF files are attached to the respective FI document.

XML and PDF files are sent in base64 encoded format from SAP CPI then in S4 we make use of various function modules to convert it and make the attachment.

Created ODATA service in tcode SEGW - ZFI_PAYMENT_COMPLEMENT_002

In Data model the custom table ZFI_IF020_PAYCOM is used to give ODATA the reference structure. The last two fields ZPDF & ZXML are created in RAWSTRING format to store the XML and PDF files.

Regenerate the Runtime Artifact ZCL_ZFI_PAYMENT_COM_01_DPC_EXT

This gives us the class where we can write the required logic, here we have redefined the method PAY_COMPSET_CREATE_ENTITY – holds the logic to validate the inputs received from SAP CPI and the logic to add PDF and XML to the FI document.

FI_DOCUMENT_CHANGE FM is used to update UUID to the respecting FI document.

The above FM is passed with the required importing parameters.

PDF Attachment:

PDF file is sent in Base64 format from CPI to S4.

SCMS_XSTRING_TO_BINARY – using this FM the received base64 format is converted to binary
ARCHIV_CREATE_TABLE – using this FM the converted binary file is attached to the FI document

XML Attachment:

XML is also sent in Base64 format from CPI to S4.

SCMS_XSTRING_TO_BINARY – using this FM the received base64 format is converted to binary
SO_CONVERT_CONTENTS_BIN – to get the binary file in tab format
SO_FOLDER_ROOT_ID_GET – this FM is used to fetch the folder ID
SO_OBJECT_INSERT – used to insert the converted XML file
BINARY_RELATION_CREATE_COMMIT – create relation between attachment and the document (Reference code is attached)

If there is any error in the attachment the file is sent to AL11.

All the received inputs including XML and PDF are saved in a custom table.

Report:

Tcode - ZFI_PAYCOMP_MONITOR

A report is created to display the details received using custom table in which the entries made through ODATA Service and displayed in ALV format.

User can view the error details in description and also can select and reprocess the particular file after updating the missed details.

Created and activated the service ZFI_PAYMENT_COMPLEMENT_002_SRV in following tcode /n/iwfnd/maint_service

The ICF Node should be in active status as shown in the screenshot.

Hope this helps someone! 😊

OData NW ABAP Gateway (OData)

Creation of OData service with implementation of CRUD methods and `deep insert` method from scratch

2024-05-03T08:33:54.245000+02:00

Overview

-- Goal:

Using SAP instance with SAP NW 7.40 or higher without RAP and without BOPF be able to create OData service upon business data model with these specific requirements:

- inserting of main business record support deep inserting (we save main record of main entity and all enclosed records in child entity)

- all CRUD methods of modification records for entities should be supported .

- code after regenerating OData service after adding of new changes is under control of developer via implemented overridden methods.

-- Considered model:

-- Main steps of implementation:

Using Eclipse + ADT you will go through this main steps and with all necessary code:

1-- Prepare data model with data

2-- Create project for OData service

3-- Add data model and generate service

4-- Register service and do initial test

5-- Implementation of `deep insert` MODEL via override

6-- Implementation of entity modification methods

7-- Implementation of OData CRUD methods using override

8-- Testing CRUD methods by SAP Gateway Client

9-- Verification of achieved code

-- As result of you will have:

-- Transportable package ZMLODATA which includes:

-- Data model with samples of data

-- OData service ZML_TRAVELLING_ODT

-- Classes where _EXT implementation decupled from regenerating process of OData service

Package ZMLODATA will contain these files:

Service Project `ZML_TRAVELLING_ODT` will be like this one:

Process of implementation

1-- Prepare data model with data

1--1-- create package ZMLODATA

1--2-- create data elements in package

ZMLNAME

ZMLDATEFROM

ZMLDATETO

1--3-- create table ZML_TRAVEL

Using package ZMLODATA you create database table in Eclipse ADT by opening `New ABAP Repository Object` for `Database Table` and using this code definition:

@EndUserText.label : 'ZML_TRAVEL'
@AbapCatalog.enhancementCategory : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zml_travel {
  key client    : abap.clnt not null;
  key travel_id : sysuuid_x16 not null;
  name          : zmlname;

}

1--4-- create table ZML_BOOKING

You add new Database Table `ZML_BOOKING` by this code into package ZMLODATA:

@EndUserText.label : 'ZML_BOOKING'
@AbapCatalog.enhancementCategory : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #ALLOWED
define table zml_booking {
  key client     : abap.clnt not null;
  @AbapCatalog.foreignKey.screenCheck : false
  key travel_id  : sysuuid_x16 not null
    with foreign key [0..*,1] zml_travel
      where travel_id = zml_booking.travel_id;
  key booking_id : sysuuid_x16 not null;
  hotel          : zmlname;
  dayfrom        : zmldatefrom;
  dayto          : zmldateto;

}

1--5-- Create Class `zml_gen_data_travels`

In package ZMLODATA you add new ABAP class `zml_gen_data_travels` by this code:

CLASS zml_gen_data_travels DEFINITION
  PUBLIC
  FINAL
  CREATE PUBLIC .

  PUBLIC SECTION.

    INTERFACES if_oo_adt_classrun .
  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS zml_gen_data_travels IMPLEMENTATION.
  METHOD if_oo_adt_classrun~main.

    DATA it_travel TYPE TABLE OF zml_travel.
    DATA it_booking TYPE TABLE OF zml_booking.

    DATA lv_long_time_stamp TYPE timestampl.
    GET TIME STAMP FIELD lv_long_time_stamp.
    DATA: l_uuid_x16 TYPE sysuuid_x16.
    DATA: system_uuid TYPE REF TO if_system_uuid.
    DATA: oref        TYPE REF TO cx_uuid_error.
    system_uuid = cl_uuid_factory=>create_system_uuid( ).

    TRY.

        it_travel =  VALUE #(
          ( client = sy-mandt travel_id = system_uuid->create_uuid_x16( ) name = 'Travel Minsk - Dubai' )
          ( client = sy-mandt travel_id = system_uuid->create_uuid_x16( ) name = 'Travel Minsk - Moscow' )
          ( client = sy-mandt travel_id = system_uuid->create_uuid_x16( ) name = 'Travel Minsk - Warsaw' )
          ( client = sy-mandt travel_id = system_uuid->create_uuid_x16( ) name = 'Travel Minsk - Dushanbe' )
          ( client = sy-mandt travel_id = system_uuid->create_uuid_x16( ) name = 'Travel Minsk - Batumi' )

        ).

        it_booking = VALUE #(
            ( client = sy-mandt booking_id = system_uuid->create_uuid_x16( ) travel_id = it_travel[ name = 'Travel Minsk - Dubai' ]-travel_id dayfrom = '20240101'  dayto = '20240104' hotel = 'Amirates Dubai' )
            ( client = sy-mandt booking_id = system_uuid->create_uuid_x16( ) travel_id = it_travel[ name = 'Travel Minsk - Moscow' ]-travel_id dayfrom = '20240105'  dayto = '20240107' hotel = 'Marriot' )
            ( client = sy-mandt booking_id = system_uuid->create_uuid_x16( ) travel_id = it_travel[ name = 'Travel Minsk - Warsaw' ]-travel_id dayfrom = '20240108'  dayto = '20240114' hotel = 'Outstanding WSW' )
            ( client = sy-mandt booking_id = system_uuid->create_uuid_x16( ) travel_id = it_travel[ name = 'Travel Minsk - Dushanbe' ]-travel_id dayfrom = '20240115'  dayto = '20240124' hotel = 'Marriot Hayat' )
            ( client = sy-mandt booking_id = system_uuid->create_uuid_x16( ) travel_id = it_travel[ name = 'Travel Minsk - Batumi' ]-travel_id dayfrom = '20240125'  dayto = '20240130' hotel = 'Amber Sea' )
        ).

        out->write( it_travel ).
        out->write( it_booking ).

*       delete existing entries in the database table
        DELETE FROM zml_booking.
        DELETE FROM zml_travel.


*       insert the new table entries
        INSERT zml_travel FROM TABLE @IT_travel.
        INSERT zml_booking FROM TABLE @IT_booking.

        out->write( |Demo data generated for tables...| ).

      CATCH cx_uuid_error.
        "handle exception
    ENDTRY.



  ENDMETHOD.

ENDCLASS.

1--6-- Run this class by pressing F9

You execute previously created class to add initial records into your data model by pressing F9.

5 records with travels and 5 records connected to each travel for bookings will be added after executing.

1--7-- at this moment you should have package with your dictionary and class

1--8-- you open data tables by preview of data to find that test records exist:

2-- create project for OData service

You press Alt-F8 and enter and run transaction: SEGW

In opened form you press icon of "Create project"

You fill in this information on form of creating project:

Project	ZML_TRAVELLING_ODT
Description	OData for travelling data
Package	ZMLODATA

You get a project `ZML_TRAVELLING_ODT` which has initial skeleton without connectivity to your model at this moment:

3-- Add data model and generate service

Using project `ZML_TRAVELLING_ODT` you do the next steps to import your entitles of model one by one, make necessary association between entities and generate project.

3--1-- Add Entity Type for ZML_TRAVEL table

Change project `ZML_TRAVELLING_ODT` to Edit mode.

Using context menu of Data model node you have to choose: Import -> DDIC Stucture

On first step of import wizard you provide the next information:

Name of type which we want create:	ZML_ITRAVEL
ABAP Structure (existing our table):	ZML_TRAVEL

On second step mark all fields:

On third step point the key of your records as TRAVEL_ID

In imported properties provide correctly operations:

if you open Entity Sets you should be able to find there `ZML_ITRAVELSet`

3--2-- Add Entity Type for ZML_BOOKING table

Again, you using context menu of Data model node choose Import -> DDIC Structure to open Wizard of importing.

On the first step of import wizard you provide:

Name of type which we want create:	ZML_IBOOKING
ABAP Structure (existing our table):	ZML_BOOKING

On second step of wizard you select all fields of entity.

And on the 3d step of wizard you point key id BOOKING_ID :

3--3-- Add association between ZML_ITRAVEL and ZML_IBOOKING

Using context menu on Association node you choose `Create` to start the wizard of creating association.

You should provide these parameters on Step 1 of association wizard:

Association Name	ZML_TRAVEL_TO_BOOKING
Principal Entity Type Name	ZML_ITRAVEL
Principal Cardinality	1
Principal Navigation Property	TO_BOOKING
Dependent Entity Type Name	ZML_IBOOKING
Dependent Cardinality	0..n
Dependent Navigation Property

On Step 2 of wizard association you point principal key TravelId for `Dependent Property`:

On Step 3 of wizard association you press Finish

You can check association in node Associations:

Also, you can check as `Navigation Property` with name `TO_BOOKING` if you expand Entity Types nodes in Data Model of project. The existence of this navigation property after applying association and the name `TO_BOOKING` we will use for `expand` functionality as well as for `deep insert` functionality

3--4-- Generate Runtime Objects of OData service

You press icon `Generate Runtime Objects`

As a result, 4 classes with prefix `ZCL_` will be generated in your package. Currently, all methods to serve ZML_IBTRAVELSET and ZML_IBOOKINGSET entity types will be pre-filled in with pattern of raising exception to generate message that method is not implemented yet. Later on, you will do implementation of each method in classes with `_EXT` suffix by overriding methods.

4-- Register service and do initial test

You should register service into SAP gateway and verify that service is maintained by initial test. It is better to do now, before you start implementation of methods to let you be ensured that service engin is generated correctly and you were able to maintain it correctly into SAP Gateway.

4--1-- Register service

In project open node `Service maintenance` and choose accessible SAP Gateway and press button `+Register` and then on prefilled form choose package ZMLODATA and save registration.

After registration you will be re-directed to Service Maintenance list ( also you can use transaction to be there in any time: /IWFND/MAINT_SERVICE ) where you can choose your service by technical name 1ZML_TRAVELLING_ODT`.

4--2-- Initial test

Once your service is registered you can test it by `SAP Gateway Client` through opening Maintenance list and then after choosing your service using ICF Nodes panel do pressing on `SAP Gateway Client` or you can directly start testing client form Service Maintenance of chosen gateway by pressing button `SAP Gateway Client` on form of Service registration.

Press `SAP Gateway Client` and and execute proposed URI and check that you have HTTP response with status 200 OK

change URI to ask provide operations with format JSON (just change format=xml to format=json)

/sap/opu/odata/sap/ZML_TRAVELLING_ODT_SRV/?$format=json

and execute to verify that you can get JSON response with status 200 Ok :

So currently OData which you created has information about your entities but if you try to use those entities (datasets) you will have error, because entities are not still connected to your data in databases.

if you will try to run this request:

/sap/opu/odata/sap/ZML_TRAVELLING_ODT_SRV/ZML_ITRAVELSet?$format=json

instead of data in response you will find error 501 and message "Method 'ZML_ITRAVELSET_GET_ENTITYSET' not implemented in data provider class"

In next steps (5,6,7) you will implement all necessary methods.

5-- Implementation of `deep insert` MODEL via override

As developer, you should modify class which is dedicated for extending object model of implementation: `zcl_zml_travelling_odt_mpc_ext` where name of class is proposed during generating service and the name of class for extending model by default is a combination: `ZCL`_ + <name_of_service> + `_MPC_EXT`

you will add manually the new deep structure there and do override of existing method `define` to be able map structure to certain entity.

This implementation is important to enable using structure for `deep insert` which will be needing to write correctly code for method CREATE of entity ZML_ITRAVELSet,.

5--1-- Add structure for `deep insert`

Open class for extending `zcl_zml_travelling_odt_mpc_ext` which is here:

You should add new type for structure of deep insert which is based on your types of data sets.

Goal to create hierarchy of types:

In public section of extension class zcl_zml_travelling_odt_mpc_ext you should add new structure:

    TYPES: BEGIN OF ty_s_trv_book.
             INCLUDE TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    TYPES:
             to_booking TYPE STANDARD TABLE OF zcl_zml_travelling_odt_mpc=>ts_zml_ibooking WITH DEFAULT KEY,
           END OF ty_s_trv_book.

Name of structure for this particular example is `ty_s_trv_book`.

5--2-- Override method `define`

Open in editor class zcl_zml_travelling_odt_mpc_ext and press Ctrl + space and choose Override `define`.

In overridden method is main aim is to map entity type of service to new structure of `deep insert`. Code of overridden method `define`:

  METHOD define.

    DATA lo_entity_type TYPE REF TO /iwbep/if_mgw_odata_entity_typ.

    super->define( ).

    lo_entity_type = model->get_entity_type( iv_entity_name = 'ZML_ITRAVEL' ).
    lo_entity_type->bind_structure( iv_structure_name = 'zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book' ).

  ENDMETHOD.

5--3-- Full code of extension method after preparation of `deep insert`:

CLASS zcl_zml_travelling_odt_mpc_ext DEFINITION
  PUBLIC
  INHERITING FROM zcl_zml_travelling_odt_mpc
  CREATE PUBLIC .

  PUBLIC SECTION.
    TYPES: BEGIN OF ty_s_trv_book.
             INCLUDE TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    TYPES:
             to_booking TYPE STANDARD TABLE OF zcl_zml_travelling_odt_mpc=>ts_zml_ibooking WITH DEFAULT KEY,
           END OF ty_s_trv_book.

    METHODS define REDEFINITION.



  PROTECTED SECTION.
  PRIVATE SECTION.
ENDCLASS.



CLASS zcl_zml_travelling_odt_mpc_ext IMPLEMENTATION.

  METHOD define.

    DATA lo_entity_type TYPE REF TO /iwbep/if_mgw_odata_entity_typ.

    super->define( ).

    lo_entity_type = model->get_entity_type( iv_entity_name = 'ZML_ITRAVEL' ).
    lo_entity_type->bind_structure( iv_structure_name = 'zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book' ).

  ENDMETHOD.

ENDCLASS.

6-- Implementation of entity modification methods

As developer, you should modify class which is dedicated for extending methods to work with data: `zcl_zml_travelling_odt_dpc_ext` where name of class is proposed during generating service and the name of class for extending data methods is combination of by default: `ZCL`_ + <name_of_service> + `_DPC_EXT`

Before start extending OData CRUD methods, you add 3 custom methods in this particular case:

6--1-- add custom method `zml_create_uuid` for getting UUID:

In protected section of class definition add:

    METHODS zml_create_uuid
      RETURNING VALUE(es_uuid) TYPE sysuuid_x16.

In implementation area of class add:

  METHOD zml_create_uuid.
    DATA lv_long_time_stamp TYPE timestampl.
    GET TIME STAMP FIELD lv_long_time_stamp.
    DATA: l_uuid_x16 TYPE sysuuid_x16.
    DATA: system_uuid TYPE REF TO if_system_uuid.
    DATA: oref        TYPE REF TO cx_uuid_error.
    system_uuid = cl_uuid_factory=>create_system_uuid( ).

    TRY.
        es_uuid = system_uuid->create_uuid_x16( ).
      CATCH cx_uuid_error.
        "handle exception
    ENDTRY.
  ENDMETHOD.

6--2-- add custom method `zml_modify_travel` for update or insert ZML_TRAVEL entity:

In protected section of class definition add:

    METHODS zml_modify_travel
      IMPORTING
                !ls_entity       TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel
      RETURNING VALUE(es_entity) TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.

In implementation area of class add:

  METHOD zml_modify_travel.
    DATA:
      it_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    MOVE-CORRESPONDING ls_entity TO it_entity.
    IF ( it_entity-client IS INITIAL ).
      it_entity-client = sy-mandt.
    ENDIF.
    TRY.
        it_entity-name = ls_entity-name.
        DATA itb_entity TYPE TABLE OF zml_travel.
        IF ( it_entity-travel_id IS INITIAL ).
          it_entity-travel_id = zml_create_uuid( ).
          itb_entity = VALUE #( ( it_entity )  ).
          INSERT zml_travel FROM TABLE @itb_entity.
        ELSE.
          itb_entity = VALUE #( ( it_entity )  ).
          MODIFY zml_travel FROM TABLE @itb_entity.
        ENDIF.
        es_entity = it_entity.
      CATCH cx_uuid_error.
    ENDTRY.
  ENDMETHOD.

6--3-- add custom method `zml_modify_booking` for update or insert ZML_BOOKING entity:

In protected section of class definition add:

    METHODS zml_modify_booking
      IMPORTING
                !ls_entity       TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking
      RETURNING VALUE(es_entity) TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.

In implementation area of class add:

  METHOD zml_modify_booking.
    DATA:
    it_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    MOVE-CORRESPONDING ls_entity TO it_entity.
    IF ( ls_entity-client IS INITIAL ).
      it_entity-client = sy-mandt.
    ENDIF.
    IF ( ls_entity-travel_id IS NOT INITIAL ).
      TRY.
          DATA itb_entity TYPE TABLE OF zml_booking.
          IF ( it_entity-booking_id IS INITIAL ).
            it_entity-booking_id = zml_create_uuid( ).
            itb_entity = VALUE #( ( it_entity )  ).
            INSERT zml_booking FROM TABLE @itb_entity.
          ELSE.
            itb_entity = VALUE #( ( it_entity )  ).
            MODIFY zml_booking FROM TABLE @itb_entity.
          ENDIF.
          es_entity = it_entity.
        CATCH cx_uuid_error.
      ENDTRY.
    ENDIF.

  ENDMETHOD.

6--4-- add custom method `deep_insert_travel_booking` for insert ZML_TRAVEL and ZML_BOOKING entities:

In protected section of class definition add:

    METHODS deep_insert_travel_booking
      IMPORTING
        !io_data_provider TYPE REF TO /iwbep/if_mgw_entry_provider
      EXPORTING
        !es_s_trv_book    TYPE zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book
      RAISING
        /iwbep/cx_mgw_busi_exception
        /iwbep/cx_mgw_tech_exception .

In implementation area of class add:

  METHOD deep_insert_travel_booking.
    DATA: ls_travel_booking_data TYPE zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book.
    DATA: ls_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    DATA: ls_childentity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    DATA: ar_childentities TYPE STANDARD TABLE OF zcl_zml_travelling_odt_mpc=>ts_zml_ibooking WITH DEFAULT KEY.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_travel_booking_data ).
    MOVE-CORRESPONDING ls_travel_booking_data TO ls_entity.
    ls_entity = zml_modify_travel( ls_entity = ls_entity ).
    MOVE-CORRESPONDING ls_travel_booking_data-to_booking TO ar_childentities.
    LOOP AT ar_childentities INTO ls_childentity.
      ls_childentity-travel_id = ls_entity-travel_id.
      ls_childentity = zml_modify_booking( ls_entity = ls_childentity ).
      ar_childentities[ sy-index ] = ls_childentity.
    ENDLOOP.
    MOVE-CORRESPONDING ls_entity TO es_s_trv_book.
    MOVE-CORRESPONDING ar_childentities TO es_s_trv_book-to_booking.
  ENDMETHOD.

7-- Implementation of OData CRUD methods using override

7--1-- Start override methods

Open class `ZCL_ZML_TRAVELLING_ODT_DPC_EXT` (name of class is proposed during generating for overriding and the name of class is combination of by default: `ZCL`_ + <name_of_service> + `_DPC_EXT`

This is generated class and will be regenerated if you need put changes in model and generate service once again.

SAP has classes for extending generated code, and those classes will not be re-created during generating, so your changes will be applicable after regenerating once again.

You can override any method by using Ctrl + space and choosing method for override from list:

7--2-- override method `/iwbep/if_mgw_appl_srv_runtime~create_deep_entity` manually

This is single method which we do overriding manually and with definition in PUBLIC SECTION of class.

Add to PUBLIC SECTION this redefinition:

METHODS /iwbep/if_mgw_appl_srv_runtime~create_deep_entity REDEFINITION.

Add to implementation area:

  METHOD /iwbep/if_mgw_appl_srv_runtime~create_deep_entity.
    DATA: ls_travel_booking_data TYPE zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book.
    CLEAR: er_deep_entity.
    TRY.
        CALL METHOD deep_insert_travel_booking
          EXPORTING
            io_data_provider = io_data_provider
          IMPORTING
            es_s_trv_book    = ls_travel_booking_data.
        copy_data_to_ref(
         EXPORTING
           is_data = ls_travel_booking_data
         CHANGING
           cr_data = er_deep_entity ).
      CATCH /iwbep/cx_mgw_busi_exception.
    ENDTRY.
  ENDMETHOD.

7--3-- override method `zml_itravelset_update_entity`

  METHOD zml_itravelset_update_entity.
    DATA:
      ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel,
      ls_entity         TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    IF ( ls_entity-travel_id IS INITIAL ).
      io_tech_request_context->get_converted_keys(  IMPORTING es_key_values = ls_converted_keys ).
      ls_entity-travel_id = ls_converted_keys-travel_id.
    ENDIF.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_travel( ls_entity = ls_entity ).
  ENDMETHOD.

7--4-- override method `zml_itravelset_delete_entity`

  METHOD zml_itravelset_delete_entity.
    DATA: ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    io_tech_request_context->get_converted_keys( IMPORTING es_key_values = ls_converted_keys ).
    DELETE FROM zml_booking WHERE travel_id = ls_converted_keys-travel_id.
    DELETE FROM zml_travel WHERE travel_id = ls_converted_keys-travel_id.
  ENDMETHOD.

7--5-- override method `zml_itravelset_create_entity`

  METHOD zml_itravelset_create_entity.
    DATA: ls_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_travel( ls_entity = ls_entity ).
  ENDMETHOD.

7--6-- override method `zml_ibookingset_get_entity`

  METHOD zml_ibookingset_get_entity.
    DATA:ls_keytab TYPE LINE OF /iwbep/t_mgw_name_value_pair.
    LOOP AT it_key_tab INTO ls_keytab.
    ENDLOOP.
    IF ( ls_keytab-name = 'BookingId' ).
      SELECT SINGLE * FROM zml_booking INTO CORRESPONDING FIELDS OF er_entity WHERE booking_id = ls_keytab-value.
    ELSEIF ( ls_keytab-name = 'TravelId' ).
      SELECT SINGLE * FROM zml_booking INTO CORRESPONDING FIELDS OF er_entity WHERE travel_id = ls_keytab-value.
    ENDIF.
  ENDMETHOD.

7--7-- override method `zml_itravelset_get_entity`

  METHOD zml_itravelset_get_entity.
    DATA:ls_keytab TYPE LINE OF /iwbep/t_mgw_name_value_pair.
    LOOP AT it_key_tab INTO ls_keytab.
    ENDLOOP.
    IF ( ls_keytab-name = 'BookingId' ).
      DATA: lv_travel_id TYPE zml_booking-travel_id.
      SELECT SINGLE travel_id FROM zml_booking INTO lv_travel_id WHERE booking_id = ls_keytab-value.
      IF sy-subrc = 0.
        SELECT SINGLE * FROM zml_travel INTO CORRESPONDING FIELDS OF er_entity WHERE travel_id = lv_travel_id.
      ENDIF.
    ELSEIF ( ls_keytab-name = 'TravelId' ).
      SELECT SINGLE * FROM zml_travel INTO CORRESPONDING FIELDS OF er_entity WHERE travel_id = ls_keytab-value.
    ENDIF.
  ENDMETHOD.

7--8-- override method `zml_ibookingset_get_entityset`

  METHOD zml_ibookingset_get_entityset.
    DATA:ls_keytab TYPE LINE OF /iwbep/t_mgw_name_value_pair.
    LOOP AT it_key_tab INTO ls_keytab.
    ENDLOOP.
    IF ( ls_keytab IS NOT INITIAL ).
      IF ( ls_keytab-name = 'BookingId' ).
        SELECT * FROM zml_booking INTO CORRESPONDING FIELDS OF TABLE et_entityset WHERE booking_id = ls_keytab-value.
      ELSEIF ( ls_keytab-name = 'TravelId' ).
        DATA: lv_travel_id TYPE zml_travel-travel_id.
        SELECT SINGLE travel_id FROM zml_booking INTO lv_travel_id WHERE travel_id = ls_keytab-value.
        SELECT * FROM zml_booking INTO CORRESPONDING FIELDS OF TABLE et_entityset WHERE travel_id = lv_travel_id.
      ENDIF.
    ELSE.
      SELECT * FROM zml_booking INTO CORRESPONDING FIELDS OF TABLE et_entityset.
    ENDIF.
  ENDMETHOD.

7--9-- override method `zml_itravelset_get_entityset`

  METHOD zml_itravelset_get_entityset.

    DATA: lv_source_entity_set_name TYPE /iwbep/mgw_tech_name.

    lv_source_entity_set_name = io_tech_request_context->get_source_entity_set_name( ).

    IF lv_source_entity_set_name IS INITIAL.

      SELECT * FROM zml_travel INTO CORRESPONDING FIELDS OF TABLE et_entityset.
    ELSE.
      SELECT * FROM zml_travel INTO CORRESPONDING FIELDS OF TABLE et_entityset.
    ENDIF.
  ENDMETHOD.

7--10-- override method `zml_ibookingset_update_entity`

  method zml_ibookingset_update_entity.
    DATA:
      ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking,
      ls_entity         TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    IF ( ls_entity-booking_id IS INITIAL ).
      io_tech_request_context->get_converted_keys(  IMPORTING es_key_values = ls_converted_keys ).
      ls_entity-booking_id = ls_converted_keys-booking_id.
    ENDIF.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_booking( ls_entity = ls_entity ).
  endmethod.

7--11-- override method `zml_ibookingset_delete_entity`

  method zml_ibookingset_delete_entity.
    DATA: ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    io_tech_request_context->get_converted_keys( IMPORTING es_key_values = ls_converted_keys ).
    DELETE FROM zml_booking WHERE booking_id = ls_converted_keys-booking_id.
  endmethod.

7--12-- override method `zml_ibookingset_create_entity`

  method zml_ibookingset_create_entity.
    DATA: ls_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_booking( ls_entity = ls_entity ).
  endmethod.

8-- Testing CRUD methods by SAP Gateway Client

8--1-- GET all records from entities

8--1--1-- GET entities with query parameter $format=json

Check again by SAP Gateway Client that you can extract data from ZML_ITRAVELSet and for ZML_IBOOKINGSet

/sap/opu/odata/sap/ZML_TRAVELLING_ODT_SRV/ZML_ITRAVELSet?$format=json

/sap/opu/odata/sap/ZML_TRAVELLING_ODT_SRV/ZML_IBOOKINGSet?$format=json

8--1--2-- GET entities by using header parameters instead of query parameter

You need to be able to add header parameters because in json it is easier to operate and some operation will work only with header (POST, PATCH, PUT and DELETE)

So look at screenshots below how you can add parameters and all rest screenshots will have always header parameters for your understanding.

It is right to keep these two parameters added for all operations:

and add this parameter only for PATCH, PUT, and DELETE:

8--2-- GET specific record from entity

8--3-- GET specific record with details using EXPAND

8--4-- PUT change record to change.

8--4--1-- PUT for ZML_ITRAVELSet it will be:

8--4--2-- PUT for ZML_IBOOKINGSet it will be:

You can verify if data were successfully applied by GET:

8--6-- PATCH change only pointed parameters.

8--6--1-- PATCH for entity ZML_ITRAVELSet:

8--6--2-- PATCH for entity ZML_IBOOKINGSet:

You can verify if it was changes by GET:

8--8-- DELETE -remove record and all child records

8--8--1-- DELETE for entity ZML_ITRAVELSet

Your code you can check and in code we delete child records from ZML_IBOOKINGSet and then record from ZML_ITRAVELSet. But it is up to you have this logic. You can allow delete only if childe records were delete previously. Just for simplicity we do deleting as cascade.

Notice: parameter `if-match` should be removed from header, overwise you will have error.

8--8--2-- DELETE for entity ZML_IBOOKINGSet

Notice: parameter `if-match` should be removed from header, overwise you will have error.

8--9-- INSERT - add new records

8--9--1-- INSERT for entity set `ZML_ITRAVELSet`

You have implemented `deep insert` with deep structure. So you expect to create complex records when you POST entity ZML_ITRAVELSet. It will be one record for ZML_ITRAVELSet and related records (child records) for entity ZML_IBOOKINGSet. Deep structure supposes to use head structure from ZML_ITRAVELSet and child structure with name `TO_BOOK` from ZML_IBOOKINGSet. So you have to prepare request with such payload:

{
  "Client" : "001",
  "Name" : "Travel Minsk - Milano",
  "TO_BOOKING": [
    {
        "Client" : "001",
        "Hotel" : "Ahmat hotel",
        "Dayfrom" : "\/Date(1481760000000)\/",
        "Dayto" : "\/Date(1481760000000)\/"
    },
    {
      "Client" : "001",
      "Hotel" : "Yes hotel",
      "Dayfrom" : "\/Date(1481760000000)\/",
      "Dayto" : "\/Date(1481760000000)\/"
    }
  ]
}

you point this URI:

/sap/opu/odata/SAP/ZML_TRAVELLING_ODT_SRV/ZML_ITRAVELSet

and you choose method: POST

8--9--2-- INSERT for entity set `ZML_IBOOKINGSet`

You should know GUID of your parent record for ZML_ITRAVELSet

{
  "TravelId" : "0242ac11-0002-1eef-80aa-0315685dd657",
  "Hotel" : "Amirates Dubai stars",
  "Dayfrom" : "\/Date(1704067200000)\/",
  "Dayto" : "\/Date(1704326400000)\/"
}

Response contains payload about what has been added and and which Booking Id was created.

If you wish you can GET particular record by using (guid' value of Booking Id ') :

9-- Verification of achieved code

You can compare your code or if you feel that it is better to apply ready to use project and go through this document you can find this project here on GitHub:

https://github.com/lukcad/ZMLODATA.git

Also, you can verify your overridden methods for class zcl_zml_travelling_odt_dpc_ext here:

CLASS zcl_zml_travelling_odt_dpc_ext DEFINITION
  PUBLIC
  INHERITING FROM zcl_zml_travelling_odt_dpc
  CREATE PUBLIC .

  PUBLIC SECTION.


    METHODS /iwbep/if_mgw_appl_srv_runtime~create_deep_entity REDEFINITION.

  PROTECTED SECTION.
    methods zml_ibookingset_update_entity redefinition.
    methods zml_ibookingset_delete_entity redefinition.
    methods zml_ibookingset_create_entity redefinition.

    METHODS zml_create_uuid
      RETURNING VALUE(es_uuid) TYPE sysuuid_x16.

    METHODS zml_modify_travel
      IMPORTING
                !ls_entity       TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel
      RETURNING VALUE(es_entity) TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.

    METHODS zml_modify_booking
      IMPORTING
                !ls_entity       TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking
      RETURNING VALUE(es_entity) TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.

    METHODS deep_insert_travel_booking
      IMPORTING
        !io_data_provider TYPE REF TO /iwbep/if_mgw_entry_provider
      EXPORTING
        !es_s_trv_book    TYPE zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book
      RAISING
        /iwbep/cx_mgw_busi_exception
        /iwbep/cx_mgw_tech_exception .


    METHODS zml_itravelset_update_entity REDEFINITION.
    METHODS zml_itravelset_delete_entity REDEFINITION.
    METHODS zml_itravelset_create_entity REDEFINITION.
    METHODS zml_ibookingset_get_entity REDEFINITION.
    METHODS zml_itravelset_get_entity REDEFINITION.
    METHODS zml_ibookingset_get_entityset REDEFINITION.
    METHODS zml_itravelset_get_entityset REDEFINITION.

  PRIVATE SECTION.


ENDCLASS.



CLASS zcl_zml_travelling_odt_dpc_ext IMPLEMENTATION.

  METHOD zml_itravelset_get_entityset.

    DATA: lv_source_entity_set_name TYPE /iwbep/mgw_tech_name.

    lv_source_entity_set_name = io_tech_request_context->get_source_entity_set_name( ).

    IF lv_source_entity_set_name IS INITIAL.

      SELECT * FROM zml_travel INTO CORRESPONDING FIELDS OF TABLE et_entityset.
    ELSE.
      SELECT * FROM zml_travel INTO CORRESPONDING FIELDS OF TABLE et_entityset.
    ENDIF.
  ENDMETHOD.

  METHOD zml_ibookingset_get_entityset.
    DATA:ls_keytab TYPE LINE OF /iwbep/t_mgw_name_value_pair.
    LOOP AT it_key_tab INTO ls_keytab.
    ENDLOOP.
    IF ( ls_keytab IS NOT INITIAL ).
      IF ( ls_keytab-name = 'BookingId' ).
        SELECT * FROM zml_booking INTO CORRESPONDING FIELDS OF TABLE et_entityset WHERE booking_id = ls_keytab-value.
      ELSEIF ( ls_keytab-name = 'TravelId' ).
        DATA: lv_travel_id TYPE zml_travel-travel_id.
        SELECT SINGLE travel_id FROM zml_booking INTO lv_travel_id WHERE travel_id = ls_keytab-value.
        SELECT * FROM zml_booking INTO CORRESPONDING FIELDS OF TABLE et_entityset WHERE travel_id = lv_travel_id.
      ENDIF.
    ELSE.
      SELECT * FROM zml_booking INTO CORRESPONDING FIELDS OF TABLE et_entityset.
    ENDIF.
  ENDMETHOD.

  METHOD zml_itravelset_get_entity.
    DATA:ls_keytab TYPE LINE OF /iwbep/t_mgw_name_value_pair.
    LOOP AT it_key_tab INTO ls_keytab.
    ENDLOOP.
    IF ( ls_keytab-name = 'BookingId' ).
      DATA: lv_travel_id TYPE zml_booking-travel_id.
      SELECT SINGLE travel_id FROM zml_booking INTO lv_travel_id WHERE booking_id = ls_keytab-value.
      IF sy-subrc = 0.
        SELECT SINGLE * FROM zml_travel INTO CORRESPONDING FIELDS OF er_entity WHERE travel_id = lv_travel_id.
      ENDIF.
    ELSEIF ( ls_keytab-name = 'TravelId' ).
      SELECT SINGLE * FROM zml_travel INTO CORRESPONDING FIELDS OF er_entity WHERE travel_id = ls_keytab-value.
    ENDIF.
  ENDMETHOD.

  METHOD zml_ibookingset_get_entity.
    DATA:ls_keytab TYPE LINE OF /iwbep/t_mgw_name_value_pair.
    LOOP AT it_key_tab INTO ls_keytab.
    ENDLOOP.
    IF ( ls_keytab-name = 'BookingId' ).
      SELECT SINGLE * FROM zml_booking INTO CORRESPONDING FIELDS OF er_entity WHERE booking_id = ls_keytab-value.
    ELSEIF ( ls_keytab-name = 'TravelId' ).
      SELECT SINGLE * FROM zml_booking INTO CORRESPONDING FIELDS OF er_entity WHERE travel_id = ls_keytab-value.
    ENDIF.
  ENDMETHOD.

  METHOD zml_itravelset_create_entity.
    DATA: ls_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_travel( ls_entity = ls_entity ).
  ENDMETHOD.

  method zml_ibookingset_create_entity.
    DATA: ls_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_booking( ls_entity = ls_entity ).
  endmethod.

  METHOD zml_itravelset_delete_entity.
    DATA: ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    io_tech_request_context->get_converted_keys( IMPORTING es_key_values = ls_converted_keys ).
    DELETE FROM zml_booking WHERE travel_id = ls_converted_keys-travel_id.
    DELETE FROM zml_travel WHERE travel_id = ls_converted_keys-travel_id.
  ENDMETHOD.

  method zml_ibookingset_delete_entity.
    DATA: ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    io_tech_request_context->get_converted_keys( IMPORTING es_key_values = ls_converted_keys ).
    DELETE FROM zml_booking WHERE booking_id = ls_converted_keys-booking_id.
  endmethod.

  METHOD zml_itravelset_update_entity.
    DATA:
      ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel,
      ls_entity         TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    IF ( ls_entity-travel_id IS INITIAL ).
      io_tech_request_context->get_converted_keys(  IMPORTING es_key_values = ls_converted_keys ).
      ls_entity-travel_id = ls_converted_keys-travel_id.
    ENDIF.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_travel( ls_entity = ls_entity ).
  ENDMETHOD.

  method zml_ibookingset_update_entity.
    DATA:
      ls_converted_keys TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking,
      ls_entity         TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    IF ( ls_entity-booking_id IS INITIAL ).
      io_tech_request_context->get_converted_keys(  IMPORTING es_key_values = ls_converted_keys ).
      ls_entity-booking_id = ls_converted_keys-booking_id.
    ENDIF.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_entity ).
    CLEAR er_entity.
    er_entity = zml_modify_booking( ls_entity = ls_entity ).
  endmethod.

  METHOD /iwbep/if_mgw_appl_srv_runtime~create_deep_entity.
    DATA: ls_travel_booking_data TYPE zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book.
    CLEAR: er_deep_entity.
    TRY.
        CALL METHOD deep_insert_travel_booking
          EXPORTING
            io_data_provider = io_data_provider
          IMPORTING
            es_s_trv_book    = ls_travel_booking_data.
        copy_data_to_ref(
         EXPORTING
           is_data = ls_travel_booking_data
         CHANGING
           cr_data = er_deep_entity ).
      CATCH /iwbep/cx_mgw_busi_exception.
    ENDTRY.
  ENDMETHOD.


  METHOD deep_insert_travel_booking.
    DATA: ls_travel_booking_data TYPE zcl_zml_travelling_odt_mpc_ext=>ty_s_trv_book.
    DATA: ls_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    DATA: ls_childentity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    DATA: ar_childentities TYPE STANDARD TABLE OF zcl_zml_travelling_odt_mpc=>ts_zml_ibooking WITH DEFAULT KEY.
    io_data_provider->read_entry_data( IMPORTING es_data = ls_travel_booking_data ).
    MOVE-CORRESPONDING ls_travel_booking_data TO ls_entity.
    ls_entity = zml_modify_travel( ls_entity = ls_entity ).
    MOVE-CORRESPONDING ls_travel_booking_data-to_booking TO ar_childentities.
    LOOP AT ar_childentities INTO ls_childentity.
      ls_childentity-travel_id = ls_entity-travel_id.
      ls_childentity = zml_modify_booking( ls_entity = ls_childentity ).
      ar_childentities[ sy-index ] = ls_childentity.
    ENDLOOP.
    MOVE-CORRESPONDING ls_entity TO es_s_trv_book.
    MOVE-CORRESPONDING ar_childentities TO es_s_trv_book-to_booking.
  ENDMETHOD.

  METHOD zml_create_uuid.
    DATA lv_long_time_stamp TYPE timestampl.
    GET TIME STAMP FIELD lv_long_time_stamp.
    DATA: l_uuid_x16 TYPE sysuuid_x16.
    DATA: system_uuid TYPE REF TO if_system_uuid.
    DATA: oref        TYPE REF TO cx_uuid_error.
    system_uuid = cl_uuid_factory=>create_system_uuid( ).

    TRY.
        es_uuid = system_uuid->create_uuid_x16( ).
      CATCH cx_uuid_error.
        "handle exception
    ENDTRY.
  ENDMETHOD.

  METHOD zml_modify_travel.
    DATA:
      it_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_itravel.
    MOVE-CORRESPONDING ls_entity TO it_entity.
    IF ( it_entity-client IS INITIAL ).
      it_entity-client = sy-mandt.
    ENDIF.
    TRY.
        it_entity-name = ls_entity-name.
        DATA itb_entity TYPE TABLE OF zml_travel.
        IF ( it_entity-travel_id IS INITIAL ).
          it_entity-travel_id = zml_create_uuid( ).
          itb_entity = VALUE #( ( it_entity )  ).
          INSERT zml_travel FROM TABLE @itb_entity.
        ELSE.
          itb_entity = VALUE #( ( it_entity )  ).
          MODIFY zml_travel FROM TABLE @itb_entity.
        ENDIF.
        es_entity = it_entity.
      CATCH cx_uuid_error.
    ENDTRY.
  ENDMETHOD.

  METHOD zml_modify_booking.
    DATA:
    it_entity TYPE zcl_zml_travelling_odt_mpc=>ts_zml_ibooking.
    MOVE-CORRESPONDING ls_entity TO it_entity.
    IF ( ls_entity-client IS INITIAL ).
      it_entity-client = sy-mandt.
    ENDIF.
    IF ( ls_entity-travel_id IS NOT INITIAL ).
      TRY.
          DATA itb_entity TYPE TABLE OF zml_booking.
          IF ( it_entity-booking_id IS INITIAL ).
            it_entity-booking_id = zml_create_uuid( ).
            itb_entity = VALUE #( ( it_entity )  ).
            INSERT zml_booking FROM TABLE @itb_entity.
          ELSE.
            itb_entity = VALUE #( ( it_entity )  ).
            MODIFY zml_booking FROM TABLE @itb_entity.
          ENDIF.
          es_entity = it_entity.
        CATCH cx_uuid_error.
      ENDTRY.
    ENDIF.

  ENDMETHOD.

ENDCLASS.

You can use this example of OData service as start point of developing your own package with own model and own project for OData by SEGW transaction. Now you have clear understanding how it can be implemented and fulfill business requirements, especially when those require none generative approach because particular changes of methods business consider as most effective approach on working production instances.

Thank you for your attention and happy programming,

Yours sincerely,

Mikhail.

PS: if you missed this link: https://github.com/lukcad/ZMLODATA.git

Fiori PO Approver app Accept and Reject button customization from ECC backend

2024-05-03T12:45:30.531000+02:00

Please go through the Part 1 Forward Button customization for better understanding.

Many time there are custom requirements for which it requires the need of creating Enhancement in standard SAP functionality.

Overview : PO Approvers are maintained in Release Strategy. Once the PO is generated it is set to be approved by PO approvers based on the levels maintained in PPOME structure. Only then the PO will be set to 03 status in EKKO.

Pre-requisite : All the roles and authorization must be given to the approvers to access the PO Approval Tile in SAP Fiori.

Requirement : If the approver find the PO is incorrect, he will reject the PO. The rejection of PO must contain the rejection text. Since the Text is an optional there comes up the challenge to make it mandatory.

Solution:

There are many ways to do this
1. Doing changes in Front-End using BTP/WEB IDE.

2. Making it mandatory from ECC

I chose the 2nd method since there was some issue in licensing the BTP and it was not configured correctly.

Making it mandatory from ECC

My PO tile looks like this

When the approver click on the Reject button , he must enter the Rejection note. If he doesn't then the PO should not be rejected.

SAP has provided only few objects which can be modified without the BTP framework. PO Approval is one of it. The main thing to note and find the Odata.

How to find the OData which will can be used for my development?
You can find the OData from going to Fiori tile -> Do Frontend debugging-> Refresh the page-> Navigate to Network Tab -> Find Path starting with key words /sap/opu/odata

In my case the OData is GBAPP_POAPPROVAL
/sap/opu/odata/SAP/GBAPP_POAPPROVAL

You can also find it through the XML file

Now you have the Standard OData name, it must be implemented so that it could connect with the backend system by providing the system name in External system.

Odata Implementation: The ODATA deployment is Central HUB . We have separate GW systems for hosting Fiori Tiles.

Tcode : /n/iwfnd/maint_service

Now one must get 200 response after connecting it with backend system.
Tcode : /n/iwfnd/gw_client

Till now OData is successfully configured. Now its time to find the BADI in ECC system to implement. This can be found in my previous Blog
Let me directly jump to the method which would be required to implement.
The method is Change SET_DECISION method

Here the SAP Standard documentation is pretty clear about the way of processing. You can go through it.

Accept : iv_decision = 1.
Reject : iv_decision = 2.
If you want nothing should happen mark ev_decision_processed = 'X'.

METHOD IF_GBAPP_EX_APV_PO_RDP~CHANGE_SET_DECISION.
" Standard Documentation: Do not delete

* This method can be used to enable execution of a workitem
* without updating a purchase order. The customer should
* implement the method and call a corresponding function to execute
* the workitem followed by COMMIT WORK.
* To avoid update of the purchase order, it is necessary to set the
* output parameter EV_DECISION_PROCESSED to 'X'.
* Preventing update of a document can be necessary, if the customer
* uses his own workflow where update of purchase order takes place
* in a separate background workflow step.
  IF iv_decision EQ 2.
    IF iv_rejection_text IS INITIAL.
      ev_decision_processed = 'X'.
    ELSE.
      DATA : t_return TYPE STANDARD TABLE OF  BAPIRET2.
      CALL FUNCTION 'ZFIORI_PO_APPROVAL_REJ_CHG' IN UPDATE TASK
        EXPORTING
          iv_ebeln = iv_pc_number
        TABLES
          t_return = t_return.
      COMMIT WORK.
    ENDIF.
  ENDIF.
ENDMETHOD.

As per my requirement if the approver accept I should not check anything and simply make it happen, hence I have not done anything with iv_decision = 1. If you want, you can add your custom requirement under it.
For me I have marked ev_decision_processed = 'X', if rejection text/ note in not provided.
I have used a Update Task FM because these were the async call hence the system was giving dump while updating the EKKO. So as to correct this I have divided it in 2 Logical unit. A wait of 5 secs have introduced so that the previous task gets over.

FUNCTION zfiori_po_approval_rej_chg.
*"----------------------------------------------------------------------
*"*"Update Function Module:
*"
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IV_EBELN) TYPE  EBELN
*"  TABLES
*"      T_RETURN STRUCTURE  BAPIRET2
*"----------------------------------------------------------------------
*"*"Update Function Module:
  WAIT UP TO 5 SECONDS.
  DATA: lr_po           TYPE REF TO cl_po_header_handle_mm,
        ls_bapi         TYPE bapiret2,
        l_result        TYPE mmpur_bool,
        lv_procstat     TYPE ekko-procstat,
        ls_document     TYPE mepo_document.
  CONSTANTS: lc_status TYPE ekko-procstat VALUE '08',
             lc_set_status TYPE ekko-procstat VALUE '03',
             lc_process TYPE char16 VALUE 'PO_PROCESS',
*             lc_trtyp TYPE char1 VALUE 'VER',
*             lc_trtyp TYPE char1 VALUE 'V',
             lc_ind TYPE char40 VALUE 'RELEASE',
             lc_tcode TYPE SY-TCODE VALUE 'ME29N'.

  SELECT SINGLE procstat FROM ekko INTO lv_procstat WHERE ebeln =  iv_ebeln.
  IF lv_procstat EQ lc_status.
*  prepare creation of PO instance
    ls_document-process     = 'PO_PROCESS'.
    ls_document-trtyp       = 'VER'.
    ls_document-doc_key(10) = iv_ebeln.
    ls_document-initiator-initiator = 'RELEASE'.

    CREATE OBJECT lr_po.
    lr_po->for_bapi = 'X'.
    lr_po->po_initialize( ls_document ).
    lr_po->set_po_number( iv_ebeln ).

    CALL FUNCTION 'MEPO_DOC_READ'
      EXPORTING
        im_ebeln                       = iv_ebeln
        im_tcode                       = lc_tcode"'ME29N'
        im_trtyp                       = ls_document-trtyp
*    IM_ID                          =
        im_document                    = ls_document
*   IM_NO_MESSAGING                =
*   IM_NO_MESSAGE_REQ              =
*   IM_NO_AUTHORITY                =
* EXCEPTIONS
*   DOC_NUMBER_MISSING             = 1
*   TRANSACTION_CODE_MISSING       = 2
*   TRANSACTION_TYPE_MISSING       = 3
*   INVALID_CALL                   = 4
*   OTHERS                         = 5
              .
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.
    DATA : ex_data  LIKE  mepoheader.
    CALL FUNCTION 'MEPO_DOC_HEADER_GET'
      IMPORTING
        ex_ekko = ex_data.

    IF cl_process_state_mm=>is_allowed(
                     im_bstyp   = ex_data-bstyp
                     im_state   = ex_data-procstat
                     im_process = cl_process_state_mm=>c_pr_reset_rej )
                                                          EQ mmpur_no.
      MESSAGE e806(mepo) WITH ex_data-procstat RAISING failed.
    ENDIF.
    ex_data-procstat = cl_process_state_mm=>c_active.
    lr_po->set_data( ex_data ).

    UPDATE ekko SET procstat = lc_set_status WHERE ebeln EQ iv_ebeln.
*    UPDATE ekko SET PROCSTAT = ex_data-procstat where ebeln eq iv_ebeln.
  ENDIF.

ENDFUNCTION.