The existing workaround approaches present several drawbacks:

• Custom UI Extensions: Require specialized UI5 development expertise.
• Third-Party Solutions: Introduce risks related to licensing compliance and potential security vulnerabilities.
• Object Page Manipulations: Involve complex, multi-step processes, such as creating a dummy object page, facilitating file upload, temporarily storing the file data in a table field, and requiring a final user action (a button press) to initiate processing. This temporary data storage is often unnecessary, complicating the data model.

However, SAP has recently introduced ABAP / CAP annotations that offer a cloud-ready solution, potentially eliminating approximately 95% of the development effort typically associated with integrating an Excel upload into the backend. This innovation allows developers to prioritize implementing core business logic over developing reusable technical artifacts.

I will now detail the implementation steps.

A business requirement to manage mass processing listings for a library was selected to demonstrate this use case. The implementation requires several steps, with steps 3 through 6 being the special or additional configurations needed, while all others are considered routine.

Implementation Steps

1. A database table for the listing entity is created. This involves fields such as Id, Title, Type, and Author.

@EndUserText.label : 'Library Listings'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zrk_lib_listings {

  key client            : abap.clnt not null;
  key listing_uuid      : sysuuid_x16 not null;
  id                    : abap.numc(10);
  title                 : abap.char(40);
  type                  : abap.char(5);
  author                : abap.char(40);
  publisher_studio      : abap.char(40);
  isbn_ean              : abap.char(40);
  language_code         : abap.lang;
  publication_year      : abap.numc(4);
  description           : abap.char(40);
  totalcopies           : abap.int2;
  available_copies      : abap.int2;
  location_shelf_id     : abap.char(40);
  lending_duration_days : abap.int2;
  status                : abap.char(40);
  cover_image_url       : abap.char(100);
  local_created_by      : abp_creation_user;
  local_created_at      : abp_creation_tstmpl;
  local_last_changed_by : abp_locinst_lastchange_user;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
  last_changed_at       : abp_lastchange_tstmpl;

}

2. A RAP Business Object (BO) is generated, followed by the requisite UI artifacts. The specific RAP BO scenario (Managed, Unmanaged, Draft, or Non-Draft) is noted as not influencing the core Excel upload use case. The RAP Generator is used to simplify the demonstration.

3. A root abstract entity is created for the file to be uploaded. (This entity is highly reusable and can be applied across different RAP BOs).

@EndUserText.label: 'Abs. Entity For Attachment'
define root abstract entity ZRK_D_FILE_STREAM
{
  @Semantics.largeObject.mimeType: 'MimeType'
  @Semantics.largeObject.fileName: 'FileName'
  @Semantics.largeObject.contentDispositionPreference: #INLINE
  @EndUserText.label: 'Select Excel file'
  StreamProperty : abap.rawstring(0);
  
  .hidden: true
  MimeType : abap.char(128);
  
  .hidden: true
  FileName : abap.char(128);   
}

4. The abstract behavior definition for the file entity is implemented.

abstract;
strict(2);
with hierarchy;
define behavior for ZRK_D_FILE_STREAM {
}

5. A second abstract entity is created to serve as an action parameter. This entity includes an association to the file abstract entity (from Step 3).

@EndUserText.label: 'Action Param for Uploading Excel'
define root abstract entity ZRK_D_UPLOAD_EXCEL
{
// Dummy is a dummy field
@UI.hidden: true
dummy : abap_boolean;
     _StreamProperties : association [1] to ZRK_D_FILE_STREAM on 1 = 1;
    
}

6. The abstract behavior definition for the action parameter is implemented, including the association to the earlier entity.

abstract;
strict ( 2 );
with hierarchy;
define behavior for ZRK_D_UPLOAD_EXCEL //alias <alias_name>
{
association _StreamProperties with hierarchy;
}

7. An action is defined on the RAP BO Behavior definition, with the parameter specified in Step 5.

static action ExcelUpload deep parameter ZRK_D_UPLOAD_EXCEL ;

managed implementation in class ZRK_BP_R_LIB_LISTINGS unique;
strict ( 2 );
with draft;
extensible;
define behavior for ZRK_R_LIB_LISTINGS alias Listings
persistent table ZRK_LIB_LISTINGS
extensible
draft table ZRK_LIB_LSTNGS_D
etag master LocalLastChangedAt
lock master total etag LastChangedAt
authorization master( global )
{
  field ( readonly )
   ListingUUID,
   LocalCreatedBy,
   LocalCreatedAt,
   LocalLastChangedBy,
   LocalLastChangedAt,
   LastChangedAt;

  field ( numbering : managed )
   ListingUUID;


  create;
  update;
  delete;

  draft action Activate optimized;
  draft action Discard;
  draft action Edit;
  draft action Resume;
  draft determine action Prepare;

  static action ExcelUpload deep parameter ZRK_D_UPLOAD_EXCEL ;

  mapping for ZRK_LIB_LISTINGS corresponding extensible
  {
    ListingUUID = listing_uuid;
    ID = id;
    Title = title;
    Type = type;
    Author = author;
    PublisherStudio = publisher_studio;
    IsbnEan = isbn_ean;
    LanguageCode = language_code;
    PublicationYear = publication_year;
    Description = description;
    Totalcopies = totalcopies;
    AvailableCopies = available_copies;
    LocationShelfID = location_shelf_id;
    LendingDurationDays = lending_duration_days;
    Status = status;
    CoverImageUrl = cover_image_url;
    LocalCreatedBy = local_created_by;
    LocalCreatedAt = local_created_at;
    LocalLastChangedBy = local_last_changed_by;
    LocalLastChangedAt = local_last_changed_at;
    LastChangedAt = last_changed_at;
  }

}

8. The business logic is implemented to read the Excel content. A released API, XCO_CP_XLSX , is used for this demonstration.

