SAP Community - NW ABAP Web Services

How to send data from ECC to PI using a Consumer Proxy (Web Service)

2020-01-27T18:45:34+01:00

There could be times when your organization has multiple PI/PO servers for different geographical locations connected to different SAP ECC servers, or they might have acquired a new company which already had another SAP PI/PO middleware into the play (you got the point).

Now, you're asked to develop a new interface that will cater to all geographic locations integrated with all back-end ECC systems. In those scenarios you have 3 options:

Consolidate all interfaces into one PI/PO server so that you can integrate other ECC boxes into one central PI/PO System Landscape Directory (SLD) - this is the best option, but also time consuming and may not be suitable for meeting the business timelines.

Create different types of interfaces - one Proxy type for the ECC systems already integrated with the PI/PO server, another RFC type for the ones not yet integrated. This will create overhead in PI/PO development and maintenance and also to note that RFC is not recommended over Proxy.

And the last option is the one that I'm going to illustrate in this blog where you'll have a single Operation Mapping in the Enterprise Service Repository and use the Proxy communication for the integrated ECC systems and Web Service for the non-integrated ECC systems.

Here are the steps you need to follow in the ABAP system to consume the Web Service stood up in the PI/PO system (I'm assuming you're aware of the steps to create the basic PI/PO interface):

Configure the ICO in PI and get the WSDL

Open the WSDL in browser and save in your local disk as a WSDL file

Go to SE80 > Repository Browser and select the Package option

Right click on Enterprise Services > Create

Select Service Consumer

Select External WSDL/Schema

Select Local File

Locate the saved WSDL file

Add Package, Transport Request and a Prefix

Click on Complete

This will create a new Service Consumer. You need to save and activate it.

The class object will have all the methods that you need to use to send data. But before that you need complete the following configurations in SOAMANAGER (in many companies those are Basis tasks – remember this is a client dependent configuration).

Select Service Administration > Web Service Configuration

Search it with the ABAP Class name:

Select the object and in next screen Create a Logical Port selecting the Manual Configuration option.

Input a meaningful Port Name and description and don’t forget to select the Logical Port as Default

Select appropriate Authentication method to login to PI from ECC.

Input URL Access Path (get it from the WSDL and remove all “amp;”), Access URL (PI server URL without the HTTP:// and w/o the Port#), Port of Access URL (PI Port#).

Leave the SOAP Protocol as default.

No input in Identifiable Business Context.

The operation should come up automatically, you just need to input the highlighted Transport Binding.

Finish to complete the configuration and make sure it’s in Active state.

Then display the service and Ping test it.

Your service is now ready to be consumed. Next you need program it to call the proxy.

Sample code:

Developing GraphQL API on ABAP: GraphQLAdmin Web Interface

2020-03-23T04:41:20+01:00

With the success of the initial version of GraphQL ABAP implementation and usage analysis over several APIs, though the APIs can be built and used with ease, I felt an urge to improve the efficiency of developing APIs with an easier and standardized way.

I have started working in my free time on the next version of the GraphQL ABAP implementation, which I will try to present first hand in this Blog Post, in hope of suggestions and comments.

Please find my earlier blog posts on the previous version of GraphQL ABAP implementation to gain some background.

GraphQL + SAP ABAP: The Inspiration

GraphQL + SAP ABAP: Architecture and Technical Details

Thoughts and Improvements:

GraphQL Schema
- But where is the Graph?
- How can we visualize the Data Model it exposes?

Schema Development
- Defining schema using ABAP code takes significant efforts and error-prone
- How can we standardize the Schema Definition process
- How can we decrease the efforts of managing the Schemas available across systems
- How can we reuse existing Business logic efficiently with minimal efforts
- How can we quickly go from Schema to API

Out of these above thoughts, I have started designing a GraphQL Admin (Web Application) with features like:

Maintain all Schemas available in the system with a simple and refreshing interface
- List the schemas
- Create/Edit/Delete the schemas

Use the Schema Definition Language (SDL) of GraphQL
- Instead of creating the schema using repetitive ABAP code scattered across Classes, provide an in-place editor for the whole schema

Instead of resolving only by ID
- Provide more context to the Resolvers to be able to improve efficiency by Schema awareness
- Resolve the ABAP executable code like Function Modules and Classes

Defining the Mapping between GraphQL and ABAP using Directives

Let us dive deep into the features of the Web Application with few Screenshots instead of my boring theory.

Dashboard (is now left empty)
- can be used to show statistics like the number of schemas available, the number of requests per schema, active calls per hour and critical messages and so on...

Schemas Menu Option: for CRUD operations on Schemas
- Creating a New Schema
  - takes unique Schema ID, description and SICF path of the schema in SAP

Creating related SICF node in SAP with just ZGQLCL_API_SERVICE_BASE as the superclass

List of Schemas
- the operations for each tile contains Edit Schema Header, Delete and Visual Editor in sequence

New Schema created will be stored into SAP tables
- Fun Fact: The API for this Application is also running on GraphQL ABAP Implementation and maintained using this Web APP and can be seen in the above screenshot as GQL_ADMIN tile

Visualizing/Updating the Schema using GraphQL Editor
- Adding new functionality into new Schema using GraphQL Editor

Note: Thanks to the GraphQL Editor Open Source library, which is used to edit the Schema generated from GraphQL ABAP Implementation
- SAP will generate the SDL required for GraphQL Editor
- WebAPP will pull this SDL from SAP and render using GraphQL Editor library
- Once the Editing is done in WebAPP, Saving will convert the updated SDL to config tables of SAP

Please head over to the GraphQL Editor site to check out how cool the idea of editing the Graph online is

The Left side Icon Menu comes with GraphQL Editor library standard Operations for searching within Schema
- with additional custom Save icon at the bottom for saving the updated Schema into SAP

The top bar is to navigate between
- GraphQL Editor
- Dashboard with Schema List
- Creating a New Schema
- Importing ABAP DDIC objects

Editor pane on the left is the SDL Syntax highlighted text editor which will render the SDL generated by ABAP Server

The right panel is the Visual representation of the Graph for given SDL which also allows
- Adding, Deleting, Updating of the Nodes in the Graph visually
- Scrolling, Panning and Zooming into the Graph

Finally, GraphQL Playground tool used to execute/test the GraphQL queries against ABAP server showing the initial schema created

Note: URLs of the Web Application and GraphQL Playground are showing "http://localhost" since these are running proxy servers locally to connect to local SAP Netweaver 7.52 instance distributed free for developers, huge Thanks to SAP for the same

Directives
- Here is another idea I have admired from PostGraphile library showing efficient usage of Directives to bridge the Operations between Data model and GraphQL language
- I have tried to implement the same for the GraphQL ABAP implementation to integrate and invoke existing executable business logic available in SAP
- I see the Directives as a way to provide additional information either at Design time or Execution time for different elements of the Schema ex. Fields, Types, ENUMs
- Following basic Directives are defined as standard into the GraphQL ABAP implementation
  - @abapName for mapping GraphQL name to SAP name
    
    @abapValue for mapping GraphQL Enum value to SAP Domain value
    
    @resolver to support legacy RESOLVER by ID functionality
- Additional Directives can be defined and added to the Schema generator using a simple implementation of Interface ZGQLIF_CUSTOM_DIRECTIVE
  - @functionModule to execute the ABAP function module using GraphQL data
    
    @class to execute ABAP Class and Method using GraphQL data
- Import functionality can be used to generate base SDL for these directives to be added to Editor and adjusted to the needs

Working with Schema Editor to define GraphQL Schema
- Adding operations into Schema using simple Import Function Modules
  - Function or Class imports will be generating simple SDL for the main operation and supporting SDL types, Inputs based on ABAP Imports and Exports.
  - This allows us to define or customize as desired, rather framework deciding all on its own, which will mostly not be sufficient for ever-changing API contracts
  - Imports support Basic Data Types, Structures and Table Types
  - FM with Type Ref To is not supported, as we can't send references through API

bellow we can see an operation zgqlfmTestStringRes has been added to Query type

with @functionModule directive and attribute "name" with FM name for resolver execution

executing the above query after saving the Schema

We can modify the names of the generated schema fields from "zgqlfmTestStringRes" to "fetchStringResource", which will have no effect on the execution of the Function

But in order to change the field names generated, we need to use the @abapName directive to map to original SAP parameter names, ex "evStr" export parameter is renamed to "sampleString"

Here is the actual Function Module from SAP looks like

Let us try to change the logic to return dynamic values from EV_STR with Time Stamp

Import also supports Class Methods import as well with few limitations
- Class Constructor with Required parameters are not supported
- Static and Public Instance methods are only exported as GraphQL operations

Sample Import of a Class results SDL as

Above the Importer provides the Static and Public Instance methods of the bellow sample class

Operations in Schema
- bellow we can see 3 operations getSeed1, staticMethod and testMulitExport have been added to Query
- getSeed1 has @class->name as Class name and @class->method as Class Method name for resolving

Execution of Class Methods is same as calling operations

Building Sample Demo GraphQL API using SFLIGHT BAPIs

Search for Flights - FM - BAPI_FLIGHT_GETLIST

SDL with "searchFlights" operation, includes all the Import and Export parameters from FM

Executing BAPI from GraphQL

Now we need Details of the Flights we fetched, we can use FM - BAPI_FLIGHT_GETDETAIL
- we will define the details operation both as
  - dependent on Search - when we want sub information at the time of search within the single API call
  - root operation - when we know all required information on the flight (without performing Search)

The difference above is to remove Required parameters when including under Search operation as the values from Search results will be automatically passed down to Details operation when the input parameter of the child operation is the same as Output field of the parent. Ex. "airlineid", "connectionid", "flightdate"

Executing Flight Details operation
- as Root operation when Flight details are known

- as Search dependent operation to pull the details along with Search

Advantages & Conclusions:

Using the SDL for managing the Schema is a great way to improve the Developer experience in building the APIs

SDLs can be managed in Source Controls like GitHub or Bitbucket at a central location for review and tracking the changes across Teams

This is a faster way of building the APIs and will need less technical knowledge of the internal logic of the server itself

As this does not rely on any functionality of the SAP Modules and is purely implemented in ABAP, this could be used across all SAP Systems

Using the Directive Resolvers will reduce the amount of SAP code to build Schema significantly

GraphQL Admin Web App can be used as a gateway to maintaining GraphQL Schemas across different SAP systems with minimal changes and can be integrated with Source Control systems for version management on SDL

The new system is designed to provide more context to the Resolvers and better Error handling

This mainly reduces/eliminate the code we need to write for Schema development itself, which will shift the focus on API development and design instead

Although this is nowhere near to finish, I see it has a lot of potential and scope to reduce Development costs and increase the efficiency of building APIs.

The source is not exported as of now for this implementation, as it is under constant changes. Once this is finalized will probably share the code here. Anyone wants to see this in action, reach out to me for a discussion on what I have built so far.

Thanks for your interest and for reading through the blog post. Stay safe amid COVID-19.

Improve the performance of an SAP FIORI application by implementing "Delta Token" mode in SAP Netweaver Gateway Odata

2020-04-14T18:45:58+02:00

In a mobility context, it is often necessary to develop an application that will be used online and offline.

To avoid performance problems, it is necessary to implement the various features offered by the components of the application architecture.

The large amount of data to be processed is often the first area of improvement. In this article, we offer a guide to implementing Delta Token mode at the webservice level on the SAP Gateway platform.

SAP Gateway & Delta Token

When the app is initially login, for a given user, to the ECC backend, it is necessary to load all the useful data to work offline.

One of the main problems in the field of mobility is to limit the amount of data that migrates from the backend to the final medium.

The network is not necessarily accessible (white zone), speed may not be up to the needs, significantly slowing down data recovery or transfer, and then blocking the application for a time that can sometimes take several minutes.

To overcome these constraints, the use of "Delta mode"is recommended for all web services.

How "Delta" Mode Works

During a call to a webservice, supporting the "Delta" mode, a "token" is generated by the latter and returned, along with the expected data collection, to the frontend.

This token, if used in successive calls, allows the backend to calculate a delta of the data and return only the data from the collection that has undergone changes since the previous call (creation, modification, deletion of values or data). This limits the amount of data that passes through the network and contributes to improved performance.

The "Delta" mode is interesting about methods returning a collection, as are the so-called "Query" methods.

In practical terms, these are the methods (visible via the SEGW transaction) known as "GetEntitySet"; Their principle is to return a list of objects that meet certain criteria (e.g. all "materials" available within the plant); it is this list that is called "collection."

Delta Mode Implementation

Creating a list-generating RFC module

The ZRFC_READ_ALL function

Our RFC contains only two parameters: two tables

ALL --> contains all the results compatible with the query

SEL_ALL_USER --> allows you to submit one or more filtering values

The structure of the function tables

ALL : This table contains all the fields you want to transmit via webservice

SEL_ALL_USER : This table contains the filter values, its structure is always the same (the length of the "low" and "high" components can vary to adapt to the filter's needs

The function algorithm

In the function code, we take into account the filter table if informed, otherwise we make a simple query.

Our function is ready to return the expected results!

Creation of an Odata project

On the SAP Gateway server, execute the SEGW transaction

The structure of the "ZGCG11_DEMO" project

The "Data model" was generated based on the composition of the RFC (without considering the filter table), as well as:

Name of "Data Model" --> "All_Delta"

Associated "Entity Set" name --> "All_Delta_Set"

Implementation of the "Query" method

Mapping is simply done between the areas of the results table and those of the Odata project entityset.

Webservice will return all results associated with this RFC module code (if no filter is provided):

It is thus possible to recover the result via the "IWFND/GW_CLIENT" transaction with this query:

--> /sap/opu/odata/SAP/ZGCG11_DEMO_SRV/All_Delta_Set

As well:

Redefining the "Query" method via ABAP

The redefinition of a method of your Odata project is achieved via a right click on the name of this method and then:

The screen we access can also be found via the SE80 transaction.

The tree of "methods" must then be unfolded until the "Query" method associated with the Entity Set is found, which always ends with an "ENTITYSET" and:

This "Query" method is the one that will be called by default if you don't specify a token, i.e. when the application is initialized or when you need a complete refresh, for example.

All you have to do is right click on it and choose to "redefine."

You will then need to report the following data elements:

  DATA : lo_dp_facade          TYPE REF TO /IWBEP/IF_MGW_DP_FACADE,

         lv_delta_token        TYPE string.

Method algorithm:

* Appel de la RFC

  CALL FUNCTION 'ZRFC_READ_ALL'

    TABLES

      ALL                = et_entityset.



  CHECK sy-subrc EQ 0.



* Get the data provider facade

  TRY.

    lo_dp_facade = /iwbep/if_mgw_conv_srv_runtime~get_dp_facade( ).

    CATCH /iwbep/cx_mgw_tech_exception.   

          RAISE EXCEPTION TYPE /iwbep/cx_mgw_tech_exception.

  ENDTRY.





* Call the delta token functionality

  TRY.

   CALL METHOD /iwbep/cl_query_result_log=>create_update_log_entry_hash

      EXPORTING

        io_tech_request_context  = io_tech_request_context

        io_dp_facade             = lo_dp_facade

        ir_service_document_name = mr_service_document_name

        ir_service_version       = mr_service_version

        it_entityset             = et_entityset

      CHANGING

        ev_delta_token           = lv_delta_token.



    CATCH /iwbep/cx_qrl_locked.          

          RAISE EXCEPTION TYPE /iwbep/cx_qrl_locked.



    CATCH /iwbep/cx_qrl_delta_unavailabl. 

          RAISE EXCEPTION TYPE /iwbep/cx_qrl_delta_unavailabl.

  ENDTRY.



* export the delta token

  es_response_context-deltatoken = lv_delta_token.

Explanation:

The method starts by calling the RFC in a standard way, it returns all the results.

Two objects are then required:

The data provider facade allows data to be stored in a hashed table based on the structure of the associated model

The "delta token"

After recovering the data from our RFC, a data provider facade is created; then the two are combined in the call of the method allowing data storage and token generation.

The Webservice call then returns all the values as well as the token that will be used in successive calls in order to only trace the difference in results.

Redefining the "Query Delta" method via ABAP

A second method must now be redefined to allow the use of the "delta" mode.
This is the method:

This method is used by all the "Entities" in your Odata project.

You will need to report the following data elements ....

  DATA : lv_entity_set_name    TYPE string,

         lv_delta_token        TYPE string,

         lo_dp_facade          TYPE REF TO /iwbep/if_mgw_dp_facade.

....As well ase tables, based on the structure of those powered by your RFC,to collect the "created/modified" and "deleted" data identified by the "delta" token method.

  TYPES : BEGIN OF wlst_users,

            ZUSER Type  XUBNAME,

            ZMAIL Type  AD_SMTPADR,

          END OF wlst_users.



  DATA  : lt_users          TYPE STANDARD TABLE OF wlst_users

                            WITH NON-UNIQUE DEFAULT KEY

                            INITIAL SIZE 0.



  DATA  : lt_deleted_users  TYPE STANDARD TABLE OF wlst_users

                            WITH NON-UNIQUE DEFAULT KEY

                            INITIAL SIZE 0.

We are only interested here in one "EntitySet", so we have to identify it:

* get the EntitySet name in progress

  lv_entity_set_name = io_tech_request_context->get_entity_set_name( ).



* If it's an EntitySet that we manage in delta mode

  CASE lv_entity_set_name.

    WHEN 'All_Delta_Set'.

*     Appel de la RFC

      CALL FUNCTION 'ZRFC_READ_ALL'

        TABLES

          all                = lt_users.





*     get the data provider facade

      TRY.

          lo_dp_facade = /iwbep/if_mgw_conv_srv_runtime~get_dp_facade( ).

        CATCH /iwbep/cx_mgw_tech_exception.

          RAISE EXCEPTION TYPE /iwbep/cx_mgw_tech_exception.

      ENDTRY.



*     Calculation of differences between delta tokens and updating of information

      TRY.

         CALL METHOD /iwbep/cl_query_result_log=>create_update_log_entry_hash

            EXPORTING

              io_tech_request_context  = io_tech_request_context

              io_dp_facade             = lo_dp_facade

              ir_service_document_name = mr_service_document_name

              ir_service_version       = mr_service_version

              it_entityset             = lt_users

            IMPORTING

              et_deleted_entityset     = lt_deleted_users

              et_entityset             = lt_users

            CHANGING

              ev_delta_token           = lv_delta_token.



        CATCH /iwbep/cx_qrl_locked.           

              RAISE EXCEPTION TYPE /iwbep/cx_qrl_locked.



        CATCH /iwbep/cx_qrl_delta_unavailabl. 

              RAISE EXCEPTION TYPE /iwbep/cx_qrl_delta_unavailabl.

      ENDTRY.





*     Export of new delta token

      es_response_context-deltatoken = lv_delta_token.





*     Export of deleted datas

      copy_data_to_ref( EXPORTING  is_data = lt_deleted_users

                        CHANGING   cr_data = er_deleted_entityset ).



*     Export of modified or created datas

      copy_data_to_ref( EXPORTING  is_data = lt_users

                        CHANGING   cr_data = er_entityset ).





    WHEN OTHERS.

*     Do nothing





  ENDCASE.

ENDMETHOD.

Data persistence

There is a constraint to the use of the "Delta" mode: the weight of the data!

Each call using this mode generates logs in SAP, only if the result of that call differs from the previous one. These logs are like a snapshot of the result of the query. They are therefore fundamental to the operation of the "Delta" mode because they are the elements on which SAP relies to determine the existence of differences.

These logs are stored in two tables:

/IWBEP/D_QRL_HDR

/IWBEP/D_QRL_ITM

The first, contains the head data, while the second contains the detail, the signature, of each line returned.

These records are specific to the user generating the call of the webservice.

Thus, over time, these tables will contain more and more "unnecessary" data since obsolete. To avoid losing performance as a result of this data, it will be necessary to carry out a regular purge.

There is a standard tool, provided by SAP:

Report « /IWBEP/R_CLEAN_UP_QRL”

Attention!
If this table no longer contains the data you want to access (via the Delta Token), then the webservice will have to make a new call from the webservice but in "full" mode, i.e. without referring to the Delta Token (which will involve a longer processing time than in delta mode).

That said, this full mode will trigger new logs that will be used in subsequent delta mode calls.

Find more informations here about SAP GATEWAY and OData : https://help.sap.com/doc/saphelp_nw74/7.4.16/en-US/ec/aeea50ca692309e10000000a445394/content.htm?no_cache=true

Remediation of uncalled active ICF services

2020-06-18T10:23:53+02:00

Web applications and web services to rule them all

Updates:
2022-11-07: Added hint for new secure-by-default logs.

The time of SAP GUI as a proprietary interface for every user interaction seems to be over soon. SAP is moving towards serving more and more applications as web applications or web services - be it SAP Fiori, be it the Webgui utilising Screen Personas or OData or REST APIs.

While this change counts in for sure to better user experience or using open standards for interfaces (e.g. towards cloud services), it also effects the SAP Basis Administrator:
A SAP basis administrator nowadays need to have a deep understanding of web technologies (additionally to understanding the SAP application server, the database as well as to the operating system like linux).

I will not go into detail about the journey from the integration of Internet Communication Manager (ICM) as web server into SAP NW AS ABAP/Java or what to consider in general when operating a web server within your ERP system - maybe even exposed to the internet.
In this blogpost I would like to catch up a topic which is more related to the content served by the Internet Communication Framework (ICF) through the ICM.

“Please activate one or the other ICF service - it is urgent!”

In the early days - before "Secure by Default" was a claim - SAP NetWeaver AS ABAP based systems were shipped with certain ICF services in status "activated". In addition to that, SAP Basis Administrators often where asked on short notice to quickly activate one or the other service in transaction SICF until some urgent needed functionality works. So it happened that there were more ICF service activated then ever needed, especially in the production system.

While in the meantime SAP released many security notes to fix vulnerabilities in the SAP standard ICF services, in many systems a number of 500 up to more than 3000 ICF services are still enabled although they are not needed nor called.

Bring some light into the darkness

Please note: As of SAP S/HANA-Version 2022 / ABAP Platform 2022 the so called secure-by-default logs for ICF calls are collected. These logs can be evaluated in transaction SBDLOG. Those can be used to activate all ICF services that have ever been logged or deactivate services that were not logged by choosing 'Menu' -> 'ICF Integration' in transaction SBDLOG. With this, the manual steps described below can be omitted.

At first lets export a list of the active ICF services of all of your systems (Dev, Int, Prod) by the following steps:

Go to transaction SE38.

Execute report RS_ICF_SERV_ADMIN_TASKS.

Choose “Export of Active Services to CSV File” and execute to save the file, e.g. as <SID>_active_services.csv

Again. Repeat these steps for every system in your landscape.

To give yourself an overview about the active ICF services in your systems take a look at the exported lists. By screening every list you will figure out that the active services in the various systems of a system landscape will be different from system to system.

Please be aware for some services there is a good reason to be active in development or integration system only! There are services used for development purposes or there might be services for features which are not yet released to production. Besides that, there are web applications used only for one time tasks or initial setup. Or active services differ simply due to configuration drift.

The main purpose of this lists is to use it a) as a template for the deactivation of uncalled ICF services in the next steps and b) as a backup to quickly mass re-activate all former active services in emergency case.

