0% found this document useful (0 votes)
93 views13 pages

Enhancing Purchase Order APIs in SAP

The document discusses wrapping SAP BAPIs and APIs to extend their functionality and expose only needed parameters. It provides steps to create an interface and wrapper class to call a BAPI, then a factory class and releasing the artifacts for consumption. The wrapper allows testing and calling the BAPI without unnecessary tier 1 coding.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
93 views13 pages

Enhancing Purchase Order APIs in SAP

The document discusses wrapping SAP BAPIs and APIs to extend their functionality and expose only needed parameters. It provides steps to create an interface and wrapper class to call a BAPI, then a factory class and releasing the artifacts for consumption. The wrapper allows testing and calling the BAPI without unnecessary tier 1 coding.
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd

API - S/4 HANA or On-premises

In 2016 SAP launched API Business Hub which is the central catalogue of SAP APIs for
application developers to search and discover standard and out of the box ways of
accessing/integrating SAP data with third-party systems or applications.

S/4HANA API is a concept somehow like BAPIs known from SAP ECC systems. The
difference here is that in the S/4HANA they are RESTful APIs and use the OData protocol,
whereas BAPIs were mainly called using RFC connection (if called from outside of SAP).
Also, under the hood, S/4HANA APIs are built using CDS views as opposed to regular
ABAP.

Having said that, you can leverage the APIs to quickly build reports without the need of
developing the backend and database logic. That is the case if the API you need is available
in the API Business Hub and provides all the data you need. Sometimes, you may find that
the API doesn’t provide all the information you need, but fear not, SAP got you covered and
allows you to extend the API and add additional fields.

System Prerequisites: S/4HANA System, Eclipse with ABAP Development Tools


There are 2 types of APIs.

 ODATA API
 SOAP API

[Link] Scenario - Extending Standard released API with new fields.

Where to find the SAP API?

The API Business Hub can be accessed using the following URL: [Link]
Searching for “Purchase Order” we have found a relevant API –
“API_PURCHASEORDER_PROCESS_SRV”. You can then check if this API is available in
our system version and activate it.
This API is also available in S/4HANA on premise version and SAP S/4HANA Cloud.

ODATA V2/V4 API-Are OData based API and can be added directly from Tcode -
/N/IWFND/MAINT_SERVICE if not available.

Search and activate the required service and execute to see the status.
How to identify the relevant object for enhancement?

As already mentioned, most of the APIs are created using CDS views, which are then
exposed using the OData protocol to the outside world. To add the extra field, you must
identify the APIs Gateway project and then the relevant CDS view name. It is the CDS view
that is enhanced directly and the API, which is created with reference to the CDS view will
inherit the enhancement.

1. Launch transaction SEGW

2. Click the ‘Open Project’ button and type API_PRUCHASEORDER_PROCESS

3. Expand the Gateway project and click on “CDS-Entity Exposures”. This will display on the
right-hand side all CDS views used in that API. We are interested in A_PurchaseOrder (PO
Header Level) and this is the CDS view we will be enhancing.
Extending the CDS view

We can now extend the CDS view using Eclipse. This is done by creating a new “Data
Definition” element and the “Extend View” template.

1. Launch Eclipse and connect to your system.

2. Click File -> New -> Other -> Data Definition

3. Enter Name and Description, click next and select transport.

4. Select ‘Extend View’ Template.


5. Add the additional "Building" or use association to get a new field.

6. Activate your extension

7. Launch the A_PurchaseOrder CDS view. Note that a new icon has appeared which
indicates that it has been enhanced, and shows the enhancement name:

Test your SAP APIs

Now it is time to validate that your new fields are visible and providing the correct data.

1. Check if the new fields have appeared in transaction SEGW for project:
API_PRUCHASEORDER_PROCESS, entity type: A_PURCHASEORDERTYPE, -node:
properties
2. Test your service in the browser or SAP Gateway Client in transaction
/IWFND/MAINT_SERVICE

Using request URI:


/sap/opu/odata/sap/API_PURCHASEORDER_PROCESS_SRV/A_PurchaseOrder