METHOD ExcelUpload.
    TYPES : BEGIN OF ty_sheet_data,
              id                  TYPE zrk_r_lib_listings-id,
              title               TYPE zrk_r_lib_listings-title,
              type                TYPE zrk_r_lib_listings-Type,
              author              TYPE zrk_r_lib_listings-author,
              PublisherStudio     TYPE zrk_r_lib_listings-PublisherStudio,
              IsbnEan             TYPE zrk_r_lib_listings-IsbnEan,
              LanguageCode        TYPE zrk_r_lib_listings-LanguageCode,
              PublicationYear     TYPE zrk_r_lib_listings-PublicationYear,
              description         TYPE zrk_r_lib_listings-Description,
              Totalcopies         TYPE zrk_r_lib_listings-Totalcopies,
              AvailableCopies     TYPE zrk_r_lib_listings-AvailableCopies,
              LocationShelfID     TYPE zrk_r_lib_listings-LocationShelfID,
              LendingDurationDays TYPE zrk_r_lib_listings-LendingDurationDays,
              status              TYPE zrk_r_lib_listings-Status,
            END OF ty_sheet_data.

    DATA lv_file_content   TYPE xstring.
    DATA lt_sheet_data     TYPE STANDARD TABLE OF ty_sheet_data.
    DATA lt_listing_create TYPE TABLE FOR CREATE zrk_r_lib_listings.

    lv_file_content = VALUE #( keys[ 1 ]-%param-_streamproperties-StreamProperty OPTIONAL ).

    " Error handling in case file content is initial

    DATA(lo_document) = xco_cp_xlsx=>document->for_file_content( lv_file_content )->read_access( ).

    DATA(lo_worksheet) = lo_document->get_workbook( )->worksheet->at_position( 1 ).

    DATA(o_sel_pattern) = xco_cp_xlsx_selection=>pattern_builder->simple_from_to(
      )->from_column( xco_cp_xlsx=>coordinate->for_alphabetic_value( 'A' )  " Start reading from Column A
      )->to_column( xco_cp_xlsx=>coordinate->for_alphabetic_value( 'N' )   " End reading at Column N
      )->from_row( xco_cp_xlsx=>coordinate->for_numeric_value( 2 )    " *** Start reading from ROW 2 to skip the header ***
      )->get_pattern( ).

    lo_worksheet->select( o_sel_pattern
                                     )->row_stream(
                                     )->operation->write_to( REF #( lt_sheet_data )
                                     )->set_value_transformation(
                                         xco_cp_xlsx_read_access=>value_transformation->string_value
                                     )->execute( ).

    lt_listing_create = CORRESPONDING #( lt_sheet_data ).

    MODIFY ENTITIES OF zrk_r_lib_listings IN LOCAL MODE
           ENTITY Listings
           CREATE AUTO FILL CID FIELDS ( Id Title Type author PublisherStudio IsbnEan LanguageCode PublicationYear description Totalcopies AvailableCopies LocationShelfID LendingDurationDays status )
           WITH lt_listing_create
           " TODO: variable is assigned but never used (ABAP cleaner)
           MAPPED DATA(lt_mapped)
           " TODO: variable is assigned but never used (ABAP cleaner)
           REPORTED DATA(lt_reported)
           " TODO: variable is assigned but never used (ABAP cleaner)
           FAILED DATA(lt_failed).

    " Communicate the messages to UI - not in scope of this demo
    IF lt_failed IS INITIAL.
      APPEND VALUE #( %msg = new_message_with_text( severity = if_abap_behv_message=>severity-success
                                                    text     = 'Listings have been uploaded - please refresh the list!!' ) )
             TO reported-listings.
    ENDIF.
  ENDMETHOD.

9. The action is utilized on the projection behavior and subsequently exposed in the metadata extension.

use action ExcelUpload;

projection implementation in class ZRK_BP_C_LIB_LISTINGS unique;
strict ( 2 );
extensible;
use draft;
use side effects;
define behavior for ZRK_C_LIB_LISTINGS alias Listings
extensible
use etag
{
  use create;
  use update;
  use delete;

  use action Edit;
  use action Activate;
  use action Discard;
  use action Resume;
  use action Prepare;

  use action ExcelUpload;

}

.lineItem: [{ type:#FOR_ACTION , dataAction: 'ExcelUpload' , label: 'Upload Excel' }]

10. The service binding is published, and the application is then ready for execution.

Note:

This feature is currently functional on the BTP ABAP Environment. However, an issue appears to exist with metadata generation on S/4HANA 2023 On-Premise deployments, even though the objects are syntactically correct. It is anticipated that this constraint will be addressed in the S/4HANA 2025 release, making the full feature set available on the S/4HANA On-Premise version following a brief waiting period.

The post ABAP RAP: Excel upload through custom action popup (No UI5 Extension, No Object Page workaround) appeared first on ERP Q&A.

Challenge: background processing framework has been introduced by SAP from Cloud 2311 version. Without this framework, it is not possible to trigger an asynchronous task from a stateless UI.

Solution: To simulate similar functionality we can use existing ABAP artifacts like RFC and submitting program in background job.

Overview: In this example, I have implemented the following:

• a new action with parameters is defined in the behavior definition. The key of the RAP object will hold the keys of the table that need to be changed. The new values to be updated are passed by the UI as parameters to the action

action (features : instance) upload_file  parameter ZSD_ABS_CONTRACTUAL_INDATA;

• an RFC function module is created that accepts the data from the file in the form of an internal table
  
• Above RFC function module is called from the RAP action implementation ( with the addition destination ‘NONE’ as otherwise commit cannot be done from the FM to schedule the job ).

METHOD upload_file.

    DATA: gt_return   TYPE STANDARD TABLE OF zsds_soitem_message,
          lt_sch_data TYPE zsdt_soschdata.

    IF NOT keys[] IS INITIAL.
      LOOP AT keys INTO DATA(ls_keys).
        APPEND INITIAL LINE TO lt_sch_data ASSIGNING FIELD-SYMBOL(<ls_sch_data>).
        <ls_sch_data>-vbeln = ls_keys-salesdocument.
        <ls_sch_data>-posnr = ls_keys-salesdocumentitem.
        <ls_sch_data>-del_dt = COND #( WHEN ls_keys-%param-newcontractualdt IS NOT INITIAL
                                       THEN ls_keys-%param-newcontractualdt ).
        <ls_sch_data>-email = cond #( WHEN ls_keys-%param-email IS NOT INITIAL
                                       THEN ls_keys-%param-email ).

      ENDLOOP.

      CALL FUNCTION 'ZSD_DEL_DATE_UPD_FILE' DESTINATION 'NONE'
        EXPORTING
          it_sch_data   = lt_sch_data
        EXCEPTIONS
          error_message = 99.

    ENDIF.

  ENDMETHOD.

• The function module calls the ‘JOB_OPEN’ and ‘JOB_CLOSE’ function modules to submit another program via a background job.
  
• The program runs asynchronously as a job and updates the data and also sends an email with the results to the email-id ( the parameter email in the previous screenshot )
  
• Email functionality has been implemented so the user is informed of the success or failure of the task as the UI doesn’t wait for a response and simply displays a message that the data will be updated in background.
  