What about service usage?

It is strictly advisable to activate ICF services only if they are necessary for business needs in order to reduce the attack surface. Often there is no documentation which services are involved in what business functionality, some of them are even involved in more than one since they provide a framework functionality (e.g. for Webdynpro ABAP or BSP). So it might be hard for you to determine which service is truly needed in the first.

As a quick win you could analyse how often each service were called in each of your systems. To do so there are at least three methods:

extract the relevant info from the HTTP access log of the ICM (parameter icm/HTTP/logging_<xx>).

enable and evaluate the ICF trace using report RS_ICF_SERV_ADMIN_TASKS as mentioned in SAP note 2430473.

evaluate the Web Statistics.

Method 1 might be time consuming to gather all log files and grep and normalize the relevant parts.

Method 2 could have a performance impact as of SAP note 1611713.

Since Web Statistics are collected by default I recommend to use method 3. However, I like to advise to prolong the retention period of Web Statistics for this purpose in advance by following these steps:

Go to transaction ST03.

Go to Collector and Performance DB -> Performance Database -> Workload Collector Database -> Reorganization -> Control.

Adjust retention period for the WEB statistics, e.g. TOTAL Monthly Aggregates Retention Period for `VC` and `VD`.

Again: Repeat these steps for every system in your landscape.

After a reasonable time frame in which the Web Statistics for relevant phases (month end closing or alike) have been collected, the statistics can be exported by following these steps:

Go to transaction ST03.

Expand Workload -> Total -> Month -> and perform for each available month the following steps.

Expand Analysis Views -> Web Statistics -> WEB Server Statistics.

Switch to tab “URL”.Note: The Web Statistics may contain entries for services which are not even present in the system but are requested for example by a scanning server.
Hint: You may have noticed the column “Protocol” indicates if a service is called via HTTP or HTTPS.

Export the list of URLs as spreadsheet (“Excel (in Office 2007 XLSX Format)“) using the “Export” button. (Note: available as of SAP_BASIS 7.02).

Again: Repeat these steps for every system in your landscape.

Put the puzzle together

Now it is time to compare the list of active services with the list of called services to prepare the cleanup.

You can also think of comparing the lists across your system landscape. As already stated, for your development and integration system you should consider that there are indeed services active which are necessary for development purposes only or services which are in acceptance test and not yet set productive. These should be evaluated for the relevant systems. Talk to the developer team!

Besides that there may also be web applications activated which are used only for initial setup tasks, e.g. SAML2 configuration or troubleshooting e.g. sec_diag_tool. You should consider to activate these only at configuration time or as long as needed.

There may also be services which are actively used in the production system but are not activated in one or another system of the system landscape. It's time to eliminate this configuration drift.

Ok, lets start the preparation:

Copy the export of active services CSV file as a template.

Remove all lines which have an entry in column REF_PATH. These are aliases which point to a service node. Aliases can not be deactivated, but they will stop working if the original service is disabled.

Remove all lines for called services and their parent paths from the list so that you end up with a list of ICF services which can be deactivated in the relevant system.

Make sure no parent node stays in the list to be deactivated while it has sub nodes which should remain active. This would lead to so called "stale nodes" and non-working services. For example if /sap/bc/echo should stay active remove /sap, /sap/bc and /sap/bc/echo from the list.

Save this list of your to-be-deactivated services as CSV file.

Again: Repeat these steps for every system in your landscape.

Time to cleanup

Now you can start deactivating unused services in each system with your processed templates by following these steps:

Open the list of active ICF services, e.g. <SID>_acvite_services.csv and doublecheck if it holds only to-be-deactivated ICF services.

Go to transaction SE38.

Execute report RS_ICF_SERV_MASS_PROCESSING.

Select “Deactivate ICF Services for All Virtual Hosts Listed in CSV File” and execute.

Confirm the popup and upload the list to deactivate all services in the list.

Again: Repeat these steps for every system in your landscape.

Did you reveal a configuration drift? Activate the missing services in the relevant systems either manually in transaction SICF or by preparing a CSV file for mass activation.

Maybe you have overlooked some parent paths during creation of the list and they have now been deactivated accidentally. This is not that fatal. You simply can perform a fresh "Export of Active Services to CSV File" and use this to “Activate ICF Services for All Virtual Hosts Listed in CSV File”. The activation logic of the report will then take care of activating also all necessary parent nodes.

Keep in mind if something goes totally wrong you have also the initial export of active services as a backup which can be used to mass activate everything again as it was before.

Just as a side note:
The UCON HTTP whitelist scenario or former HTTP_WHITELIST does not serve for the same purpose as the UCON RFC Basic scenario. Meaning it does not affect the general reachability of certain paths through ICM! But this is a topic for another blogpost.

Whats next?

After finishing the deactivation in all systems, I recommend to "Export of Active Services to CSV File" once again. With this list you should start documenting your web services and their business need.

I started to collect information about SAP standard ICF services in https://github.com/J-Goerlich/Standard_ICF_services which may give you a hint if a service is needed in your scenario.

500 Internal Server Error. This browser is not supported - Error in Enterprise Portal in IE 11

2020-11-04T11:02:54+01:00

Overview :

A Webdynpro application is integrated in the Enterprise Portal to display the backend application to the end user

Recently, on upgrading/updating ECC or backend and on launching WD ABAP application in portal error is seen as 500 Internal Server Error. This browser is not supported, on launching from Internet Explorer 11.

Environment :

Enterprise Portal on SAP NetWeaver Java

WebDynpro ABAP

Cause :

The issue is caused by the application running in Quirks mode and going forward it will support Standards mode of rendering.

Refer KBA # 2398889 - Internet Explorer support for Enterprise Portal

As a limitation from Microsoft, IE11 can not render 2 contents using different document modes (quirks/standards) in the same frame/window

(This scenario works fine for Chrome and Firefox).

Solution :

The KBA # 2424773 - Display and Rendering issue in IE 11 in Portal has the steps to solve the issue.

The KBA has a quick test in the Cause Part, to check the requirement of the application in the browser via Console tab of the browser.