We can now see that the newly added fields are appearing:

Right now, in current system I have limited access and data is not maintained in Sandbox so
"No show of data". However new added field is visible in Entity set of OData.

2. Business Scenario - No convenient released API is available to create purchase


requisitions, so documentation recommends using a BAPI as an alternative. Creating wrapper
API for unreleased or released BAPI in system and release the wrapper API for consumption in
tier 1.

How to check if BAPI is released or not?

In Eclipse Editor, Under Properties check the API state.


Create a wrapper interface

You now want to wrap the API BAPI_PR_CREATE . Depending on your specific use-case, you

normally would need to access only certain specific functionalities and methods of the BAPI you want
to expose. An ABAP Interface is the perfect development object for this purpose: the interface
simplifies and restricts the usage of the underlying BAPI for the specific use-case, by exposing only
the parameters that are needed. Therefore, non-wrapped functionalities are forbidden.

To create the interface for your BAPI wrapper right click on the newly created package and
select New > ABAP Interface. Input the Name ZIF_WRAP_BAPI_PR_CREATE_XXX and a

Description.

Click on Next and then click on Finish.

Implement your ABAP Interface to expose only the parameters that are needed in your specific use-
case. Save and activate it. As already said, you will expose only the parameters that are needed in
your specific use-case. In this case you want to create a purchase requisition item (for which you
expose the parameter PR_ITEM ) and given the underlying BAPI signature, the PR_ITEM always
requires a header, which is why you are also exposing the parameter PR_HEADER.
Create a wrapper class

You now need to create a class to wrap the BAPI (implementing the interface you created in the
previous step) and implement its methods.

Right click on your package and select New > ABAP Class. Input the
Name ZCL_BAPI_PR_WRAPPER_XXX and a Description:
Click on Next and then click on Finish.

The implementation of the wrapper class depends on the specific use-case and BAPI signature. We
suggest implementing the wrapper class in the following way:

The wrapper class has a method defined in the private section, CALL_BAPI_PR_CREATE , which

has access to all the parameters of the underlying BAPI. Having this type of central private method is
best practice: internally, the wrapper class has access to all the parameters and then the interface has
virtual access to all of these parameters and exposes publicly only the ones that are needed
depending on the specific use-case. Save and activate it.

Since we plan to access the wrapped BAPI in a different tier, it is good to provide the possibility to test
it, and to keep wrapping-specific coding in tier 1 to a minimum. For this reason, the interface approach
is recommended, and the wrapper class will not be released directly for consumption in tier 1, but
rather will be accessible via a factory class that you will create in the next step.

Create a wrapper factory class

Our recommended approach is to create a factory class to control the instantiation of the wrapper
class. This factory class will then be released for consumption in tier 1. This approach has the
advantage of a clear control of when and where an instance of the wrapper class is created, and in
the event in which several wrapper classes are needed all their instantiations could be handled inside
one single factory class. Also, in case of wrapper classes this has the advantage that in case the
wrapper class is changed throughout its software lifecycle, at a later point in time a different class
could be initialized, without changes to the consumer implementation.

To create the factory class right click on your package and select New > ABAP Class. Input the
Name ZCL_BAPI_WRAP_FACTORY_XXX and a Description. Save and activate it.
Release the wrapper interface and factory class

Now you need to release the wrapper interface and wrapper factory class for consumption in tier 1. To
do this, you need to add a Release Contract (C1) to both objects for use system-internally and use in
Cloud Development.

In your Project Explorer open the ABAP Interface you created. In the Properties tab click on the API
State tab and then click on the green plus icon next to the Use System-Internally (Contract C1).

Make sure the Release State is set to Released and check the option Use in Cloud Development:

The API State tab will now show the new Release State:
In ADT, now you can create the class for the console application. Right click on the newly created
package and select New > ABAP Class and input the Name ZCL_BAPI_WRAP_TEST_XXX and a

Description:
You can test that the wrapper was correctly released for consumption in tier 1 by running the console
application class ZCL_BAPI_WRAP_TEST_XXX . First, the errors in the class should have