• The button and the popup that allows the user to upload an excel file:

Conclusion: The above approach can be used to call an asynchronous task from an RAP object for OP SAP versions. With SAP Cloud 2311, it will also be possible to update the UI once the asynchronous task is completed using event driven actions.

The post Handle Asynchronous task in background job from a stateless UI application using RAP business object appeared first on ERP Q&A.

1. Use Meaningful Names

Choose clear, descriptive names for variables, methods, and classes. Avoid abbreviations and aim for names that convey the purpose and intent of the code.

2. Write Small and Focused Methods

Keep your methods small and focused on a single task. This makes the code easier to understand, test, and maintain. Aim for methods that do one thing and do it well.

3. Avoid Hardcoding Values

Hardcoding values makes the code inflexible and harder to maintain. Use constants or configuration tables instead, so changes can be made easily without modifying the code.

4. Comment Judiciously

Write comments that explain why a piece of code exists, not what it does. Good code should be self-explanatory, but comments can provide context and rationale for complex logic.

5. Follow Consistent Formatting

Maintain a consistent coding style and format throughout your ABAP programs. This includes indentation, spacing, and naming conventions. Consistent formatting improves readability and helps in code reviews.

6. Use Modularization Techniques

Break down complex processes into smaller, reusable components using subroutines, function modules, or methods. Modularization promotes code reuse and simplifies debugging.

7. Handle Exceptions Properly

Implement proper error handling using TRY-CATCH blocks. Ensure that your code gracefully handles exceptions and provides meaningful error messages to users.

8. Optimize Database Access

Minimize the number of database accesses and use efficient queries. Retrieve only the data you need and avoid nested SELECT statements. Use indexes and buffering where appropriate.

9. Avoid Using Obsolete Constructs

Stay updated with the latest ABAP syntax and features. Avoid using obsolete constructs and embrace modern ABAP features such as inline declarations, new string operations, and expressions.

10. Test Your Code Thoroughly

Write unit tests to validate your code’s functionality. Regular testing helps catch bugs early and ensures that your code behaves as expected in different scenarios.

11. Document Your Code

Provide clear and concise documentation for your programs. This includes explaining the purpose, usage, and any special considerations of your code. Good documentation aids future maintenance and onboarding of new developers.

12. Engage in Code Reviews

Participate in code reviews to share knowledge and ensure adherence to coding standards. Peer reviews help identify potential issues and foster a culture of continuous improvement.

By following these clean code principles and best practices, you can create ABAP programs that are robust, efficient, and easy to maintain. Clean code is a key factor in the long-term success of any software project, and SAP ABAP is no exception.

The post Writing Clean Code and Best Practices in SAP ABAP appeared first on ERP Q&A.

Are you starting your journey into the world of SAP ABAP programming? You’ve come to the right place! In this post, we’ve compiled 12 essential tips to help you navigate the initial steps of learning ABAP. Whether you’re a complete beginner or have some basic knowledge, these insights will provide a solid foundation to build your skills and confidence in working with ABAP.

What Is SAP ABAP?

SAP ABAP (Advanced Business Application Programming) is a high-level programming language developed by SAP for building applications on the SAP platform. If you’re planning a career in SAP development, mastering ABAP is a crucial step. It allows you to create customized reports, interfaces, forms, and more within SAP’s ERP environment.

12 Tips for Beginners Starting with SAP ABAP Programming

1. Understand the Basics of SAP

Before diving into ABAP, familiarize yourself with the fundamentals of SAP. Learn about SAP modules, the ERP system, and how different components interact.

2. Learn the Syntax and Structure

Start by understanding the basic syntax and structure of ABAP. Get comfortable with keywords, data types, and basic programming constructs.

3. Use the ABAP Development Tools (ADT)

Get accustomed to using ABAP Development Tools in Eclipse. It’s essential for efficient development and offers features like syntax highlighting, code completion, and debugging tools.

4. Understand Data Dictionary Objects

Learn how to work with Data Dictionary (DDIC) objects such as tables, views, data elements, and domains. These are crucial for database interactions in ABAP.

5. Practice Modularization Techniques

Master the use of subroutines, function modules, methods, and classes to write modular and reusable code. This will make your programs more maintainable and efficient.

6. Get Familiar with Internal Tables

Internal tables are a key feature in ABAP for handling data in-memory. Practice creating, populating, and manipulating internal tables.

7. Understand ALV Reports

Learn how to create and customize ALV (ABAP List Viewer) reports. ALV provides a flexible way to output data with features like sorting, filtering, and layout customization.

8. Explore Open SQL

SAP ABAP uses Open SQL for database operations. Learn the basics of SELECT, INSERT, UPDATE, and DELETE statements, and how to handle database transactions.

9. Practice Debugging

Get comfortable with the debugging tools in ABAP. Knowing how to effectively debug your code is crucial for identifying and fixing issues.

10. Learn About BAPIs and RFCs

BAPIs (Business Application Programming Interfaces) and RFCs (Remote Function Calls) are essential for integrating different SAP systems. Understand how to use them to enable communication between systems.

11. Get Hands-On with Enhancements and Exits

Learn about user exits, BADI (Business Add-Ins), and enhancement spots to customize and extend standard SAP functionality.

12. Engage with the SAP Community

Join the SAP community through forums, blogs, and SAP’s official website. Engaging with experienced professionals can provide valuable insights and help you stay updated with the latest developments.

Conclusion

Starting your SAP ABAP journey may feel overwhelming at first, but with the right approach, it becomes manageable and rewarding. Use these 12 tips as a checklist to gradually develop your skills and build a strong ABAP foundation. Whether you aim to become a technical consultant, developer, or SAP solution architect, understanding ABAP deeply enhances your career potential.

The post 12 Tips for Beginners Starting with SAP ABAP Programming appeared first on ERP Q&A.

This short overview of abstract entities concept in the context of non-standard RAP business object operations. It outlines their purpose, advantages, and implementation strategies, emphasizing their role in enhancing modularity and flexibility in data modeling.

Purpose

Abstract entities are Core Data Services (CDS) constructs specifically designed to model complex input parameters for non-standard RAP BO operations(actions and functions).

Database Independence

One of the key features of abstract entities is their independence from database persistence. They are particularly suited for parameter modeling and give possibility to redefine parameters on next modelling level.

Reusability

Abstract entities promote reusability across multiple operations. This characteristic enables developers to adopt a more modular approach, allowing the same abstract entity to be utilized in different contexts without the need for redundant definitions.