To solve the issue one of the below solution can be implemented in Portal

To make the portal run in standards mode by making use of the framework page - Ajax standards mode framework.

Changing the Launch in New Window" attribute (for iviews/pages) to "Display in separate headerless portal window (standards mode)"

End of Quirks Mode Support for Internet Explorer :

Starting from NetWeaver 7.52 and/or SAP Kernel 753 and/or SAP_UI 7.52 used in lower NetWeaver AS ABAP versions, Quirks Mode (IE 5.5 rendering mode) of Internet Explorer is no longer supported by SAP for all SAP UI technologies (the SAP release date is planned for the end of Q3/2017) and cannot be executed anymore.

If you use Enterprise Portal 7.50, change your framework page to Ajax Framework Page standards mode (AFP Standards) or Fiori Framework Page.
Refer Blog: Bye Bye Quirks

Additional Resources :

2398889 - Internet Explorer support for Enterprise Portal

1672817 - Browser: Microsoft Legacy Edge and Internet Explorer Support Policy Note

Web Dynpro ABAP - Browser supporting

Internet Explorer document modes

Introducing the SRT_MONI Generic Search Framework (GSF) - a new way of filtering SOAP Web Service Messages by content

2020-11-30T22:33:12+01:00

Introduction:

The transaction SRT_MONI is used to monitor ABAP-Web-Service-Messages (WS Messages). This transaction enables you to search for WS Messages, and filter them based on criteria like date, time, message ID, sender-, and receiver information etc. However, it is so far missing the functionality to filter the messages based on their content easily (transaction SRT_MONI also provides the possibility to search for content values, but that is more complex and can’t be run in background.

Therefore, the SRT MONI Generic Search Framework (GSF) was developed. It introduces a new modular way to filter the messages based on the information extracted from their corresponding XML data. The goal of this development is to create an easy and customizable way to filter WS Messages based on their content.

Details on the technical background can be found in the article Extension and enhancement of the SRT_MONI Generic Search Framework (GSF)

The new functionality is available by transaction code: SRT_MONI_GSF

To run this transaction the user needs to have the authorization to run transaction SRT_MONI.

User Interface

Figure 1 shows a screenshot of the User Interface. So far, the user interface consists of two major sections. The standard selection criteria, which is not customizable, and the enhanced selection criteria, which is customizable using the GSF. The customization is explained below.

The standard selection criteria are used to pre-select messages as shown in Figure 2 (the uppermost box). The section containing the enhanced selection criteria is used to browse the content of the WS message. The two dropdown menus “Search Object”, and “Selection Parameter” are used to group the technical names into different categories. The “Search Object” defines herby the generic term (e.g. Business Partner, Customer, Vendor etc.). The “Selection parameter” defines the subcategory (e.g. ID, Name etc.). Every Selection Parameter corresponds to an unlimited number of technical names. The grouping of the technical names is further explained in the enhanced technical description of Transaction SRT_MONI_GSF.

Figure 1 – User Interface

The pushbutton "Service Selection" provides the user with a popup (Figure 2) on which they can select the webservices they want to search for. By default, all webservices are selected. It is mandatory to select at least one webservice.

Figure 2 – Select / De-select Services

In the field “Value(s)”, enter the values you want to search for, e.g. different Business Partner IDs. After all fields are filled, the search can be started either by pressing F8, by clicking the button "Execute" in the lower right corner, or by choosing "More" -> "Program" -> "Execute". The search starts in the foreground. The screen is locked until the program is done. An example of a result list is shown in Figure 3.

Figure 3 – Example of a result list

The performance can be low due to a high number of messages that need to be extracted and analyzed. For that reason, foreground processing might not be useful. To offer more utility, background processing is available in the SRT Moni Generic Search Framework. By choosing "More" -> "Program" -> "Execute in Background", the search gets submitted as a job. You can display the running Job e.g. using transaction SM37 or via "More" -> "System" -> "Own Jobs". After the job has finished, the message IDs found are displayed in the print job log as shown in Figure 4.

Figure 4 – Example of a result list as job log

The message IDs can be easily copied and transported for further analysis to transaction SRT_MONI.

Delivery and initial usage hints

The new transaction is available via the following SAP notes:
2971973 - SRT_MONI_GSF Creation of package
2972601 - SRT_MONI_GSF Interface Note
2972602 - SRT_MONI_GSF Application Note Business Partner
2980590 - SRT_MONI_GSF Application Note T100 Messages

The SAP notes have to be applied in the given order.

Per default the new functionality is delivered for mainly Business Partner Services searching the name, number of the Business Partner or the number of the customer / supplier. Technically the supplier ID is listed as Vendor ID for historical reasons.

The search itself for the names of the Business Partner does support wildcard search - the standard SAP search parameters are provided.

Additionally all Services are used for an error message search. The error message search is very broad and should be provided with the following syntax:

(R11)046 (see Figure 5)

Figure 5 – Syntax for searching for message within the service messages

The message search also provides Wildcard search as well as a search containing only the corresponding message number.

Final remarks

As this is a very new functionality which hopefully enables easier acess to data echange via Web Services, a follow up Blog post will be provided to explain the technical bckground in more dtail and also will provide a step-by-step description of the very easy to use enhancement concept.

In case an error occurs you would need to raise an incident on application component LO-MD-BP-WS.

We have taken all measures possible to make this post as accurate as possible, but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know.
The above given dates and times might change without notice and/or reflection in this blog. For latest accurate dates and times, please check out the referenced, and non-referenced information available from SAP

Update:

With SAP Notes 3101750 and 3101780 also the sender interface name is introduced. The purpose and usage is analogues to the receiver (e.g. instead of receivernametable use sendernametable) interface name.

Extension and enhancement of the SRT_MONI Generic Search Framework (GSF)

2020-12-03T09:15:42+01:00

Introduction:

This blog post describes the technical background of the SRT_MONI Generic Search Framework (GSF) and explains how to create your own enhanced searches. For more general information on the SRT_MONI GSF please check out Introducing the SRT_MONI Generic Search Framework.

The transaction is accessible via these SAP notes:

2971973          -           SRT_MONI_GSF Creation of package (mandatory)
2972601          -           SRT_MONI_GSF Interface Note (mandatory)
2972602          -           SRT_MONI_GSF Application Note Business Partner (optional)
2980590          -           SRT_MONI_GSF Application Note T100 Messages (optional)
3000261 - Documentation for Report "Web Service Utilities: Generic Search Framework" (optional)

New functionality:

3101750 - The SRT_MONI Generic Search Framework does not offer the sender name of the service as filter criteria

Content of a WS message

The SRT_MONI GSF is used to filter Webservice (WS) messages based on it's content. So let's start by taking a look at how this content is structured (Figure 1) :

Figure 1 – Content of a WS Message

A WS message usually is structured very simple, since it just consists of a column called NAME, and a column called VALUE. We will call the values inside the NAME column “technical names” and the values from the VALUE column the “corresponding values”.

Technical Background

Before handing out a step-by-step guide on how to create own enhanced searches it is useful to know how the algorithm works.

Figure 2 – Search Algorithm

In Figure 2, the search algorithm is shown in detail. At first, the messages are selected based on the information extracted from the UI and the constructor of the specific subclass (e.g. time, date, processing status group, webservice name). The gathered messages are then extracted one by one and are filtered by their technical names and the corresponding values. If the search is successful, the message ID is saved, and the next message is analyzed until all messages have been browsed. If either the technical names or the corresponding values do not fit to the search parameters, the algorithm ignores the message, returns, and goes to the next message. After all messages have been analyzed, the saved message IDs are used to show a list of all found messages.

Please be aware that the search can take some time, since the algorithm needs to extract and analyze all messages found after the “Pre-Selection” (the uppermost box in figure 2). It is recommended to narrow down the search criteria as much as possible.

The SRT Moni Generic Search Framework also offers Background Processing as explained in Introducing the SRT_MONI Generic Search Framework

Enhancement of the User Interface (UI)

Figure 3 shows you the area of the UI that can be defined by the user. This includes the two dropdown menus "Search Object" and "Selection Parameter" and the button "Service Selections".

Figure 3 – Enhancement Area of the UI

The dropdown menus are used to combine the technical names in logical units. You can find a further explanation to this concept in chapter Grouping of technical names. The button offers the possibility to select from a customized list of webservices. This is further described in chapter Enhancement of the GSF.

Grouping of technical names

The grouping of the technical names is shown in Figure 7 as an example for the “Search Object” Business Partner. In this example the Business Partner has two “Selection Parameters”: ID and Name. Please note that this example is just for demonstration purposes!

Figure 4 – Grouping of the Technical Names as an Example for the “Search Object” Business Partner

The “Selection Parameter” ID has two technical names beneath it:

‘----InternalID’

‘----ReceiverInternalID’

The “Selection Parameter” Name has five technical names beneath it:

‘-------GivenName’

‘-------MiddleName’

‘-------FamilyName’

‘-------AdditionalFamilyName’

‘-------BirthName’

Please be aware that this example is just to demonstrate that different quantities (with no limit) of technical names can be assigned to one “Selection Parameter”.

During runtime, the values corresponding to the technical names are compared to the values entered in the field “Value(s)”. It is an select-option field and therefore the input of several values is possible, when you extend the field.

Enhancement of the GSF

But enough with the background information. Lets have a look at how you can create and implement your own searches. In this chapter you can find a step-by-step guide on how to enhance the GSF to use your own “Search Object”, “Selection Parameter” with corresponding technical names, and “Service Selection”. We tried to make this as user-friendly as possible.

The most important prerequisite is that you have imported and implemented at least the mandatory SAP notes mentioned in chapter Introduction.

This example will create a demo class.

Step 1

Create a new subclass of CL_SRT_MONI_GSF and press Save.

Figure 5 - Creation of a Demo Class as Subclass of CL_SRT_MONI_GSF

Step 2

Define and implement the constructor of this class by clicking on Constructor.

Figure 6 - Definition of the Constructor

Step 3

In the constructor, maintain the following attributes:

IF_SRT_MONI_GSF~IDENTIFIER TYPE STRING
- Defines the name of the “Search Object" in this case DEMO

Figure 7 - Enhanced Search Object Dropdown

IF_SRT_MONI_GSF~TECHNICALSEARCHCRITERIA TYPE TT_SRT_MONI_GSF_SEL_IDENT
- Defines the name of the “Selection Parameter” and the corresponding technical names

Figure 8 - Enhanced Selection Parameter Dropdown

You can use method IF_SRT_MONI_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC( ) to assist with the correct filling of the IF_SRT_MONI_GSF~TECHNICALSEARCHCRITERIA. To do so, call the method with the following parameters:

Importing Parameter: IV_SELECTION_IDENTIFIER TYPE STRING
- Specifies the name of the selection identifier

Changing Parameter: CT_SEARCH_PARAMETERS TYPE TT_SRT_MONI_TEC_PARAMS
- Specifies the names of the technical names
- TYPE TABLE OF STRING

The function must be called once for every entry in the selection parameter dropdown. So, in order to produce the dropdown as shown in Figure 8, you must call the method two times.

Step 4 (optional)

The constructor is already complete. After saving and activation the class is already usable. However, you can narrow down the search criteria further. This might be useful for certain Webservices. In the constructor, you can maintain optional attributes as shown below:

IF_SRT_MONI_GSF~RECEIVERNAMESINGLE TYPE STRING
- Specifies a single interface receiver name (e.g. wildcard ‘BusinessPartner*’)

IF_SRT_MONI_GSF~RECEIVERNAMETABLE TYPE IF_SRT_MONI_GSF~TT_SRT_MONI_GSF_SERVICE
- Specifies multiple interface receiver names
- If this table is filled, it is used by default. If the table is not filled, the value from IF_SRT_MONI_GSF~RECEIVERNAMESINGLE is used
- Table Type TT_SRT_MONI_GSF_SERVICES

In this example both IF_SRT_MONI_GSF~RECEIVERNAMESINGLE and IF_SRT_MONI_GSF~RECEIVERNAMETABLE are filled, so the programs logic will only show the values specified inside IF_SRT_MONI_GSF~RECEIVERNAMETABLE.

Figure 9 - Enhanced Service Selection Pop Up

With SAP Note 3101750 also the sender interface name is introduced. The purpose and usage is analogues to the receiver interface name (e.g. instead of receivernametable use sendernametable). You can find the complete constructor of our example class DEMO below:

 METHOD constructor.

    DATA: lt_tecsearch_param   TYPE if_srt_moni_gsf~tt_srt_moni_gsf_tec_params,

          ls_receivernametable TYPE if_srt_moni_gsf~st_srt_moni_gsf_services.

    super->constructor( ).



* Fill value for own name - used in first dropdown

    if_srt_moni_gsf~identifier = 'DEMO'.



* Fill value for object specific search values which are checked in the XMLs and group them if necessary



    APPEND 'DEMOTechnicalName1' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName2' TO lt_tecsearch_param.



    if_srt_moni_gsf~provide_tecselcrit_to_construc(

    EXPORTING

        iv_selection_identifier = 'DEMOSelectionParameter1'

    CHANGING

        ct_search_parameters    = lt_tecsearch_param ).



    APPEND 'DEMOTechnicalName3' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName4' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName5' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName6' TO lt_tecsearch_param.



    if_srt_moni_gsf~provide_tecselcrit_to_construc(

    EXPORTING

        iv_selection_identifier = 'DEMOSelectionParameter2'

    CHANGING

        ct_search_parameters    = lt_tecsearch_param ).



* Fill filter on receiver webservice name

* Logic is: If table filter is set, use ONLY these services. If not and single is set, use this one.

* If both are not set, display all

* Using single value only will increase the performance



    if_srt_moni_gsf~receivernamesingle = 'DEMOWebService*'.



    ls_receivernametable-name = 'DEMOWebService1'.

    ls_receivernametable-selected = abap_true.



    APPEND ls_receivernametable TO if_srt_moni_gsf~receivernametable.



    ls_receivernametable-name = 'DEMOWebService2'.

    APPEND ls_receivernametable TO if_srt_moni_gsf~receivernametable.



  ENDMETHOD.

Explanation: At first two attributes are declared. Afterwards, the constructor of the superclass is called. Then the name of the “Search Object” is defined, in this case, the name is ‘DEMO’. The dropdown menu “Selection Parameter” is filled by the two method calls. The table LT_TECSEARCH_PARAM is holding the technical names. In this example, the table was filled using an APPEND statement. Inside the method call IF_SRT_MONI_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC this table gets cleared, so it can be reused for the second method call. You can append an unlimited number of technical names to this table. In this state, the constructor will already be working. However, you can optionally fill in the receiver names as demonstrated in the code snippet. Note that there would be no need to fill the “receivernamesingle” here, because the “receivernametable” is filled automatically. By specifying

ls_receivernametable-selected = abap_true.

the Webservice appended to the "receivernametable" will be set to selected by default when starting the transaction.

Besides enhancing the UI and the search criteria in the constructor, you can also implement your own authorization and plausibility checks. To implement a customized authorization or plausibility check, the methods IF_SRT_MONI_GSF~AUTHORIZATION_CHECK and IF_SRT_MONI_GSF~OBJECT_PLAUSIBILITY_CHECK need to be redefined inside the Object Class.

Conclusion

In this blog post, an overview of how to extend the SRT_MONI GSF by customized searches was given. In addition, you learned about the search algorithm that is used by the framework. I hope that the SRT_MONI GSF will assist you when working with ABAP Web Service Messages.

In case an error occurs please raise an incident on application component LO-MD-BP-WS.

We have taken all measures possible to make this post as accurate as possible, but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know.
The above given dates and times might change without notice and/or reflection in this blog post. For latest accurate dates and times, please check out the referenced, and non-referenced information available from SAP.

How to send multiple ERP systems master data (ECC) to ARIBA On-Demand

2020-12-03T20:19:15+01:00

/ARBA/MASTER_DATA_EXPORT using this program we can upload master data to ARIBA Cloud from ECC

The program /ARBA/MASTER_DATA_EXPORT should be set up to run on a desired schedule to extract information from the relevant SAP tables for the objects

The output of the program is a .CSV file containing the information necessary for the update

The file automatically transmitted to the Ariba on -Demand application through an HTTP post

The file is received by the Ariba on-demand application processed by a receiving job that is triggered at the time the data is transmitted( Immediate processing in Ariba)

The values in Ariba on -Demand are updated with any errors noted in the processing log of the Ariba on-Demand administration console

Full load

Incremental Load

Following data can be transferred to Ariba Cloud

General ledger

InternalOrder

Costcenter

Wbselement

Asset

Supplier related data

Remittance location

Purchaseorg

User related data

User and User group

Companycode

Overview for multiple systems:

To differentiate Master Data from all the ERP(ECC) systems , We have to do prefix specific to system for the following data

Example : Supplier Number : 123456 , if we add prefix to suppplier it will be - ERP1_123456 like wise , we have to do for each and every system..

General ledger

InternalOrder

Costcenter

Wbselement

Asset

Supplier related data

Remittance location

Purchaseorg

User related data

User and User group

Companycode

Plant

How to do a prefix for master data ?

Following BADI will be implemented, prefix will be added in the runtime, send the data to Ariba

This Badi has multiple methods

each method is relevant for specific data like Company code , Plant ...using this methods we can enhance and prefix the master data

Example : prefixing Vendor Purchase group information

Code :

Data :lt_SYSTID_MAP type STANDARD TABLE OF /ARBA/SYSTID_MAP,

        ls_SYSTID_MAP type /ARBA/SYSTID_MAP,

        ls_vendor_info type /arba/vendor,

        ls_vendor_PORG_INFO type /arba/vendor_Po,

        lv_lifnr(20) type c,

        lv_lifnr1(20) type c,

        lv_ekorgx(20) type c,

        lv_namex(50) type c,

        lv_purcsx(20) type c,

        lv_sidx(20) type c,

        lv_tbix    type sy-tabix,

        lv_system(4) type c,

        lv_value TYPE tvarv_val,

        lv_name TYPE rvari_vnam VALUE 'ERP_ID'.





    SELECT SINGLE low " will read value from buffer

      INTO lv_value

      FROM tvarvc

     WHERE name = lv_name.

    IF sy-subrc = 0.

      lv_system = lv_value.

    ENDIF.

       CLEAR : lv_lifnr,lv_namex.

      LOOP AT  vendor_info[] INTO ls_vendor_info.

        lv_tbix = sy-tabix.



           CONCATENATE lv_system ls_vendor_info-lifnr INTO

                    lv_lifnr.

           CONCATENATE lv_system ls_vendor_info-name1 INTO

                    lv_namex.

           CONCATENATE lv_system ls_vendor_info-systemid INTO

                    lv_sidx.



        ls_vendor_info-lifnrx = lv_lifnr.

        ls_vendor_info-namex = lv_namex.

        ls_vendor_info-sidx = lv_sidx.



        MODIFY vendor_info from ls_vendor_info INDEX lv_tbix.

      ENDLOOP.



       LOOP AT  vendor_PORG_info[] INTO ls_vendor_porg_info.

        lv_tbix = sy-tabix.



           CONCATENATE lv_system ls_vendor_porg_info-lifnr INTO

                    lv_lifnr.

           CONCATENATE lv_system ls_vendor_porg_info-ekorg INTO

                    lv_ekorgx.



        ls_vendor_porg_info-lifnrx = lv_lifnr.

        ls_vendor_porg_info-ekorgx = lv_ekorgx.





        MODIFY vendor_porg_info from ls_vendor_porg_info INDEX lv_tbix.

      ENDLOOP

Conclusion : This way , We can send multiple ERP system data to ARIBA Cloud .

SAP Netweaver GoogleAuthenticator/FreeOTP for Fiori Launchpad using Keycloak (on Premise)

2021-01-30T20:05:58+01:00

In this article we will learn to configuring Multi-factor Authentication (MFA) or 2 Factor Authentication(2FA) for on premise Fiori Launchpad using Keycloak; an open source Identity and Access Management tool.

Image icons courtesy SAP and Keycloak

Things required for this configurations:

Keycloak

Fiori Launchpad on SAP Netweaver

Google Authenticator or FreeOTP

Keycloak is available as free to download (Apache license) in multiple deployment options, I will be using standalone server deployment for this purpose but the configuration steps will not change based on deployment options. This article covers configuration aspect of Keycloak, and installation is beyond scope of this article, though standalone installation is fairly simple and it requires just a single command.

The SAML configuration steps are nearly identical in all SAP Netweaver versions, I will be using 7.52 for this article.

We will be using Keycloak as Identity Provider (IdP) and SAP Netweaver as Service Provider(SP). First step is to configure SAP Netweaver as SP, so head over to SAP GUI and launch SAML configuration using transaction code "SAML2". This will launch SAML configuration web page (if you see an error, activate SAML2 service in SICF) which looks like below:

Click on "Enable SAML 2.0 Support" and select "Create SAML 2.0 Local Provider" option.

On next screen enter provider name, usually FQDN is preferred for better understanding but it is not mandatory to do so, any name would work.

Click next to continue.

Everything can be left as default, however, if you prefer not see IdP selection page before redirecting to IdP login page, select "Automatically", and click finish.

Congratulations! you have successfully configured SAP Netweaver as Service Provider(SP). isn't that easy?

Now head-over to Keycloak, after successful login Keycloak configuration page looks like below:

We need SAML2 certificate and metadata to setup trust relationship between SAP Netweaver and Keycloak. Click on "SAML 2.0 Identity Provider Metadata" next to "Endpoints" and save it as ".xml" file.

Now, we have to upload metadata and SAML2 certificate in SAP Netweaver, switch back to SAP Netweaver SAML2 configuration page.

Click on "Trusted Providers" tab and add "Upload Metadata Files".

Upload metadata file downloaded earlier from Keycloak configuration page.

Click next to continue, if alias configured on this page, it will be shown on IdP selection before redirecting to IdP login page.

Click next to continue, if this is production installation make sure to change "Digest Algorithm" to higher value possibly SHA-256.

Click next to continue

Keycloak user will be mapped using email attribute, so select "Comparison Method" "Minimum" and add "PasswordProtectedTransport" in "List of Requested Authentication Context". These are bare minimum settings required to use user mapping, if this is production install I would recommend to use better "Comparison Method"

The configuration wizard will finish on this page, next we need to map Keycloak user attribute to SAP Netweaver user.

Click edit and add email in "Supported NameID Formats" and change "User ID Mapping Mode" to "Logon Alias".

In this step, we will map Keycloak user attribute "Email" to SAP Netweaver user attribute "Logon Alias", make sure to maintain both email and logon alias in respective systems.

Save and Enable.

Congratulations! another mile stone, we have successfully setup trust relationship between Keycloak and SAP Netweaver. However, Keycloak does not recognise SAP Netweaver system as a client yet. So, let's download metadata from our Service provider i.e SAP Netweaver.

Switch to "Local Provider" tab and click on "Metadata" button, a prompt will show Metadata download option, download to local drive.

Switch back to Keycloak configuration page and select "Clients". Create a new client using "Create" button on right.

Import SAP Netweaver metadata file downloaded earlier and save the configuration. We have successfully completed bidirectional trust relationship between Keycloak and SAP Netweaver.

Last step is to create users in both the systems and assign their mapping attributes. i,e E-mail ID and Logon Alias in Keycloak and SAP Netweaver respectively.

Click on "Users" and create a new user with email ID. Unlikely Tony Stark will use Keycloak, let's assume JARVIS controls everything though SSO.

Save user and make sure to maintain password on "Credentials" page (turnoff "Temporary" switch to make sure system doesn't prompt for password change)

Create a new user in SAP with logon alias as email ID created earlier in Keycloak, this is a last step in our configuration.

Now, it's time to test our brand new configuration, run "/n/UI2/FLP" transaction in SAP GUI to launch Fiori Launchpad and copy the URL. Open launchpad URL in another browser or in a new private mode tab. If you had selected "Identity Provider Discovery: Common Domain Cookie" earlier as automatic you will be redirected to Keycloak login page else you need to click continue on SAP Netweaver login page and the system will redirect to Keycloak login page as below:

Now it is time to test our user, enter username and password and click "Log in", on successful authentication the login page will redirect to Fiori Launchpad.

Next step is to activate MFA, switch back to Keycloak and edit user "Tony" or whatever user you had created earlier.

Select "Configure OTP" under "Required User Actions". On next logon, the system will prompt to link you mobile device using "FreeOTP" or "Google Authenticator" OTP app, follow the instructions.

That's it, Congratulations! You have MFA enabled Fiori Launchpad.

If you like this article, feel free to share, tweet, like or follow me for new articles.

Extension and enhancement of SXI_MONITOR Generic Search Framework

2021-05-17T19:38:40+02:00

Introduction

This blog post describes the technical background of the SXI_MONITOR Generic Search Framework and explains how to create your own enhanced searches. For more general information on the SXI_MONITOR_GSF please check out Introducing the SXI_MONITOR Generic Search Framework.

The new transaction is available via the following SAP notes:

2971973 - SRT_MONI_GSF Creation of package

3035719 - Generic Search Framework for SXI_MONITOR - Interface Note

3035724 - Generic Search Framework for SXI_MONITOR_GSF - Application Note BP

Content of an XML message

The SXI_MONITOR Generic Search Framework is used to filter XML message based on its content. The following figure shows how an XML message is structured.

Figure 1: Content of a XML Message with Organization Data

An XML message as shown above consists of elements, attributes, their value assignments, and the content of the elements. The fields marked in red in the above example are called "technical names", and the corresponding values marked in green are called "corresponding values".

Technical Background

Before we look at how the extension and enhancement of the SXI_MONITOR Generic Search Framework can be carried out, let's take a closer look at how the algorithm works.

Figure 2: Search Algorithm

The figure above shows the search algorithm in detail. The first step is to filter the XML messages based on the information specified on the user interface and in the constructor of the subclass. The filter consists of various information such as: Date, time, status group or name of the service. The gathered XML messages are then extracted one by one and are filtered by their technical names and the corresponding values. If there is an XML message that fits to the technical names and corresponding values, the message ID is saved. If there is no XML message that not fit to the search parameter, the algorithm ignores the message and goes to the next XML message. All these steps are carried out until all XML messages have been processed. Finally, the XML messages that are found and stored with the message ID are show as a list.

Please be aware that the search can take some time, since the algorithm needs to extract and analyze all messages found after the “Pre-Selection”. It is recommended to narrow down the search criteria as much as possible.

The SXI_MONITOR Generic Search Framework also offers Background Processing as explained in Introducing the SXI_MONITOR Generic Search Framework.

Enhancement of the User Interface

Below you can see the user interface of SXI_MONITOR Generic Search Framework, which can be defined by the user. This includes the two dropdown menus “Search Object” and “Selection Parameter” and the button “Service Selections”.

Figure 3: Enhancement Area of the User Interface

Grouping of technical names

The grouping of the technical names is shown as an example for the “Search Object” Business Partner. In this example the Business Partner has two “Selection Parameters”: ID and Name. Please note that this example is just for demonstration purposes!

Figure 4: Grouping of the Technical Names as an Example for the “Search Object” Business Partner

The “Selection Parameter” ID has three technical names beneath it:

‘PartyID’

‘BusinessPartnerInternalID’

RelationshipBusinessPartnerInternalID’

The “Selection Parameter” Name has 10 technical names beneath it:

‘Name1’

‘Name2’

‘Name3’

‘Name4’

‘GivenName’

‘SecondName’

‘FamilyName’

‘BirthName’

‘MiddleName’

‘PreferredGivenName’

Please be aware that this example is just to demonstrate that different number of technical names can be assigned to one “Selection Parameter”.

During runtime, the values corresponding to the technical names are compared to the values entered in the field “Value(s)”. It is an select-option field and therefore the input of several values is possible.

Enhancement of the Generic Search Framework

In this part of the blog post we will take a step-by-step look at how to enhance the Generic Search Framework for your own “Search Object”, “Selection Parameter” with corresponding technical names, and “Service Selection”. We tried to make this as user-friendly as possible. The most important prerequisite is that you have imported and implemented at least the mandatory SAP notes mentioned in chapter introduction. This example will create a demo class.

Step 1:

Create a new subclass of CL_SXI_MONITOR_GSF and save it.

Figure 5: Creation of a Demo Class as Subclass of CL_SXI_MONITOR_GSF

Step 2:

Define and implement the constructor of this class by clicking on Constructor.

Figure 6: Definition of the Constructor

Step 3:

In the constructor, maintain the following attributes:

IF_SXI_MONITOR_GSF~IDENTIFIER, which defines the name of the “Search Object”

Figure 7: Enhanced Search Object Dropdown

IF_SXI_MONITOR_GSF~TECHNICALSEARCHCRITERIA, which defines the name of the “Selection Parameter” and the corresponding technical names

Figure 8: Enhanced Selection Parameter Dropdown

For the correct filling of “Selection Parameter” you can use the method IF_SXI_MONITOR_GSF~PROVIDE_TECSELCRIT_TO_CONSTRUC( ). To do so, call the method with the following parameters:

Importing Parameter: IV_SELECTION_IDENTIFIER, which specifies the names of the selection identifier

Changing Parameter: CT_SEARCH_PARAMETERS, which specifies the names of the technical names

The function must be called once for every entry in the selection parameter dropdown. So, to produce the dropdown as shown in Figure, you must call the method three times

Step 4 (optional):

An optional enhancement can still be added, which can narrow down the search criteria. This is the “Service Selection”, which is also added in the constructor. To do this, the following steps should be carried out:

IF_SXI_MONITOR_GSF~SENDERNAMESINGLE, which specifies a single interface sender name (e.g. wildcard ‘*BusinessPartner*’).

IF_SXI_MONITOR_GSF~SENDERNAMETABLE, which specifies multiple interface sender names. If this table filled, it is used by default.

IF_SXI_MONITOR_GSF~RECEIVERNAMESINGLE, which specifies a single interface receiver name.

IF_SXI_MONITOR_GSF~RECEIVERNAMETABLE, which specifies multiple interface receiver names. If this table filled, it is used by default.

Figure 9: Enhanced Service Selection Pop Up

You can find the complete constructor of our example class DEMO below:

METHOD constructor.

    DATA: lt_tecsearch_param   TYPE if_sxi_monitor_gsf~tt_sxi_monitor_gsf_tec_params,

          ls_sendernametable TYPE if_sxi_monitor_gsf~st_sxi_monitor_gsf_services,

          ls_receivernametable TYPE if_sxi_monitor_gsf~st_sxi_monitor_gsf_services.





    super->constructor( ).



* Fill value for own name - used in first dropdown

    if_sxi_monitor_gsf~identifier = 'DEMO'.



* Fill value for object specific search values which are checked in the XMLs and group them if necessary



    APPEND 'DEMOTechnicalName1' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName2' TO lt_tecsearch_param.



    if_sxi_monitor_gsf~provide_tecselcrit_to_construc(

    EXPORTING

        iv_selection_identifier = 'DEMOSelectionParameter1'

    CHANGING

        ct_search_parameters    = lt_tecsearch_param ).



    APPEND 'DEMOTechnicalName3' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName4' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName5' TO lt_tecsearch_param.

    APPEND 'DEMOTechnicalName6' TO lt_tecsearch_param.



    if_sxi_monitor_gsf~provide_tecselcrit_to_construc(

    EXPORTING

        iv_selection_identifier = 'DEMOSelectionParameter2'

    CHANGING

        ct_search_parameters    = lt_tecsearch_param ).



    if_sxi_monitor_gsf~provide_tecselcrit_to_construc(

    EXPORTING

        iv_selection_identifier = 'DEMOSelectionParameter3'

    CHANGING

        ct_search_parameters    = lt_tecsearch_param ).



* Fill filter on sender webservice name

* Logic is: If table filter is set, use ONLY these services. If not and single is set, use this one.

* If both are not set, display all

* Using single value only will increase the performance



    if_sxi_monitor_gsf~sendernamesingle = 'DEMOSenderService*'.

    if_sxi_monitor_gsf~receivernamesingle = 'DEMOReceiverService*'.



    ls_sendernametable-name = 'DEMOService1'.

    ls_sendernametable-selected = abap_true.



    APPEND ls_sendernametable TO if_sxi_monitor_gsf~sendernametable.



    ls_sendernametable-name = 'DEMOService2'.

    APPEND ls_sendernametable TO if_sxi_monitor_gsf~sendernametable.



    ls_sendernametable-name = 'DEMOService3'.

    APPEND ls_sendernametable TO if_sxi_monitor_gsf~sendernametable.



    ls_receivernametable-name = 'DEMOReceiverService4'.

    ls_receivernametable-selected = abap_true.



    APPEND ls_receivernametable TO if_sxi_monitor_gsf~receivernametable.



    ls_receivernametable-name = 'DEMOReceiverService5'.

    APPEND ls_receivernametable TO if_sxi_monitor_gsf~receivernametable.



    ls_receivernametable-name = 'DEMOReceiverService6'.

    APPEND ls_receivernametable TO if_sxi_monitor_gsf~receivernametable.

ENDMETHOD.

Explanation:

First, two data elements are declared that are necessary for the technical search criteria and for the service selection. Then the constructor of the superclass is called. The next step is to define the name of the search object, in this case the search object has the name DEMO. There are two method calls that are responsible for filling the selection parameters. The associated technical names were added to the table LT_TECSEARCH_PARAM with the APPEND command. In the lower part of the coding you can optionally specify the service selections. With IF_SXI_MONITOR_GSF~SENDERNAMESINGLE and/or IF_SXI_MONITOR_GSF~RECEIVERNAMESINGLE you can define a service. With IF_SXI_MONITOR_GSF~SENDERNAMETABLE and/or IF_SXI_MONITOR_GSF~RECEIVERNAMETABLE you have the possibility to create several services. Besides enhancing the UI and the search criteria in the constructor, you can also implement your own authorization and plausibility checks. To implement a customized authorization or plausibility check, the methods IF_SXI_MONITOR_GSF~AUTHORIZATION_CHECK and IF_SXI_MONITOR_GSF~OBJECT_PLAUSIBILITY_CHECK need to be redefined inside the Object Class.

Conclusion

In this blog post I have given you an overview of how you can expand SXI_MONITOR Generic Search Framework using self-defined search objects. You also saw briefly how the algorithm of the Generic Search Framework works. I hope that the SXI_MONITOR GSF can help you with working with XML messages.

In case an error occurs please raise an incident on application component LO-MD-BP-WS.

We have taken all measures possible to make this post as accurate as possible, but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know.

The above given dates and times might change without notice and/or reflection in this blog post. For latest accurate dates and times, please check out the referenced, and non-referenced information available from SAP.

Introducing the SXI_MONITOR Generic Search Framework

2021-05-18T08:24:44+02:00

Introduction

The transaction SXI_MONITOR is used to monitor XML-Messages. This transaction enables you to search for XML-Messages, and filter them based on criteria like date, time, message ID, sender-, and receiver information etc. However, it is so far missing the functionality to filter the messages based on their content easily (transaction SXI_MONITOR also provides the possibility to search for content values, but that is more complex and can’t be run in background).

Therefore, the SXI Monitor Generic Search Framework (GSF) was developed. It introduces a new modular way to filter the messages based on the information extracted from their corresponding XML data. The goal of this development is to create an easy and customizable way to filter XML-Messages based on their content.

Details on the technical background can be found in the article Extension and enhancement of the SXI_MONITOR Generic Search Framework.

The new functionality is available by transaction code: SXI_MONITOR_GSF

User Interface

Figure 1 shows a screenshot of the User Interface. So far, the user interface consists of two major sections. The standard selection criteria, which is not customizable, and the enhanced selection criteria, which is customizable using the GSF. The customization is explained below.

The standard selection criteria are used to pre-select messages as shown in Figure 1 (the uppermost box). The section containing the enhanced selection criteria is used to browse the content of the XML-message. The two dropdown menus “Search Object”, and “Selection Parameter” are used to group the technical names into different categories. The “Search Object” defines herby the generic term (e.g. Business Partner, Customer, Vendor etc.). The “Selection parameter” defines the subcategory (e.g. ID, Name etc.). Every Selection Parameter corresponds to an unlimited number of technical names. The grouping of the technical names is further explained in the enhanced technical description of Transaction SXI_MONITOR_GSF.

Figure 1: User Interface

The pushbutton “Service Selection” provides the user with a popup (Figure 2) on which they can select the webservices they want to search for. By default, all webservices are selected. It is mandatory to select at least one webservice.

Figure 2: Select/De-select Services

In the field “Value(s)”, enter the values you want to search for, e.g. different Business Partner IDs. After all fields are filled, the search can be started either by pressing F8, by clicking the button “Execute” in the lower right corner, or by choosing “More” -> “Program” -> “Execute”. The search starts in the foreground. The screen is locked until the program is done. An example of a result list is shown in Figure 3

Figure 3: Example of a result list

The performance can be low due to a high number of messages that need to be extracted and analyzed. For that reason, foreground processing might not be useful. To offer more utility, background processing is available in the SXI Monitor Generic Search Framework. By choosing “More” -> “Program” -> “Execute in Background”, the search gets submitted as a job. You can display the running Job e.g. using transaction SM37 or via “More” -> “System” -> “Own Jobs”. After the job has finished, the message IDs found are displayed in the print job log as shown in Figure 4.

Figure 4: Example of a result list as job log

The message IDs can be easily copied and transported for further analysis to transaction SXI_MONITOR.

Delivery and initial usage hints

The new transaction is available via the following SAP notes:

2971973 - SRT_MONI_GSF Creation of package

3035719 - Generic Search Framework for SXI_MONITOR - Interface Note

3035724 - Generic Search Framework for SXI_MONITOR_GSF - Application Note

The SAP notes have to be applied in the given order.

Per default the new functionality is delivered for mainly Business Partner Messages searching the name, number of the Business Partner or the number of the customer / supplier.

The search itself for the Business Partner does support wildcard search – the standard SAP search parameters are provided.

Final remarks

As this is a very new functionality which hopefully enables easier access to data exchange via XML-Messages, a follow up Blog post will be provided to explain the technical background in more detail and also will provide a step-by-step description of the very easy to use enhancement concept.

In case an error occurs, you would need to raise an incident on application component LO-MD-BP-WS.

We have taken all measures possible to make this post as accurate as possible, but things sometimes fall through the cracks. In case you find any errors or inconsistencies please let us know.

The above given dates and times might change without notice and/or reflection in this blog. For latest accurate dates and times, please check out the referenced, and non-referenced information available from SAP

Using WebServices to transfer data to SAP BW- SOA Manager and SOAP Configurations

2022-01-31T21:57:58+01:00

Introduction-

WebService is one of the RDA (Realtime Data Access) techniques that can be used as a Push mechanism to transfer from data in the form of XMLs to SAP BW and HANA systems.

Web Services are mostly used to transfer the data in SAP BW/ HANA environments when the data mostly resides on web portals or on some external servers which are non-compatible or can not directly communicate with SAP, then by enabling the SAP's SOAP services this form of data can be pushed to SAP BW and HANA system's staging and architected data marts or any other layer which is used for reporting purpose.

Basically the data in SAP BW is received in the form of requests either through Pull or Push mechanisms. Pull mechanism is active when the data is residing in the Delta Queues and BW daemon jobs or ODP extractors or normal InfoPackages bring them through the IDOCs to BW PSA or ADSOs respectively.

Through the Push mechanism also data gets fetched in SAP BW only but External system plays the role of controlling the data transfer either in a scheduled manner or on adhoc basis.

Both form of data can be tracked using the Request IDs in SAP.

Detailed Overview and Steps -

Now that we are clear with the basic understanding of the scenario when to enable the WebServices for pushing data to SAP BW lets find the detailed steps which are mandatory for such type of data extractions.

Check for soap services whether it is active or not in tcode SICF. Click execute button.

TCode- SICF

2. Drilldown as per below to find soap –
Default_host -> sap -> bw -> xml -> soap.

If soap is not active, right click on it and activate it.

Soap in SICF

3. Create a Data Source with the file format provided by any non-sap system under Web Services Source System.

Data Source Creation in SAP BW

4. Navigate to SOAMANAGER tcode. Open below highlighted-

SOA Management

5. Click on the required function module for the data source created.

6. Click on Create Service.

7. Enter details with meaningful texts and click Next.

8. Select as per below-

9. Click Next-

10. Click Finish-

11. You will find the Service is activated.

12. Click on below highlighted button.

13. Below URL will get generated.

WSDL URL

14. Click on below highlighted button.

15. You may find below error for incorrect Port and Host Name.

16. Go back to main screen of SOAMANAGER and Open below.

17. Open Web Services Navigator and maintain entries for Hostname and Port name (This information needs to be provided by the external system’s Administrator or SAP Basis.

18. Navigate to the path in SICF shown in automated URL which was generated while creating the Service.

19. If wsdl is inactive, right click , activate and then right click again and Test.

20. The result will show in a web page when you execute the WSDL url in an XML page format showing the data from backend source table.

This way you can configure the WebServices to push the data from the external source tables in to SAP BW system's staging layers. From the PSA it can either be pulled manually to other data marts or schedule the load via process chains.

Integrate SAP TM-ECC by Enhancing Standard Webservice Without PI

2022-05-02T10:26:33+02:00

Introduction

SAP TM or Transport Management System is used to optimize logistics by managing all aspects of Transportation processes within a company. Not only it streamlines the logistics businesses by improving efficiency, but it also helps in reducing cost of business. One of the key aspects of implementing SAP TM is its integration with ECC system. In many cases, data is replicated using Service Interfaces. It is also quite common that customized structures or attributes need to be replicated from SAP TM to ECC.

Accommodate the custom attributes, the webservice need to be enhanced. This enhancement can be done with or without involving PI as a middleware.

In this blogpost, I have shared the solution to enhance webservices via Point-to-Point connection using SOAMANAGER technology. Using Backend Metadata Repository, the enhancement can be achieved.

Requirement

Shipments can be created in ECC from Freight Order in SAP TM. The shipment created in ECC does not have the vehicle type. Therefore, we will enhance the webservice to send the Vehicle Type through a custom attribute from TM to ECC.

Prerequisites

Access to SAP TCodes like SPROXY, SRT_MONI, SPXNGENAPPL

Knowledge of SAP ABAP, BOPF coding.

Solution

Step 1: Create Custom Namespace in TM System

Go to TCode SPXNGENAPPL to create the custom namespace under which the enhancement will be created.

Create an entry for the custom namespace (Format: http://CompanyName/xi/RelevantName). Choose the option Backend Metadata Repository from the dropdown from the right column.

Save the entry. It does not get captured in TR. We must create the entry manual in higher environments.

To easy identification, use the namespace of the Standard Webservice and append some meaningful name at the end separated by ‘/.’ The custom namespace name is critical. X`

The same namespace will be present under namespaces in SPROXY, and the enhanced nodes and structures will be saved there.

Step 2: Enhance Standard Webservice in TM System

Locate the Webservice.

Now go to TCode SPROXY. Find the Service to be enhanced. Double click on it. The Service Consumer details will display on the right. Go to Internal View Tab.

We will use the following webservices in TM and in ECC, respectively.

TM: TransportationOrderSCMExecutionRequest_Out (Service Consumer)

ECC: TransportationOrderSCMExecutionRequest_In (Service Provider)

Find the Node to be Enhanced

Here, we will be enhancing the node TRANSPORTATION_ORDER_EXECUTION and adding custom attributes to it.

Click on the node TRANSPORTATION_ORDER_EXECUTION and once the window on the appears, double click on the ABAP Name (Here, /SCMTMS/CPX_TOR_SCMEXR_TOREXE) under Global Data Type with Elements.

The node structure will open. Go to Proxy Editor.

Click on Create Enhancement to create Data Type Structure. A wizard will appear.

Provide Enhancement Name as per the naming conventions followed by the organisation. In the namespace, provide the namespace name you have maintained earlier for the MDR. Next, click on Continue button at the bottom.

In the next step, maintain Package, Transport Request No and Prefix name. The prefix is for internal attributes. If TR number is not known, check Local Button.

Click on Continue and Finish. Once done, click on SAVE button to save the changes.

Now go to External View to add custom attributes to the structure environment. You can add individual attributes, or you can add a custom data type to the enhancement.

To add an attribute or element, right click on the Enhancement Name and choose attribute or element.

If you want to add a custom data type, choose Add Element, and provide appropriate name starting with YY or ZZ.

Now, right click on the Element Name and choose Set Global Type Reference to create custom reference for the datatype.

Here you can create your own reference or use existing ones. Creating reference will open a wizard like the previous one. Once you have created the reference, add maximum length and type to the elements.

After creation of custom fields, save and activate the changes.

Step 3: Add Custom Code for Custom Attributes in ECC

We need to add our own custom code to perform data mapping for the custom attributes. This will allow the system to send the data from the system to the XML message.

BADI in TM System: /SCMTMS/TOR_SE_SHPMNT_REQ

Interface: /SCMTMS/TOR_IF_SE_SHPMNT_REQ

Create BADI Implementation and add your code to complete the mappings of the attribute.

The data present in the OUT structure is finally send to the XML message. Therefore, the data manipulation or data population of the custom attributes should be done in the OUT structure.

In TM system, every document acts like an Object. Therefore, BOPF coding might be required the required value.

After replication, the XML message can be checked in SRT_MONI TCode to display XML messages. You can check whether the XML message has been successfully processed in the system. This is visible both in Source and Target System.

Step 4: Create Custom Namespace in ECC System

Repeat Step 1 in ECC system as well. Be extra careful to maintain the exact Namespace name as it was maintained in TM system.

This is crucial as identical mappings and names in source and target will ensure that XML is mapped properly, and data is flowing between the system successfully.

Step 5: Enhance Standard Webservice in ECC

Webservice Name in ECC: TransportationOrderSCMExecutionRequest_In (Service Provider)

Follow the same steps as they were in step 2. Keep the names in every step identical in both source and Target system. So, the enhancement name, structure name, attribute name as well as the data types should be identical in both systems.

And most importantly, the Custom Namespace (MDR) name should be identical, even upper case and lower case.

Step 5: Add Custom Code for Custom Attributes in ECC

Like the Source system, the custom attributes need to be mapped to the correct fields in the Target system for further usage.

BADI in ECC is: TRA_SE_TO_SHPMNT_RQ_IN

Interface: IF_TRA_SE_TO_SHPMNT_RQ_IN

Here, the incoming data from the XML message will be stored in the IN structure. The data received from TM system can be stored in Standard Table as well Custom table to be used later.

Conclusion

In this blog post, we have enhanced a standard webservice by addition of custom attributes without involving PI system. This Point-to-Point communication system can be used in multiple scenarios without involving any middleware or third parties. It is synchronous and efficient and highly effective.

ABAP REST API http Service call from Postman: JSON to ABAP data

2022-05-10T09:42:07+02:00

This blog post will describe the steps of how to expose REST API and handle REST API request from SAP ECC 6.0 without installing SAP Gateway service builder component. It will also help to convert json data to ABAP data. In this blog post I have described how to build web server service in ECC application server of Rest APIs using JSON data format.

Prerequisite JSON data format, SAP logon and postman.

Define JSON structure:

JSON is a text-based data format which follow JavaScript object syntax. It stores the value in form of key value pair. Each of the property and value is separated with colon (:).

In ABAP define JSON structure which will be posted though POST request body and will be handled by HANDLE_REQUEST method. In se11 create JSON structure.

JSON structure and Table Type:

Implement http Request handle Method inside handling class:

Create a class ZMG_TEST_JSON with public instantiation using t-code se24 and add HANDLE_REQUEST standard method.

Inside the class, Implement HANDLE_REQUEST standard method of interface IF_HTTP_EXTENSION. Implemented method will process POST request with JSON body which will be posted through postman. Request can also be triggered from AZURE or any other third-party.

Maintain Service: ICF Hierarchy service:

Internet Communication Framework (ICF) services is an integrated component of Application server which allows us to communicate with SAP systems using internet standard protocol HTTP, HTTPs SMTP etc.

SICF t-code to create independent service ZMG_TEST_SRV in ICF hierarchy.

To link handler class with created service, in service's hander list tab add created handler class (ZMG_TEST_JSON) and save.

Adding ZMG_TEST_JSON class in service:

Service will be created in the selected path. Right click and activate the service.

Activate Service:

Right click and test the service. Server URL will be generated.

Service URL:

In SAP ECC, put a debugger in implemented HANDLE_REQUEST method of ZMG_TEST_JSON.

Http Post in REST API:

POST is a request method supported by HTTP used by the World Wide Web. By design, the POST request method requests that a web server accept the data enclosed in the body of the request message. It is often used when uploading a file or when submitting a file in request body. Submitting the request with JSON body.

Open Postman and paste the generated URL. Check header parameters, paste JSON body and send the request.

Postman Collection:

Send request to server for process:

HTTP request methods (GET, POST, PUT, DELETE, COPY …) are embedded in header field with the name '~request_method' uri service path of request header with the name '~request-uri'

ABAP built for converting JSON data format to ABAP data format:

As per implemented method posted json will be parsed and will be stored in sap internal table.

HANDLE_REQUEST_Implementation:

METHOD if_http_extension~handle_request.

  TYPES: BEGIN OF ly_emp,

         number          TYPE char7,

         dateofjoining   TYPE char40,

         name            TYPE char40,

   END OF ly_emp.

  TYPES: BEGIN  OF ly_post_res,

         departmentcode   TYPE char10,

         departmentname   TYPE char50,

         employee         TYPE ly_emp,

         END OF ly_post_res.

  DATA:

        lv_request_uri      TYPE string,

        lv_request_method   TYPE string,

        lv_content_type     TYPE string,

        lv_req_body         TYPE string.

  DATA: cl_fdt_json   TYPE REF TO cl_fdt_json,

        lx_root       TYPE REF TO cx_root,

        ls_data       TYPE zmg_json_struct,

        lt_final      TYPE TABLE OF zmg_json_struct.



  lv_request_uri         = server->request->get_header_field( name = '~request_uri' ).

  lv_request_method      = server->request->get_header_field( name = '~request_method' ).

  lv_content_type        = server->request->get_header_field( name = 'content-type' ).



  lv_req_body = server->request->get_cdata( ).



  IF lv_req_body IS NOT INITIAL.

    REPLACE ALL OCCURRENCES OF REGEX '[^[:print:]]' IN lv_req_body WITH space.

    REPLACE ALL OCCURRENCES OF REGEX '#' IN lv_req_body WITH space.

    CONDENSE lv_req_body.

    CREATE OBJECT cl_fdt_json.

    TRY.

        CALL METHOD cl_fdt_json=>json_to_data

          EXPORTING

            iv_json = lv_req_body

          CHANGING

            ca_data = ls_data.

      CATCH cx_root INTO lx_root.

    ENDTRY.

  ENDIF.



ENDMETHOD.

JSON data to ABAP data:

Parsing JSON header data:

Parsing JSON Item data:

By following above steps, we can covert json data to ABAP data and store it into table.

Summary:

During one of our projects requirements, I have gone through several REST API documents. Most of the documents, blog post and articles describes the ways of REST API call which convert ABAP data to JSON data, not vice versa. From my learning and SAP-Non-SAP integration experience I have organized REST API call from JSON format to ABAP format without having SAP_GWFND (SAP Gateway Foundation) component or Separate Gateway server installed in landscape.

Please do like the blog post, if you find the content helpful. Also, do share your comments and inputs, if any.

SAP Webdispatcher webadm user got deleted!!

2022-10-24T20:32:05+02:00

Hi All,

Recently I came across a very weird situation where after installation of SAP Web Dispatcher and setting up of SSL I found that I wasn't able to login to Admin page, the credentials of webadm user weren't working.

There were lots of messages in /usr/sap/SID/W00/work/dev_webdisp as below:

[Thr 139921060026112] Sun Oct 23 09:55:29:304 2022
[Thr 139921060026112] *** ERROR => HttpAdmHandleReq: authorization failed for user: webadm [http_adm.cpp 2596]

So, as a normal practice, I tried to go ahead with resetting the webadm password as per Note:1987484 - Forget password for SAP webdispatcher web Administration Interface

What I found weird is that first of all icmauth.txt authentication file didn't exist in /usr/sap/SID/SYS/global/security/data directory.

Hence, I followed below steps to recreate the webadm user and for reset of the password.

Stop the Webdispatcher.

Go to the webdispatcher executable folder.

For example, /usr/sap/<WDP SID>/<WDP instance name>/exe

There you can find the wdispmon executable.

Run "wdispmon -a pf=<x:\path to webdispatcher profile\instance_profile>".

As the file somehow didn't exist, I recreated it.

So, give "y" to continue (without quotes) and you'll see below screen for maintenance of icmauth authentication file

If I do l - list users of set here, it doesn't show anything. Normally it shows webadm user here.

Go ahead with re-creating the user.

For this, select a - add user to set option.

GIve username as webadm, Your new password, Confirm your new password, Group name as admin and as my SAPSSLC.PSE was signed, I gave the Subject Name associated with it.

After this, Press Enter to continue and execute s - save changes of set to file

After saving,

Stop sapstartsrv process, start sapstartsrv process and start Webdispatcher instance.

This creates the required entry in icmauth.txt file and after this you'd be able to successfully login to Webdispatcher Administration Interface!

Please let me know your thoughts in the comment section below.

For such more technical articles, please follow the tag Basis Technology (https://answers.sap.com/tags/7bf2eaed-4604-44ae-bad7-d2d2d5c58c54), and read other posts on the topic (https://blogs.sap.com/tags/7bf2eaed-4604-44ae-bad7-d2d2d5c58c54/)

Please follow my profile for similar content that I'll publish in the near future.

Regards,

Manoj Somkuwar

Download ZIP Package through NetWeaver Gateway with Odata

2022-12-15T09:54:16+01:00

Introduction

In this blog, I would like to show you how to download a ZIP package stored on an application server via Odata call in very simple steps.

I have tried not to add any additional logic apart from downloading the ZIP package from the Odata service.

Steps

1. Table creation.

2. Create an oData service.

3. Redefine methods of DPC extension class GET_ENTITYSET, /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_STREAM.

4. Redefine methods of MPC extension class DEFINE.

5. Register the oData service.

6. Test

Implementation

Let's begin the development step by step.

Step 1

1. Create a table where we will have the package name stored.

Table

Step 2

2.1. Create an Odata service.

Odata service

2.2. Create an entity with an entity set.

Entity

2.3. Add table name to ABAP structure and also mark Media checkbox as true. Do remember to mark the Media as true.

Add Structure

2.4. Import Properties/fields from the custom table.

Import Properties

2.5. Now it's time to generate the service.

Generate Service

Step 3

3.1. Go to the DPC extension class, redefine the GET_ENTITYSET method and add logic to get data from the custom table. This is required so that we can fetch data from the table to get the package name.

DPC_EXT Fetch Data

3.2. In the DPC extension, redefine method /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_STREAM and add the logic to get filename, convert it to xstring and pass it back to Odata.

 METHOD /iwbep/if_mgw_appl_srv_runtime~get_stream.



   TYPES:

     "! <p class="shorttext synchronized" lang="en">Media Type Information</p>

     BEGIN OF ty_s_media_resource.

       INCLUDE TYPE /iwbep/if_mgw_core_srv_runtime=>ty_s_media_resource.

   TYPES:END OF ty_s_media_resource .



   TYPES: BEGIN OF ty_package,

            docnr    TYPE zzdocnr,

            filename TYPE zzfilename,

          END OF ty_package.



   DATA:ls_key_tab TYPE /iwbep/s_mgw_name_value_pair,

        ls_package TYPE ty_package,

        ls_stream  TYPE ty_s_media_resource,

        lv_docnr   TYPE zzdocnr,

        lo_meco    TYPE REF TO /iwbep/if_message_container,

        ls_lheader TYPE ihttpnvp,

        lv_xstring TYPE xstring.



   READ TABLE it_key_tab INTO ls_key_tab INDEX 1.

   IF sy-subrc EQ 0.

     lv_docnr = ls_key_tab-value.

   ENDIF.



   SELECT SINGLE docnr,

               filename

     FROM zzip_package INTO @ls_package

     WHERE docnr = @lv_docnr.





   DATA(lv_path) = '.\SamplePackage.zip'.

   OPEN DATASET lv_path FOR INPUT IN BINARY MODE.    "#EC CI_USE_WANTED

   IF sy-subrc = 0.

     READ DATASET lv_path INTO lv_xstring.           "#EC CI_USE_WANTED

   ENDIF.



   CLOSE DATASET lv_path.                            "#EC CI_USE_WANTED



   IF sy-subrc = 0.

     ls_stream-mime_type = 'application/x-zip-compressed'. "mime type

     ls_stream-value     = lv_xstring.             "content

     ls_lheader-name     = 'Content-Disposition'(001).



     CONCATENATE 'attachment; filename="'(002)

                 ls_package-filename

                 '";'

            INTO ls_lheader-value.



     set_header( is_header = ls_lheader ).



     ls_lheader-name  = 'Content-Length'(003).



     DATA(lv_len)     = xstrlen( ls_stream-value ).

     ls_lheader-value = lv_len.

     set_header( is_header = ls_lheader ).

     copy_data_to_ref( EXPORTING is_data = ls_stream

                       changing  cr_data = er_stream ).



   ELSE. "error when file not found



     lo_meco = mo_context->get_message_container( ).

     lo_meco->add_message_text_only(

     EXPORTING

     iv_msg_type               =  'E'

     iv_msg_text               =  'File Not Found'(004)  " Message Text

     iv_add_to_response_header = abap_true " Flag for adding or not the message to the response header

     ).



   ENDIF.



 ENDMETHOD.

Step 4

4.1. Now redefine the method DEFINE of MPC extension class. Add your Entity name and field which contains the zip package.

METHOD define.

  super->define( ).



  DATA: lo_entity   TYPE REF TO /iwbep/if_mgw_odata_entity_typ,

        lo_property TYPE REF TO /iwbep/if_mgw_odata_property.



  lo_entity = model->get_entity_type( iv_entity_name = 'Package' ).



  IF lo_entity IS BOUND.

    lo_property = lo_entity->get_property( iv_property_name = 'Filename').

    lo_property->set_as_content_type( ).

  ENDIF.



ENDMETHOD.

Step 5

5.1. Now it's time to register the Odata service from /IWFND/MAINT_SERVICE tcode.

5.2. Once, the service is registered let's see if the metadata is loaded properly.

Metadata

Step 6

6.1. Lets us now upload the zip file to the application server.

Upload Package

6.2. Contents of the package. There are 52 notepad files in it.

Package contents

6.3. Let us execute the Odata service to get the ZIP Package. Select the HTTP method as GET and pass the below URI.

/sap/opu/odata/sap/ZZIPPACKAGE_DOWNLOAD_SRV/PackageSet('0001')/$value

6.4. Below is the HTTP response.

Response

6.5. Here comes the final step, click on the "Response in Browser" and let us see the uploaded ZIP package.

Downloaded ZIP Package

Hurray! the same ZIP package is downloaded.

Conclusion

In this way, we can download the ZIP package from the Odata service. UI developers can use the same service and trigger to download the package from the frontend button. Thank you for reading the blog post on ZIP Package download. I hope that you found the information useful and that it has provided you with some valuable insights.

If you have any thoughts or questions on the topic, please feel free to leave a comment below. I would love to hear from you.

If you found this post helpful, please like and share it with your network 🙂

Kind Regards,

Nitin Sharma

Generate Dynamic QR code from oDATA

2023-01-09T20:05:10+01:00

Introduction

QR (Quick Response) codes are two-dimensional barcodes that are widely used for storing and sharing information. They are particularly useful because they can be read quickly and easily by a smartphone or other device equipped with a camera and a QR code reader app.

If we can add a QR code to our app/oData call, it can open a wide area of fields for implementation.

Step-by-Step Procedure:

1. Create a page format as of QR size: If we do not create a page format then the QR will be shown in the whole A4 size page and a lot of space will be left empty. Use tcode SPAD for creating.

2. Create a Barcode: We will use SE73 to create a barcode.

3. Create a smartstyle: To create a character format for QR.

4. Create a smartform: To display the

5. Create a class: To convert text to xstring. This xstring will be passed to the oData call.

6. Table Creation: Create a table to store the data to be displayed in form of a QR code via oData.

7. Create oData Service: Finally, we will be creating an oData service.

8. Publish and test the Odata service.

Let's start the development now in the steps mentioned above.

STEP 1: Create a page format: Go to tcode SPAD.

1.1 Click on the full administrator and go to the tab Device Types and click on display.

Image 1- SPAD landing screen

Image 2- SPAD Page Format

1.2 Click on the pencil button to come to change mode and then click Create to create a new page format.

Image 3- Create Page Format

1.3 Save the page format with the below settings. One thing to notice is that depending on the data, the QR code can increase its size a bit as it has to hold more data in it. Play and change these settings as required.

Image 4- Save Page Format

1.4 Our first step completes here.

STEP 2: Create a barcode.

2.1 Go to tcode SE73 and create a new Barcode.

Image 5 - SE73

2.2 Create a new barcode.

Image 6 - New Barcode

2.3 Use the below setting to create the barcode.

Image 7 - New Barcode Setting

Image 8 - New Barcode Setting

Image 9 - New Barcode Setting

Image 10 - New Barcode Setting

2.4 QR Code is created. Now it's time to test the QR code. Place your cursor on the new barcode, in our case it is ZQRDISP, and hit F6 (execute barcode). I guess we all are excited to see the QR code in this development for the first time.

Image 11 - Test Barcode From SE73

2.5 Execute the report with any text.

Image 12 - Execute Report

2.6 Tada! Our QR code is ready.

Image 13 - QR Code from SE73

STEP 3 : Create Smartstyle

Let's create a smartstyle on the top of created barcode.

3.1 Create a smartstyle with character format as the created barcode. Also, create a default paragraph to add to the header data.

Image 14 - Smartsyles

STEP 4: Create Smartform

Let's move on to create a smartform.

4.1 This smartform will have an input parameter of type string and we will pass this parameter to the text element so that it can be displayed as a QR code. Add recently created smartsytle via the output options tab of the text element.

Image 15 - Smartform

4.2 Save and activate it.

4.3 It's time to execute the smartform, let's see what the output looks like. Pass any text to input field. Voila, we got a QR code!🕺🕺🕺

Image 16 - Smartform Output

4.4 Do scan the QR code and it will take you to like to read another oData blog.

STEP 5: Create Class

5.1 Create a class that will take a string as an input. It will take that string and pass it to smartform, generate the QR from it, and then finally the QR will be converted to pdf xstring. As oData can not process images directly, we are converting it to xstring.

Image 17 - Class

5.2 Below is the snippet of the code. We are performing the below activities in the code:

Get Device type.

Set relevant output options of the smartform.

Call smartform.

Convert the smartform output to OTF format.

Pass back the OTF xstring as a returning parameter.

  METHOD display.



    DATA :

      lv_fm_name            TYPE rs38l_fnam,

      ls_output_options     TYPE ssfcompop,

      lv_language           TYPE tdspras,

      ls_control_parameters TYPE ssfctrlop,

      ls_output_data        TYPE ssfcrescl,

      lv_pdf_len            TYPE i,

      lv_pdf_xstring        TYPE xstring,

      lt_lines              TYPE TABLE OF tline,

      lv_devtype            TYPE rspoptype,

      lt_tstotf             TYPE tsfotf.



* language

    lv_language = sy-langu.

    TRANSLATE lv_language TO UPPER CASE.

    ls_control_parameters-langu = lv_language.



* set control parameters to get the output text format (OTF) from Smart Forms

    ls_control_parameters-no_dialog = 'X'.

    ls_control_parameters-getotf    = 'X'.

    ls_control_parameters-preview   = space. "No preview



* get device type from language

    CALL FUNCTION 'SSF_GET_DEVICE_TYPE'

      EXPORTING

        i_language             = lv_language

*       i_application          = 'SAPDEFAULT'

      IMPORTING

        e_devtype              = lv_devtype

      EXCEPTIONS

        no_language            = 1

        language_not_installed = 2

        no_devtype_found       = 3

        system_error           = 4

        OTHERS                 = 5.



* set device type in output options

    ls_output_options-tdprinter = lv_devtype.



* Set relevant output options

    ls_output_options-tdnewid  = 'X'.   "Print parameters,

    ls_output_options-tddelete = space. "Print parameters



    CALL FUNCTION 'SSF_FUNCTION_MODULE_NAME'

      EXPORTING

        formname           = 'ZQRDISPLAY'  "Smartform name

      IMPORTING

        fm_name            = lv_fm_name

      EXCEPTIONS

        no_form            = 1

        no_function_module = 2

        OTHERS             = 3.



* Call Smartform generated FM

    CALL FUNCTION lv_fm_name

      EXPORTING

        control_parameters = ls_control_parameters

        output_options     = ls_output_options

        user_settings      = space

        gv_text            = iv_barcode_data

      IMPORTING

        job_output_info    = ls_output_data

      EXCEPTIONS

        formatting_error   = 1

        internal_error     = 2

        send_error         = 3

        user_canceled      = 4

        OTHERS             = 5.



    APPEND LINES OF ls_output_data-otfdata[] TO lt_tstotf[].



* Convert to OTF

    CALL FUNCTION 'CONVERT_OTF'

      EXPORTING

        format                = 'PDF'

      IMPORTING

        bin_filesize          = lv_pdf_len

        bin_file              = lv_pdf_xstring       " binary file

      TABLES

        otf                   = lt_tstotf

        lines                 = lt_lines

      EXCEPTIONS

        err_max_linewidth     = 1

        err_format            = 2

        err_conv_not_possible = 3

        err_bad_otf           = 4

        OTHERS                = 5.



    IF sy-subrc = 0.

      rv_image_data = lv_pdf_xstring.

    ENDIF.



  ENDMETHOD.

STEP 6: Create a Table

6.1 This table will store the data information and also will be used while creating the oData service.

Image 18 - Table

STEP 7: Create an oData service

7.1 Finally we reached the step where we will be creating the oData service. If it's your first oData service then I would recommend visiting A Step by Step process to create Odata services.

7.2 Once the oData service is created, import the table created.

Image 19 - oData Service

7.3 Do remember to check the checkbox "Media".

Image 20 - oData Media Check

7.4 Now we are all set to generate the oData service. Once oData is generated, goto DPC extension class and redefine method /IWBEP/IF_MGW_APPL_SRV_RUNTIME~GET_STREAM.

  METHOD /iwbep/if_mgw_appl_srv_runtime~get_stream.



    DATA:

      lt_keys     TYPE /iwbep/t_mgw_tech_pairs,

      ls_key      TYPE /iwbep/s_mgw_tech_pair,

      lv_customer TYPE s_customer,

      lv_xstring  TYPE xstring,

      ls_stream   TYPE ty_s_media_resource.



    lt_keys = io_tech_request_context->get_keys( ).



* docno is the specified key

    READ TABLE lt_keys WITH KEY name = 'DOCNO' INTO ls_key.

    IF sy-subrc IS INITIAL.



* We will convert field LINK as QR code

      SELECT SINGLE link FROM zstoreqrdetails INTO @DATA(lv_link)

      WHERE docno = @ls_key-value.



* Method display of Class zcl_qrcode will convert the data to QR to xstring

      lv_xstring = zcl_qrcode=>display( iv_barcode_data = lv_link ).



      ls_stream-value = lv_xstring.



      ls_stream-mime_type = 'application/pdf'.



* Pass the QR's xstrinh back to oData

      copy_data_to_ref( EXPORTING is_data = ls_stream

                        CHANGING  cr_data = er_stream ).



    ENDIF.



  ENDMETHOD.

7.5 In this step we will goto MPC extension class and redefine method DEFINE.

  METHOD define.



    DATA:

      lo_entity   TYPE REF TO /iwbep/if_mgw_odata_entity_typ,

      lo_property TYPE REF TO /iwbep/if_mgw_odata_property.



    super->define( ).



* QR_Detail is the entity name

    lo_entity = model->get_entity_type( iv_entity_name = 'QR_Detail' ).



    IF lo_entity IS BOUND.

* Field Link will be converted to media

      lo_property = lo_entity->get_property( iv_property_name = 'Link' ).

      lo_property->set_as_content_type( ).

    ENDIF.



  ENDMETHOD.

7.6 That's it. We are done with the development. In the next step, we will test it.

STEP 8: Testing

8.1 Register your oData service.

8.2 Once registered, let's see if metadata is loaded.

Image 21 - Metadata

8.3 Guys, please open your QR scanners as we are now going to get them. Execute the below URL and we will get the QR code as output.

/sap/opu/odata/sap/ZSHOW_QRINFO_SRV/QR_DetailSet('0001')/$value

Image 22 - Test1

8.4 Let's execute another case.

/sap/opu/odata/sap/ZSHOW_QRINFO_SRV/QR_DetailSet('0002')/$value

Image 23 - Test2

Conclusion

As we come to the end of this post, I hope you have a better understanding of how to display QR codes via oData call.

I hope that you found the information useful and that it has provided you with some valuable insights. If you have any thoughts or questions on the topic, please feel free to leave a comment below. I would love to hear from you.

If you found this post helpful, please share it with your network 🙂

Thanks,

Nitin Sharma

Implementing All OData Query/URI Options - Part 2

2023-03-26T13:54:17+02:00

Introduction

In the previous blog, we have discussed about the URI calls which do not require any custom implementation. In this blog, we will go through the URI's which do require custom implementation.

Steps

We can divide OData URI to 2 parts:

Do Not Need Custom Implementation (Implementing All OData Query/URI Options – Part 1)
1. $select
2. $count
3. $expand
4. $format
5. $links
6. $value

Need Custom Implementation (This Blog)
1. $orderby
2. $top
3. $skip
4. $filter
5. $inlinecount
6. $skiptoken

Implementation

1. $orderby: The $orderby option is used to specify a sort order for the results of a query. It is used in the URL of an OData service to indicate how the results should be sorted.

The syntax for the $orderby option is as follows: $orderby=propertyName [asc|desc], where propertyName is the name of the property by which the results should be sorted, and "asc" or "desc" is used to specify the sort order (ascending or descending, respectively).

For example, if we want to retrieve a list of customers and sort them by last name in descending order, the URL would look like this:

http://<host>/sap/opu/odata/sap/<service>/Customers?$orderby=LastName desc

It is also possible to sort by multiple properties using the $orderby option, by separating each property with a comma.

http://<host>/sap/opu/odata/sap/<service>/Customers?$orderby=LastName desc, FirstName asc

The code the $orderby can be written as:

  METHOD ekkoset_get_entityset.



*- To get data from DB

    SELECT * FROM ekko INTO TABLE @DATA(lt_ekko) UP TO 10 ROWS.



*- Check the $orderby in the Odata Query

    READ TABLE it_order INTO DATA(ls_order) INDEX 1.

    IF sy-subrc IS INITIAL.

      IF ls_order-order = 'desc'.

        SORT lt_ekko BY (ls_order-property) DESCENDING.

      ELSE.

        SORT lt_ekko BY (ls_order-property) ASCENDING.

      ENDIF.

    ENDIF.



*- Check the size of the table for $inlinecount

    IF io_tech_request_context->has_inlinecount( ) = abap_true.

      DESCRIBE TABLE lt_ekko LINES DATA(lv_size).

      es_response_context-inlinecount = lv_size.

    ENDIF.



    MOVE-CORRESPONDING lt_ekko TO et_entityset.



  ENDMETHOD.

Below is the output:

1. $orderby.jpg

Another better way to use the $orderby can be the standard way of using it, displayed below:

*- Check the $orderby in the Odata Query

    /iwbep/cl_mgw_data_util=>orderby(

      EXPORTING

        it_order =  it_order                " the sorting order

      CHANGING

        ct_data  = lt_ekko

    ).

2. $top: The $top option is used to specify the maximum number of results that should be returned in a query. It is used in the URL of an OData service to indicate how many results should be returned. The syntax for the $top option is as follows: $top=n, where n is an integer indicating the number of results that should be returned.

For example, if we want to retrieve the top 10 customers, the URL would look like this:

http://<host>/sap/opu/odata/sap/<service>/Customers?$top=10

The $top option can be used in combination with other options such as $filter, $select and $orderby to further refine the results of a query.

http://<host>/sap/opu/odata/sap/<service>/Customers?$filter=Country eq 'US'&$top=5&$orderby=LastName desc

It's important to note that the $top option is used to limit the number of records returned in one response and not to restrict the total number of records returned by the OData service.

  METHOD ekkoset_get_entityset.



*- To get data from DB

    SELECT * FROM ekko INTO TABLE @DATA(lt_ekko) UP TO 10 ROWS.



*- Check the $orderby in the Odata Query

    /iwbep/cl_mgw_data_util=>orderby(

      EXPORTING

        it_order =  it_order                " the sorting order

      CHANGING

        ct_data  = lt_ekko

    ).



*- For paging i.e. $top and $skip

    /iwbep/cl_mgw_data_util=>paging(

      EXPORTING

        is_paging = is_paging                " paging structure

      CHANGING

        ct_data   = lt_ekko

    ).



*- Check the size of the table for $inlinecount

    IF io_tech_request_context->has_inlinecount( ) = abap_true.

      DESCRIBE TABLE lt_ekko LINES DATA(lv_size).

      es_response_context-inlinecount = lv_size.

    ENDIF.



    MOVE-CORRESPONDING lt_ekko TO et_entityset.



  ENDMETHOD.

We can use it as below:

2. $top.jpg

3. $skip: The $skip option is used to specify the number of results that should be skipped before returning the results in a query. It is used in the URL of an OData service to indicate how many results should be skipped. The syntax for the $skip option is as follows: $skip=n, where n is an integer indicating the number of results that should be skipped.

For example, if we want to retrieve all customers but skip the first 10, the URL would look like this:

http://<host>/sap/opu/odata/sap/<service>/Customers?$skip=10

The $skip option can be used in combination with other options such as $top, $filter, $select, and $orderby to further refine the results of a query.

http://<host>/sap/opu/odata/sap/<service>/Customers?$filter=Country eq 'US'&$skip=5&$top=5&$orderby=LastName desc

It's important to note that the $skip option is used to skip the records from the beginning of the result set, so it is typically used in combination with the $top option to retrieve a specific page of results.

Same code of paging(used in 3. $top). The below snippet is showing the second 2nd record as it is fetching the 1st record after skipping 1st one.

3. $skip.jpg

4. $filter: The $filter option is used to specify filter criteria for the results of a query. It is used in the URL of an OData service to indicate which results should be returned based on certain conditions. The syntax for the $filter option is as follows: $filter=condition, where the condition is a logical expression that evaluates to true or false.

The condition can be built using comparison and logical operators (eq, ne, gt, ge, lt, le, and, or, not).

For example, if we want to retrieve all customers whose last name starts with "S", the URL would look like this:

http://<host>/sap/opu/odata/sap/<service>/Customers?$filter=startswith(LastName,'S')

If we want to retrieve all customers whose last name starts with "S" and whose first name is "John", the URL would look like this:

http://<host>/sap/opu/odata/sap/<service>/Customers?$filter=startswith(LastName,'S') and FirstName eq 'John'

The $filter option can be used in combination with other options such as $top, $skip, $select, and $orderby to further refine the results of a query.

  METHOD ekkoset_get_entityset.



*- To get data from DB

*- it_filter_select_options will have filter values for $filter keyword

    IF it_filter_select_options IS INITIAL.

      SELECT * FROM ekko INTO TABLE @DATA(lt_ekko) UP TO 10 ROWS.

    ELSE.

      READ TABLE it_filter_select_options INTO DATA(ls_sopt)

                                           WITH KEY property = 'Ebeln'.

      IF sy-subrc IS INITIAL.

        SELECT * FROM ekko INTO TABLE @lt_ekko WHERE ebeln IN @ls_sopt-select_options.

      ENDIF.

    ENDIF.



*- Check the $orderby in the Odata Query

  /iwbep/cl_mgw_data_util=>orderby(

    EXPORTING

      it_order =  it_order                " the sorting order

    CHANGING

      ct_data  = lt_ekko

  ).



*- For paging i.e. $top and $skip

  /iwbep/cl_mgw_data_util=>paging(

    EXPORTING

      is_paging = is_paging                " paging structure

    CHANGING

      ct_data   = lt_ekko

  ).



*- Check the size of the table for $inlinecount

  IF io_tech_request_context->has_inlinecount( ) = abap_true.

    DESCRIBE TABLE lt_ekko LINES DATA(lv_size).

    es_response_context-inlinecount = lv_size.

  ENDIF.



  MOVE-CORRESPONDING lt_ekko TO et_entityset.



ENDMETHOD.

We can test the above code as:

4. $filter.jpg

5. $inlinecount: It is used to include the total count of all the matching results in the response. It is used in the URL of an OData service to indicate that the total count of the matching results should be included in the response. The syntax for the $inlinecount option is as follows: $inlinecount=allpages, where "allpages" is a keyword indicating that the total count should be included.

For example, if we want to retrieve all customers and include the total count of customers in the response, the URL would look like this:

http://<host>/sap/opu/odata/sap/<service>/Customers?$inlinecount=allpages

The $inlinecount option can be used in combination with other options such as $filter, $top, $skip, $select and $orderby to further refine the results of a query.

http://<host>/sap/opu/odata/sap/<service>/Customers?$filter=Country eq 'US'&$top=5&$skip=5&$orderby=LastName desc&$inlinecount=allpages

It's important to note that the $inlinecount option will include the count of the matching results in the response, the count will be included in the ".count" attribute of the response.

5. $filter.jpg

6. $skiptoken: The $skiptoken option is used with the $top option to retrieve a specific page of results by providing a token that represents the position in the result set from where the next set of results should be retrieved. When a partial response is returned by the server, the $skiptoken value is included in the __next link of the response, allowing clients to easily retrieve the next set of results without having to construct or interpret the $skiptoken value themselves.

The syntax for the $skiptoken option is as follows: $skiptoken=token, where the token is a string value representing the position in the result set from where the next set of results should be retrieved.

For example, if we want to retrieve the next set of 10 customers starting from the 11th customer, the URL would look like this:

http://<host>/sap/opu/odata/sap/<service>/Customers?$top=10&$skiptoken='11'

The $skiptoken option can be used in combination with other options such as $filter, $top, $select and $orderby to further refine the results of a query.

http://<host>/sap/opu/odata/sap/<service>/Customers?$filter=Country eq 'US'&$top=5&$skiptoken='11'&$orderby=LastName desc

It's important to note that the $skiptoken option is used to navigate through the result set in a pagination manner, and it should be used in conjunction with $top option and the result set should be sorted in the same order as in the query that generated the skiptoken.

6. $skiptoken.jpg

The $skip and $skiptoken looks same in first look but they are some difference. To know further about $skip and $skiptoken you can visit this blog: Difference between $skip and $skiptoken in Odata

Conclusion

SAP has provided us multiple options to play with for real-time requirements with a little effort. I would recommend you to try these query options and debug to see how it works. The blog was divided into the following parts.

$orderby: sorts data by one or more fields.

$top and $skip: enable server-side paging.

$filter: retrieves specific data from an entity set based on a set of criteria.

$inlinecount: provides the total number of records in an entity set.

$skiptoken: enables server-side paging using a continuation token.

Edit 1: Thanks @gregorw for helping to enrich the blog.

In the world of Odata services, there are two types of services -

Those created from SEGW

Those based on CDS views

When creating Odata services from SEGW, custom implementation is required for the $orderby, $top, $skip, $filter, and $inlinecount query options. However, this is not the case when the Odata service is based on a CDS view. In this scenario, SAP provides these query options without the need for implementation, making the development process simpler and more efficient.

It’s important to note that this difference exists because of the fundamental architectural differences between SEGW and CDS views. SEGW generates ABAP code based on metadata, whereas CDS views are defined in the ABAP repository and translated into Open SQL. By leveraging the capabilities of CDS views, developers can benefit from SAP’s pre-built query options and focus on delivering value to their customers.

If you have any thoughts or questions on the topic, please feel free to leave a comment below. I would love to hear from you.

If you found this post helpful, please like and share it with your network 🙂

Kind Regards,

Nitin Sharma

Difference between $skip and $skiptoken in Odata

2023-03-26T13:57:47+02:00

Introduction

When working with large datasets in SAP OData, server-side paging can be a useful technique for improving performance and reducing the amount of data that needs to be transmitted over the network. Two commonly used parameters for server-side paging are $skip and $skiptoken. While they may seem similar, they serve different purposes and have different use cases.

In this technical blog, we will explore the difference between $skip and $skiptoken in SAP OData and provide examples of how they can be used in different scenarios. We will also discuss best practices for using these parameters and provide tips for optimizing performance when working with large datasets.

What is $skip : Please refer to this blog for more details about $skip - Implementing All OData Query/URI Options – Part 2

What is $skiptoken: Please refer to this blog for more details about $skiptoken Implementing All OData Query/URI Options – Part 2

Difference between `$skip` and `$skiptoken`:

$skip is used to skip a specified number of items in a collection of data before returning the remaining results. For example, if we want to retrieve all employees after skipping the first 10 employees, we would use the following query:

/sap/opu/odata/sap/<service_name>/Employees?$skip=10

This query would skip the first 10 employees and return the remaining employees in the "Employees" entity set.

On the other hand, $skiptoken is used to enable efficient server-side paging of query results when the size of the data set is too large to be retrieved in a single request. When a server returns a limited number of results along with a $skiptoken value, the client can use this token in a subsequent request to retrieve the next set of results. The $skiptoken value serves as an identifier of the last result returned by the server and helps the server to skip to the next set of results efficiently.

For example, suppose we want to retrieve the first 100 orders from an "Orders" entity set that contains 500 orders. We can use the following query:

/sap/opu/odata/sap/<service_name>/Orders?$top=100

This query would retrieve the first 100 orders. However, if we want to retrieve the next 100 orders, we would need to use $skiptoken. When the server returns the first 100 orders, it would also return a $skiptoken value that identifies the last order returned. We can then use this $skiptoken value in a subsequent request to retrieve the next 100 orders:

/sap/opu/odata/sap/<service_name>/Orders?$top=100&$skiptoken=<skiptoken_value>

In this query, <skiptoken_value> is the $skiptoken value returned by the server in the previous response. The server would skip the first 100 orders and return the next 100 orders after the order is identified by the $skiptoken value.

Few interesting examples that we could use in an SAP OData technical blog about server-side paging using $skip and $skiptoken:

Retrieving large amounts of data efficiently: Imagine we have an entity set containing a large number of records, such as a sales order entity set that contains thousands of orders. Instead of retrieving all the orders in a single request, we can use $skip and $skiptoken to retrieve them in smaller, more manageable batches. This can significantly improve performance and reduce the load on the server.

Implementing infinite scrolling: With server-side paging, we can implement infinite scrolling, where data is loaded dynamically as the user scrolls down a page. This can provide a better user experience and prevent the need to load all the data at once, which can be slow and resource-intensive.

Combining $skip and $filter to retrieve specific data: We can combine $skip and $filter to retrieve specific data from an entity set. For example, if we have an employee entity set and we want to retrieve all the employees in the sales department after skipping the first 10 employees, we can use the following query:
```
/sap/opu/odata/sap/<service_name>/Employees?$skip=10&$filter=Department eq 'Sales'
```

Using $skiptoken with SAP Gateway: SAP Gateway provides built-in support for $skiptoken, allowing us to easily implement server-side paging in our OData services. We can use the go_paging method in our Gateway class to handle $skiptoken values and efficiently retrieve large amounts of data.

Conclusion:

In conclusion, understanding the difference between $skip and $skiptoken in SAP OData is crucial when working with large datasets. By using these parameters effectively, developers can improve the performance and scalability of their OData services and provide a better user experience for their customers. By following best practices and optimizing their queries, developers can ensure that their OData services are performing at their best and delivering value to their users.

If you found this post helpful, please like and share it with your network 🙂

Kind Regards,

Nitin Sharma

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.

@abapName	for mapping GraphQL name to SAP name
@abapValue	for mapping GraphQL Enum value to SAP Domain value
@resolver	to support legacy RESOLVER by ID functionality

@functionModule	to execute the ABAP function module using GraphQL data
@class	to execute ABAP Class and Method using GraphQL data

SAP Community - NW ABAP Web Services

How to send data from ECC to PI using a Consumer Proxy (Web Service)

Developing GraphQL API on ABAP: GraphQLAdmin Web Interface

Building Sample Demo GraphQL API using SFLIGHT BAPIs

Advantages & Conclusions:

Improve the performance of an SAP FIORI application by implementing "Delta Token" mode in SAP Netweaver Gateway Odata

SAP Gateway & Delta Token

How "Delta" Mode Works

Delta Mode Implementation

Creating a list-generating RFC module

The ZRFC_READ_ALL function

The structure of the function tables

The function algorithm

Creation of an Odata project

The structure of the "ZGCG11_DEMO" project

Implementation of the "Query" method

Redefining the "Query" method via ABAP

Redefining the "Query Delta" method via ABAP

Data persistence

Remediation of uncalled active ICF services

Web applications and web services to rule them all

Updates: 2022-11-07: Added hint for new secure-by-default logs.

“Please activate one or the other ICF service - it is urgent!”

Bring some light into the darkness

What about service usage?

Put the puzzle together

Time to cleanup

Whats next?

500 Internal Server Error. This browser is not supported - Error in Enterprise Portal in IE 11

Introducing the SRT_MONI Generic Search Framework (GSF) - a new way of filtering SOAP Web Service Messages by content

Update:

Extension and enhancement of the SRT_MONI Generic Search Framework (GSF)

How to send multiple ERP systems master data (ECC) to ARIBA On-Demand

SAP Netweaver GoogleAuthenticator/FreeOTP for Fiori Launchpad using Keycloak (on Premise)

Extension and enhancement of SXI_MONITOR Generic Search Framework

Introducing the SXI_MONITOR Generic Search Framework

Using WebServices to transfer data to SAP BW- SOA Manager and SOAP Configurations

Integrate SAP TM-ECC by Enhancing Standard Webservice Without PI

ABAP REST API http Service call from Postman: JSON to ABAP data

SAP Webdispatcher webadm user got deleted!!

Download ZIP Package through NetWeaver Gateway with Odata

Introduction

Steps

Implementation

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Conclusion

Generate Dynamic QR code from oDATA

Introduction

Step-by-Step Procedure:

STEP 1: Create a page format: Go to tcode SPAD.

STEP 2: Create a barcode.

STEP 3 : Create Smartstyle

STEP 4: Create Smartform

STEP 5: Create Class

STEP 6: Create a Table

STEP 7: Create an oData service

STEP 8: Testing

Conclusion

Implementing All OData Query/URI Options - Part 2

Introduction

Steps

Implementation

Conclusion

Difference between $skip and $skiptoken in Odata

Introduction

Difference between $skip and $skiptoken:

Conclusion:

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

1. Introduction:

2. Contents:

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

Updates:
2022-11-07: Added hint for new secure-by-default logs.

Difference between `$skip` and `$skiptoken`:

3. SAP CorS Managed (External):　