disappeared now that you released the wrapper, so you can save and activate the class. Now you can
run it: right click on the class and select Run As > ABAP Application (Console). The class should now
run without errors and the purchase requisition will be created and displayed in the console:

Common questions

Powered by AI

Using a factory class in BAPI wrapping offers significant advantages by providing controlled instantiation of wrapper classes, thus maintaining a clear architecture and limiting direct exposure of BAPIs . It allows for centralized management of multiple wrappers within a single factory class, streamlining system architecture and facilitating seamless updates or changes to wrapper classes without altering consumer implementations . This approach enhances maintainability and scalability, particularly in cloud development environments where flexibility and controlled access are critical .

Developers can extend a standard released API in SAP S/4HANA by enhancing the CDS view associated with it. The process involves using Eclipse with ABAP Development Tools to create a new 'Data Definition' element and selecting the 'Extend View' template . After identifying the relevant CDS view in transaction SEGW, developers add new fields through associations or direct extensions . The enhanced CDS view is then activated to reflect these changes in the API .

ABAP interfaces play a crucial role in creating wrapper APIs by defining a clear and restricted interaction point for underlying BAPIs . By wrapping only specific functionalities, the interface simplifies usage and enhances security, ensuring that only necessary methods and parameters are exposed for particular use cases . This focused exposure facilitates more targeted and efficient API consumption while maintaining encapsulation and integration clarity .

Key prerequisites for extending SAP APIs using CDS views include having an S/4HANA system and Eclipse with ABAP Development Tools set up . Developers ensure successful CDS view enhancements by correctly identifying and enhancing the relevant CDS view in transaction SEGW and following best practices for extending these views via Eclipse . Proper implementation and activation of enhancements ensure that new fields are correctly displayed and functional in database operations and the API layer .

Developers might face challenges if the API Business Hub does not provide all the necessary data, requiring the extension of existing APIs or development of new API solutions. This can be addressed by enhancing CDS views to include the needed fields and creating custom implementations . Developers can also create wrapper APIs for existing BAPIs if relevant APIs are not released . These solutions require a deep understanding of the existing SAP architecture and tools such as Eclipse with ABAP Development Tools for development and extension tasks .

A developer might create a wrapper API for an unreleased BAPI when a convenient released API is not available for a business function, such as creating purchase requisitions . The process involves creating an ABAP interface to wrap specific BAPI functionalities and a class to implement this interface. A wrapper factory class may also be created to manage instantiations efficiently and facilitate cloud development. This encapsulates the BAPI, simplifying its use and exposing only necessary functionalities for the specific application case .

Testing newly created or extended SAP APIs can be conducted using the SAP Gateway Client or directly in a browser by executing the service with relevant request URIs . Developers should ensure that new fields appear correctly in the API output by verifying the API specifications and conducting unit tests to validate data handling . In scenarios where data isn't maintained in a sandbox, synthetic data can be used to test the structural integrity of API extensions and confirm their integration with existing functionality .

S/4HANA APIs differentiate from traditional BAPIs in SAP ECC systems mainly in their use of RESTful APIs and the OData protocol, compared to BAPIs which were typically accessed via RFC connections from outside SAP . S/4HANA APIs are also built using CDS views as opposed to ABAP, simplifying backend development and database logic . This RESTful approach in S/4HANA APIs allows for more seamless integration with third-party systems .

The OData protocol in S/4HANA significantly enhances API integration and functionality by providing a standardized method for interacting with data through RESTful services . This protocol allows developers to perform CRUD operations in a simplified manner, promoting interoperability and ease of integration with external systems . By leveraging OData, APIs can expose SAP data as web services, facilitating seamless data exchange and reducing the complexity of backend development .

The API Business Hub serves as a central catalog for discovering and accessing SAP APIs, streamlining the development and integration processes . It enables developers to easily search for relevant APIs, such as the 'API_PURCHASEORDER_PROCESS_SRV', and check their availability in the system version . This platform facilitates the integration of SAP data with third-party systems without the need for intensive backend development, thus enhancing development efficiency .

You might also like