Parameter Flexibility

These entities support complex structures, including multi-level nested components. This flexibility allows for more sophisticated data representations and enhances the capability to handle intricate business logic.

Binding

Unlike traditional entities, abstract entities are not bound to specific BO nodes. They provides greater adaptability in how they are integrated into various operations.

Improved Separation of Concerns

By decoupling input parameter modeling from the actual business logic, abstract entities facilitate a clearer separation of concerns. This simplification in design leads to more maintainable and understandable code, as the focus can be placed on each aspect of the application independently.

In conclusion, abstract entities serve as a powerful tool for modeling complex input parameters in non-standard RAP BO operations.

2. Implementation details.

I want to highlight how to effectively use abstract entities in ABAP development. One of their key applications is for typing, particularly for action parameters in RAP actions. Let’s begin with a straightforward example.

We make a simple abstract entity with four fields.

@EndUserText.label: 'ABSTRACT ENTITY'
define root abstract entity ZPRU_ABS_ENTITY
{
    ABSTRACTENTITYNAME : char40;
    SURNAME : char40;
    AGE : int4;
    EMAIL : char40;
    
    CHILD : composition [ * ] of ZPRU_ABS_CHILD;
    CHILD_2: composition [ * ] of ZPRU_ABS_CHILD_2;
}

Next, I created a RAP business object with a root entity view (the specifics of which aren’t important for this example) and defined the ‘sendEntity’ action with an input parameter of type ZPRU_ABS_ENTITY.

Let’s have a look at action definition:

managed implementation in class zbp_pru_root_entity unique;
strict ( 2 );

define behavior for ZPRU_ROOT_ENTITY alias ROOT
persistent table zpru_dn
lock master
authorization master ( instance )
{
  create;
  update;
  delete;
  field ( readonly ) dn_no, freq, prod;

  //Flat
  action sendEntity parameter ZPRU_ABS_ENTITY;
  // Deep
  action sendEntity2 deep parameter ZPRU_ABS_ENTITY;
  // Deep Table
  action sendEntity3 deep table parameter ZPRU_ABS_ENTITY;

}

Right now, let’s check RAP business object implementation class.

CLASS lhc_root DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

    METHODS get_instance_authorizations FOR INSTANCE AUTHORIZATION
      IMPORTING keys REQUEST requested_authorizations FOR root RESULT result.

    METHODS sendentity2 FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity2.

    METHODS sendentity FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity.

    METHODS sendentity3 FOR MODIFY
      IMPORTING keys FOR ACTION root~sendentity3.

ENDCLASS.

CLASS lhc_root IMPLEMENTATION.

  METHOD get_instance_authorizations.
  ENDMETHOD.

  METHOD sendentity2.
    DATA(lv_deep_field_from_abs_entity) = keys[ 1 ]-%param-child[ 1 ]-abstractchildname.
  ENDMETHOD.

  METHOD sendentity.
    DATA(lv_field_from_abs_entity) = keys[ 1 ]-%param-abstractentityname.
  ENDMETHOD.

  METHOD sendentity3.
    DATA(lv_deep_table_field) = keys[ 1 ]-%param[ 1 ]-child[ 1 ]-abstractchildname.
  ENDMETHOD.

ENDCLASS.

Derived type:

As a result, you’ll see the KEYS table, where each row contains a %PARAM component. This component is typed as the structure ZPRU_ABS_ENTITY.

The next step is to demonstrate the use of the ‘deep parameter AbstractBDEF’ and the ‘deep table parameter AbstractBDEF’ in defining a BDEF action parameter.

To do this, we need to extend the abstract entity by adding a BDEF of type Abstract with a hierarchy.

First, I added the ‘root’ keyword to the abstract entity:

One important note: when adding a BDEF to an abstract entity, we initiate the creation of an abstract business object. As a result, we need to construct this business object in a way that’s quite similar to how we build standard RAP business objects. This is why we use keywords like ‘root’, ‘composition’, and ‘association to parent.’

I also created a new abstract entity, ZPRU_ABS_CHILD. Then, I added mutual associations between ZPRU_ABS_ENTITY as the root and ZPRU_ABS_CHILD as the child.

Then, I’ve created BDEF with ZPRU_ABS_ENITY as root entity and Abstract implementation type:

Let’s overview new abstract BDEF:

abstract;
strict ( 2 );
with hierarchy;

define behavior for ZPRU_ABS_ENTITY alias ABS
{
  association CHILD;
  association CHILD_2;
}

define behavior for ZPRU_ABS_CHILD alias CHILD
{

  association ROOT;

}

define behavior for zpru_abs_child_2 {

association third_level;

}

There are 3 main points:

1. add keyword ‘with hierarchy’ to make BDEF opt to deep expanding.
   
2. recreate RAP BO composition tree, add root entity and child entity.
   
3. explicitly mark association to ZPRU_ABS_CHILD.

Finally, I’ve added addition keyword ‘deep’ to action definition to expand action parameter type.

Let’s have a look into typing:

%PARAM typing:

You can notice that to component %PARAM a new nested table with the name CHILD has been added. It’s an effect of keyword ‘deep’ in action parameter definition. Component CHILD has type of table due to cardinality [ * ] in definition of composition in abstract root entity ZPRU_ABS_ENTITY.

Last topic is about addition ‘deep table’ to action parameter definition.

Let’s add it:

Hence, let’s check what has been changed in typing:

As you can see component %PARAM became table, before it was a structure. This is the effect of keyword ‘table’ in action parameter definition.

Lastly, the same principles apply to typing action output parameters. However, one key difference is that we can’t use the ‘deep’ addition when defining output parameters. As a result, the %PARAM component will be incorporated into the output’s derived type as a structure.

A table with summarizing:

The post CDS Abstract Entity and ABAP RESTful Application Programming Model: Input parameter modelling appeared first on ERP Q&A.

Unmanaged SAP RAP refers to a development approach where developers have more control over the data persistence and business logic compared to the managed approach. Here are some key aspects

1. Custom Logic: In unmanaged RAP, developers write their own custom logic for handling data retrieval, manipulation, and persistence. This gives more flexibility in how data is processed and stored.
   
2. Direct Database Access: Developers can directly access the database tables and define their own data models using Core Data Services (CDS) views or ABAP classes.
   
3. Explicit Service Definition: Unlike managed RAP, where service definitions are automatically generated based on annotations, unmanaged RAP requires developers to explicitly define service implementations and behaviors.
   
4. Manual CRUD Operations: CRUD (Create, Read, Update, Delete) operations need to be implemented explicitly in unmanaged RAP, giving full control over how data is managed.
   
5. Integration with Existing Systems: Unmanaged RAP is often used when integrating with existing systems or when there is a need for complex business logic that cannot be easily handled by the managed approach.
   
6. Flexibility: Developers have more freedom to implement complex validation rules, authorization checks, and other custom requirements directly in the application logic.

Overall, unmanaged SAP RAP provides a more hands-on approach to application development compared to the managed approach, allowing developers to leverage their expertise in ABAP programming and database handling while building modern RESTful APIs.

Top of Form

In this example, we will show a simple application for Employee build with RAP Unmanaged flavors.

Development steps.

To be summarized below object will be created for Unmanaged scenario.

Table ZT01_EMPLOYEE

Base CDS View Z_I_EMPLOYEES_U

Consumption CDS view Z_C_EMPLOYEES_U

Behavior Definition

Bottom of Form

Behavior definition

Implement the Create method

Implement Update Method

Implement Delete Method

Implement Adjust_Numbers method.

Implement Save method.

Test

1. Open the Application.

2. Click on Create. Give Input value and Create.

3. New Record got created.

4. Select any Row , click on Edit.

5. Change the value and Save.

6. Record will be updated.

7. Select the Rows and click on Delete.

8. Records will be deleted.

9. In the Database table also you can see the records.

So, all the CRUD operation is successful using RAP Unmanaged flavors.

The post SAP RAP Unmanaged scenario example-Simplified appeared first on ERP Q&A.

The SAP landscape has evolved significantly, with businesses seeking simpler, more efficient solutions that offer excellent user experiences. Many organizations remain deeply embedded in the SAP ecosystem, primarily focusing on ABAP over other languages. So, is it possible to develop feature-rich applications without other frontend languages? Yes, leveraging ABAP with RAP (ABAP Restful Application Programming) makes it possible.

Restful Application Programming is an ABAP programming model for creating business applications and services in an AS ABAP or BTP ABAP environment. RAP offers a standardized way of developing applications using Core Data Services (CDS), the modernized extended ABAP language, OData protocol, and the concept of business objects and services. RAP applications can only be created through ABAP development tools (ADT) and it’s available in SAP BTP ABAP Environment, SAP S/4 HANA Cloud, and AS ABAP >=7.56.

Before digging deeper into RAP, let’s explore CDS, annotations, and business services. To illustrate these concepts, let’s create a simple read-only list report application.

Developing an OData Service for simple list reporting

An OData service follows the best practices for developing and consuming RESTful APIs. This service can be used in SAP Fiori applications and can also be exposed as Web APIs. Below are the steps for creating a simple list report application:

Let’s explore each step in detail by creating the application.

Sample requirement: Create a read-only list report application which shows purchase order information.

• Create an interface CDS view which takes data from Purchase Order Header (EKKO) and Item (EKPO).

• Create two interface CDS views for showing master data of purchase order type and material details.

• Make an association between the purchase order type CDS view and material details CDS view from the purchase order header/item CDS view. The associated views will act as Search Help in the list report after applying the annotations.

• Create a consumption view on top of the Purchase Order Header/Item interface view (ZI_PURCHASE_ORDER_RVN).

The UI annotations needed for the application are written in the consumption CDS View or Metadata Extensions.

Now, we have the data model and the required annotations to manifest semantics for it. The next step is to create the OData service and binding the service.

To define a service, we first need to create a service definition. In service definition, we specify the CDS entities that need to be exposed. In this example, the gateway client is replaced by the service definition and service binding.

As a last step, create the service binding for service definition.

Set the binding type as OData V2 – UI, since this is an OData V2 service.

After publishing the service, the exposed entity and associated entities will be visible. Click on the entity and click the preview button to see the preview of the application.

Purchasing Doc Type Search Help

Material Search Help

Conclusion

This blog serves as an introduction to developing OData services for simple list reporting using the ABAP Restful Application Programming (RAP) model. By following the steps outlined, you can create a read-only list report application that showcases purchase order information. We have covered the basics of creating CDS views, defining and binding OData services, and incorporating annotations for enhanced functionality.

The post ABAP RESTful Application Programming Model (RAP) appeared first on ERP Q&A.

Regional Differences

Due to business and legal requirements SAP implementations often use different:

• G/L accounts
• Chart of accounts
• Cost centers
• Tax codes
• Currency codes
• Organization structures (sales organization, purchase org., plants, company codes etc.)

for different countries and regions.

So one of the first tasks is to search for hard coded G/L accounts, chart of accounts, cost centers, tax codes, currency codes, sales organizations, purchase organizations, plants and company codes in custom ABAP programs and replace the findings by appropriate variables or customizing tables.

Currency Codes

Replacing hard coded currency codes should be pretty simple. Most transactional data tables have both fields (amount beside and currency code) and the currency code is part of the company settings in table T001, too. So instead of hardcoding the currency code it`s better to read the currency code from the transactional data table where applicable or from the T001-table. If hard coded currency codes are used to decide whether a currency conversion must be performed the decision can be simply omitted as the currency conversion between the same currency leads to the same result.

Calculations done with currency values

Special care must be taken in custom programs, which calculate differences or ratios between two currency values. If the program simply subtract or divides those two values, you will get wrong results when the first value has a different currency than the other. In one of my projects we had this issue, because the programs were built at the time, where SAP was implemented for only one country and all values were in the same currency.

Translation

Translation API

Translating all objects with transaction SE63 is quite impractical as you need to go through every single object. Under the hood the transaction SE63 uses a API, which can be used to build your own more practical translation program. This API (translation API) consists of the following parts:

• the table LXE_ATTOB, which contains the types of translation objects
• the function module LXE_OBJ_OBJECTS_GET, which reads the translation objects for a given object type and collection. In case of ABAP development objects the collection is the package.
• the function module LXE_OBJ_TEXT_PAIR_READ to read the text pairs
• the function module LXE_OBJ_TEXT_PAIR_WRITE to write the text pairs
• the function module LXE_OBJ_CREATE_TRANSPORT_ENTRY to append the translation object to a workbench request

The GitHub repository https://github.com/SAP-Easy-Translation/abap_client is a example, how the translation API could be used to select the text pairs from a range of packages and edit or review these text pairs in a more practical way.

Other language dependent texts

The translation needs to cover all language dependent texts. Beside the obvious ABAP development objects (Dictionary-Objects, Text-Elements in programs and classes, T100-Messages, Forms etc.) there are a few more language dependent texts:

• Descriptions for customizing objects (custom sales documents types, Sales order reasons, Delivery note types, Invoice types, Conditions, Purchase Order Types, Material groups etc.)
  
• Report variant descriptions
  
• Queries build with transaction SQ01
  
• SapScript Standard Texts maintained in transaction SO10

You shouldn’t forget to translate these objects, too.

Customizing objects

The descriptions of the customizing objects can be edited directly in the maintenance views or by selecting the object types TADC, TADE, TADG, TADS, TADW, TAIC, TAIE, TAIG, TAIS and TAIW in the translation transaction SE63.

Report variant descriptions

Report variant descriptions can be found under the object types VARI (system variants) and VARX (local report variants).

Queries

Queries can be translated in the transaction SQ02 by going to the menu Environment -> Language comparison.

and by entering the Query and the user group or the InfoSet in the next screen.

Both query and InfoSet should be translated and after the translation you should regenerate the Query program (Transaction SQ01 -> Menu -> Query -> More functions -> Generate program).

SapScript Standard Texts

SapScript Standard Texts are translated in transaction SO10. Enter Text name, Text ID and the target language and press the “Create”-Button or “Change”-Button to translate the text.

SapScript Standard Texts are not automatically added to a workbench request. The program RSTXTRAN must be called to achieve this.

Form Printing

When you print SapScript forms or SmartForms, make sure to activate UPE (Unicode Printing Enhancement) as described in note 1812076. Otherwise you will get hashmarks (#) for characters, which are not included in the character set of the printer.

Conclusion

This blog post should show you some of the caveats when implementing SAP for new countries or regions. However there some more cultural differences between regions. Some asian countries like Thailand have two different calendars (buddhist calendar and gregorian calendar) and in some countries like Japan the fiscal year is different from the calendar year. These differences should be keept in mind when dealing with issues or when adapting custom ABAP code for new countries or regions.

The post Going international – Caveats in custom ABAP programs appeared first on ERP Q&A.

Effective user provisioning is essential for both organisational security and productivity in the context of digital operations. But controlling user access across many systems can be complicated and difficult at times. This blog article will discuss how IBM Verify SaaS integrates seamlessly with SAP NetWeaver and explain how this works together to improve overall operational efficiency, strengthen security, and streamline user provisioning processes.

SAP NetWeaver (on-premise) is a widely used platform that acts as the foundation for various SAP applications, including SAP ECC and S/4HANA. Users typically log in to these applications through the SAP NetWeaver interface.

IBM Security Verify SaaS adds an extra layer of security to the login process for SAP ECC and S/4HANA systems. By integrating with SAP NetWeaver, it allows users to log in securely using a web browser, but also requires an additional verification step (Multi-Factor Authentication or MFA) provided by IBM Security Verify. This MFA could be a code from a mobile app, a fingerprint scan, or another secure method.

SAP Netweaver on ABAP Stack vs SAP Netweaver on Java Stack

Development stacks for Java and ABAP are provided by SAP NetWeaver. Java offers open-source flexibility and meets the demands of contemporary development, while ABAP excels in fundamental business logic and connects with SAP with ease. Select Java for modern apps, scalability, and a larger talent pool, or ABAP for deep integration and current SAP expertise. Although it’s less prevalent, both allow interoperability and can coexist on a single server.

While IBM Security Verify offers an adapter for integrating with SAP NetWeaver applications on the Java stack, this blog focuses specifically on the integration process for SAP NetWeaver applications built on the ABAP stack with IBM Security Verify SaaS.

Architecture

IBM Security Verify SaaS can be integrated with a hybrid SAP landscape, including on-premise SAP Netweaver, cloud-based SAP BTP, and other SAP SaaS offerings (such as SAP SuccessFactors, SAP ARIBA, SAP Fieldglass). This centralized approach offers strong security with Multi-Factor Authentication and simplifies user experience through Single Sign-On. Users authenticate through IBM Security Verify, which then communicates with the relevant SAP application (Netweaver, BTP, or SAP SaaS offering) to grant access. This architecture enhances security and streamlines user experience for accessing SAP resources.

Prerequisites

• SAP NetWeaver
• IBM Security Verify
• A smartphone with IBM Security Verify App

Configurations and Settings in IBM Security Verify and SAP NetWeaver

IBM Security Verify Configuration :

Log in into IBM Security Verify as an administrator

You will be navigated to the home screen, as displayed below, after logging in.

Now, follow these steps:

1. On the left panel, click “Applications” under “Applications.”
   
2. On the right side of the screen, click the “Add application” button.
   
3. In the default applications list, search for “SAP NetWeaver” instead of creating a custom application.

As indicated below, complete the “General” section with the relevant information, then save it.

Select the “Sign on” tab and complete the fields as indicated by the screenshots below. The required data is available through your individual SAP NetWeaver account. Furthermore, adhere to the conditions listed in “Prerequisites” in order to receive the necessary information from SAP NetWeaver.

Now we need to upload “Metadata” file into SAP Netweaver which we can download from IBM Verify dashboard as mentioned in below steps.

1. Go to “Sign on” section of the application and scroll on the right side of the screen where you can find prerequisites
   
2. Scroll down as mentioned on below screenshots to the download metadata step and click on the link.
   
3. The metadata file will be saved to device which you can upload to in SAP NetWeaver Cloud as highlighted below:

Refer to SAP Netweaver user details to create a user in IBM Security Verify. Follow the instructions outlined below.

1. Log in to SAP Netweaver via SAP GUI.
2. Navigate to transaction code “SU01D”.
3. Choose the user for whom you want to create details in IBM Security Verify.
4. Gather user information, including first and last names, email addresses, etc.

For reference see below screenshot:

As we have completed the configurations in IBM Security Verify. Now, let’s add a user with the appropriate attributes in IBM Security Verify and check if it maps to the SAP NetWeaver dashboard.

1. Go to the “Users” tab under the “Directory” section on the left side of the IBM Security Verify dashboard.

Click on the “Add User” button as shown in the screenshot below.

Complete all required fields in the user information section depicted in the image below, then proceed to click on the “Save” button within the user tab interface.

Navigate downwards to access additional fields for adding further details about the user. In the provided screenshot, you can observe that we have included the email address for the user.

After completing the necessary user details, proceed to click on the “Save” button to ensure the user information is stored. Set up the SAP Netweaver configuration and then access the SAP NetWeaver application to ensure that the newly formed user is correctly mapped within the system.

SAP Netweaver Configuration

Establish a local SAML 2.0 provider: Enter into the SAP Netweaver login page using SAP GUI. Here, access the transaction “SAML2” by navigating to the command field at the top of the screen, as indicated below:

A web browser configuration screen will be displayed, requiring you to choose “Create SAML2.0 Local Provider” and press the “Next” button.

Enter “IBM_Security_Verify” as the provider name in the Initial settings.

Click “Next” since there is no need to modify the options in the “General Settings” box.

Select the “Finish” option, we’ll leave the “Service Provider Settings” as they are by default, as seen below.

You will now be taken to the screen below, where you can see the details that you customised in accordance with the previous instructions.

Upload Metadata File: As indicated below, click the “Trusted Providers” section. Then, click the “Add” button to bring up a drop-down menu, from which choose “Upload Metadata File” and upload the file which was downloaded from IBM Security Verify to local device.

There should be a new line item shown in the trusted providers list. You can configure in the “Endpoints” area as seen in the screenshot below.

Click “Add” after selecting the “Identity Federation” section, then enter the user’s email address under “Supported NameID Formats”. Additionally, as seen in the screenshot below, set “Email” as the User ID mapping mode and “email” for the “Assertion Attribute Name” field.

The following step will take us to a different section called “Signature and Encryption” where we will check the value of “Digest Algorithm” and, if it isn’t already, set it to “SH-256”. We will also check the values of the remaining fields, as indicated in the screenshot below:

We’ll now select the “Authentication Requirements” option and review the default settings as shown below:

Include a policy for web applications: To access “Policies,” follow the instructions in the screenshot below. After choosing “Web Applications Policies” press “Add”.

Name the policy “SSO” and describe it as such. And confirm the information as displayed in the screenshots below:

Let’s test :

Use the web browser to log in to SAP Netweaver as shown below. Please be aware that in order to access SAP Netweaver on a web browser, you must utilise a login link.

Here, I’ll use the IBMid for further login into the system.

Give your IBMid and click on “Continue”.

Select “w3id Credentials” as below :

Give your username and password details and click on “Sign in”.

You should be able to access the SAP Netweaver as below in your web browser.

Conclusion

The integration of IBM Verify with SAP NetWeaver presents a powerful synergy that not only simplifies user provisioning but also fortifies organisational security and enhances operational efficiency. By combining the robust authentication features of IBM Verify with the versatile platform of SAP NetWeaver, businesses can streamline user access management, reduce manual effort, and bolster security measures. This integration not only ensures compliance and consistency but also elevates the overall user experience. As organizations navigate the complexities of the digital landscape, leveraging this integration can provide a competitive edge while effectively managing user identities and access controls.

The post Boosting SAP Netweaver Security: A Guide to Integrating SAP Netweaver (ABAP Stack) with IBM Verify appeared first on ERP Q&A.

In this blog post, I would like to share some insights for generating OpenXML documents by use of the RESTful Application Programming Model with Cloud-released development objects. With this app, you will be able to upload .docx templates and fill them with information from you CDS view (could be used for generating invoices, business documents and so on…).

Prerequesites

• SAP BTP ABAP environment or an S/4 system to your disposal.
  
• Eclipse IDE installed on your local machine with the ABAP Development Tools.

Shortcut with abapGit:

For those who are using abapGit, feel free to check out the code from my GitHub repo!

Step 1:

Create a database table with the following config (hint: do not forget to generate custom domains for mime type and attachment type)

@EndUserText.label : 'Invoice for document generation'
@AbapCatalog.enhancement.category : #EXTENSIBLE_ANY
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #A
@AbapCatalog.dataMaintenance : #RESTRICTED
define table zmri_invoice {

  key client            : abap.clnt not null;
  key invoice           : ebeln not null;
  comments              : abap.char(30);
  attachment            : zmriattachment;
  mimetype              : zmimetype;
  filename              : zfilename;
  purchaseorder         : abap.char(30);
  price                 : abap.dec(8,2);
  local_created_by      : abp_creation_user;
  local_created_at      : abp_creation_tstmpl;
  local_last_changed_by : abp_locinst_lastchange_user;
  local_last_changed_at : abp_locinst_lastchange_tstmpl;
  last_changed_at       : abp_lastchange_tstmpl;

}

Step 2:

Generate ABAP repository objects by right-clicking on the previously created database table.
Choose the ABAP RESTful Application Programming Model (OData UI Service) variant.

Step 3

Create a custom action in your Behavior Definition:

managed implementation in class ZBP_R_MRI_INVOICE unique;
strict ( 2 );
with draft;
define behavior for ZR_MRI_INVOICE alias ZrMriInvoice
persistent table ZMRI_INVOICE
draft table ZMRI_INVOIC000_D
etag master LocalLastChangedAt
lock master total etag LastChangedAt
authorization master( global )

{
  field ( mandatory : create )
   Invoice;

  field ( readonly )
   LocalCreatedBy,
   LocalCreatedAt,
   LocalLastChangedBy,
   LocalLastChangedAt,
   LastChangedAt;

  field ( readonly : update )
   Invoice;


  create;
  update;
  delete;

  action ( features : global ) createMSWordInvoice ;

  draft action Activate optimized;
  draft action Discard;
  draft action Edit;
  draft action Resume;
  draft determine action Prepare;



  mapping for ZMRI_INVOICE
  {
    Invoice = invoice;
    Comments = comments;
    Attachment = attachment;
    Mimetype = mimetype;
    Filename = filename;
    PurchaseOrder = purchaseOrder;
    Price = price;
    LocalCreatedBy = local_created_by;
    LocalCreatedAt = local_created_at;
    LocalLastChangedBy = local_last_changed_by;
    LocalLastChangedAt = local_last_changed_at;
    LastChangedAt = last_changed_at;
  }
}

Step 4:

Implement the custom action in your behaviour implementation class:

CLASS lhc_zr_mri_invoice DEFINITION INHERITING FROM cl_abap_behavior_handler.
  PRIVATE SECTION.

    CLASS-DATA: mt_data TYPE zmri_invoice.

    DATA:
          lv_content   TYPE xstring,
          lo_zip       TYPE REF TO cl_abap_zip.

    METHODS:
      get_global_authorizations FOR GLOBAL AUTHORIZATION
        IMPORTING
        REQUEST requested_authorizations FOR ZrMriInvoice
        RESULT result,

      get_global_features FOR GLOBAL FEATURES
        IMPORTING
        REQUEST requested_features FOR ZrMriInvoice
        RESULT result,

      createMSWordInvoice FOR MODIFY
        IMPORTING keys FOR ACTION ZrMriInvoice~createMSWordInvoice.

ENDCLASS.

CLASS lhc_zr_mri_invoice IMPLEMENTATION.

  METHOD get_global_authorizations.
*  This method does not need an implementation
  ENDMETHOD.

  METHOD createMSWordInvoice.

*     Select document to be filled
    SELECT * FROM zc_mri_invoice
     FOR ALL ENTRIES IN @keys
     WHERE invoice      = @keys-invoice
     INTO CORRESPONDING FIELDS OF @MT_data.
    ENDSELECT.

*     Create zip class instance
    lo_zip = NEW cl_abap_zip( ).

*     Search for main document part
    DATA lv_index TYPE string VALUE 'word/document.xml'.

*     Load attachment into zip class object
    lo_zip->load( zip = mt_data-attachment check_header = abap_false ).

*     Fetch the binaries of the XML part in the attachment
    lo_zip->get(
    EXPORTING
      name   = lv_index
    IMPORTING
      content = lv_content
    ).


* Convert the binaries of the xml into a string
    DATA(lv_string) = xco_cp=>xstring( lv_content
      )->as_string( xco_cp_character=>code_page->utf_8
      )->value.

* Search for the text to be replaced and fill with the information in your data set
    REPLACE FIRST OCCURRENCE OF '<InvoiceNumber>' IN lv_string
    WITH mt_data-Invoice.

    REPLACE FIRST OCCURRENCE OF '<Purchase Order>' IN lv_string
    WITH mt_data-PurchaseOrder.

    REPLACE FIRST OCCURRENCE OF '<Comments>' IN lv_string
    WITH mt_data-Comments.

    DATA lv_price TYPE string.
    lv_price = mt_data-Price.

    REPLACE FIRST OCCURRENCE OF '<Price>' IN lv_string
    WITH lv_price.

* Convert the changed XML string into binaries
    DATA(lv_new_content) = xco_cp=>string( lv_string )->as_xstring( xco_cp_character=>code_page->utf_8
    )->value.

* Delete "old" main document part from the zip file
    lo_zip->delete(
    EXPORTING
      name   = lv_index
    ).

* Add "new" main document part to the zip file
    lo_zip->add(
    EXPORTING
      name   = lv_index
      content = lv_new_content
    ).

* Save the new zip file
    DATA(lv_new_file) = lo_zip->save( ).

* Upload changed docx file
    MODIFY ENTITIES OF zr_mri_invoice IN LOCAL MODE ENTITY ZrMriInvoice
      UPDATE SET FIELDS WITH
      VALUE #( (
          Invoice = mt_data-Invoice
          Attachment = lv_new_file
      )  )
    FAILED failed.

    APPEND VALUE #( %msg = new_message_with_text( severity = if_abap_behv_message=>severity-success text = 'Template successfully filled...' ) ) TO reported-ZrMriInvoice.
  ENDMETHOD.

  METHOD get_global_features.
* This method does not need to be implemented
  ENDMETHOD.


ENDCLASS.

Explanation: In this implementation class, the cl_abap_zip class (which is released for cloud development) is used to load the .docx template. If you didn’t already know, a .docx file is basically a ZIP-file. In order to get the main document part, we need to fetch the “word/document.xml” file within the zip object by applying the lo_zip->get() method. This method returns an XSTRING which has to be converted into an UTF-8 encoded string, for us to modify the content of the main document part. For the binary-to-string conversions the xco_cp class is used, which is part of the XCO library (I can only recommend using this library as it has some great features). Afterwards the converted XML-string has to be modified with the invoice details from your CDS view. The modified XML-string has to be converted back into binaries, by use of the same class. The last step is to delete the “old” main document part from the zip object and add the new document content to the zip object. Now update the attachment field in your CDS entity and that’s it. Your app should now be able to populate a .docx-file with information from your CDS view.

Step 5:

Create a metadata extension and a service binding for your Fiori Frontend and test the application:

@Metadata.layer: #CORE
@UI: { headerInfo: {
typeName: 'Invoice',
typeNamePlural: 'Invoices',
title: { type: #STANDARD, value: 'Invoice' },
         description: { type: #STANDARD, value: 'Invoice' } },
         presentationVariant: [{
         sortOrder: [{ by: 'Invoice', direction: #ASC }],
         visualizations: [{type: #AS_LINEITEM}] }] }
annotate view ZC_MRI_INVOICE with
{
  .facet: [    {
                label: 'General Information',
                id: 'GeneralInfo',
                type: #COLLECTION,
                position: 10
                },
                     { id:            'Invoicedet',
                    purpose:       #STANDARD,
                    type:          #IDENTIFICATION_REFERENCE,
                    label:         'Invoice Details',
                    parentId: 'GeneralInfo',
                    position:      10 } ]

  : { lineItem:       [ { position: 10, importance: #HIGH , label: 'Invoice Number'} ] ,
          identification: [ { position: 10 , label: 'Invoice Number' } ] }
  Invoice;
  : { lineItem:       [ { position: 20, importance: #HIGH , label: 'Purchase Order'} ] ,
           identification: [ { position: 20 , label: 'Purchase Order Number' } ] }
  PurchaseOrder;
  : { lineItem:       [ { position: 20, importance: #HIGH , label: 'Price'} ] ,
           identification: [ { position: 20 , label: 'Price' } ] }
  Price;
  : { lineItem:       [ { position: 20, importance: #HIGH , label: 'Comments'} ] ,
           identification: [ { position: 20 , label: 'Comments' } ] }
  Comments;
  :
  { lineItem:       [ { position: 30, importance: #HIGH , label: 'Attachment'}, { type: #FOR_ACTION, dataAction: 'createMSWordInvoice' , label: 'Create Invoice' } ], 
    identification: [ { position: 20 , label: 'Attachment' }] 
  }
  Attachment;

  .hidden: true
  MimeType;

  .hidden: true
  Filename;


}

Test the application by creating an entry and uploading a docx-template.

The template could look something like this:

Now select the entry and use the custom action to fill the template with your data:

After the success message, click on the attachment (template.docx) and verify that the placeholders have been filled:

The post Upload and modify OpenXML documents via RAP App in SAP BTP ABAP Environment appeared first on ERP Q&A.