SAP S/4HANA is the latest version of SAP. The full form of SAP S/4HANA is SAP Business Suite 4th generation ERP High Performance Analytic Appliance.

There are 3 layers that are present in SAP namely:-

1. Presentation layer
2. Application Layer
3. Database Layer

In the 1990’s a new architecture was introduced, and it was R/3. In R/3 architecture we can observe the three layers namely presentation layer, application layer and database layer.

The speed of R/3 architecture is fast when compared with R/2 architecture. The algorithms in R/2 architecture were in the database layer whereas the algorithms in R/3 architecture are in the application layer. The database layer can be anyone like oracle, Microsoft etc…

1. Presentation Layer

The presentation layer is a screen where user can interact with the system. For example we can take Monitor of a computer or laptop screen. So for SAP it is GUI –> Graphical User Interface. Here user will interact with SAP data base with the help of SAP GUI which is a software that will be installed on laptops.

2. Application Layer

This is the main advantage of SAP R/3 architecture. Here it acts as like middle wear between presentation layer and database layer. Here it will process the user input , applies business rules and execute the programs in this layer.
Here in this layer it will collects all the details or actions that are being carried out by the user and interacts with the database system and represents them on the output screen.

Dispatcher: Dispatcher will collects the request and will decide which type of request it is whether it is dialog, update, background, spool , enqueue. After getting to know about the spool request type it will also check for the work processor which is idle.
Work Processor:- After getting the request into work processor it will co-ordinate with the database management and will perform the operation or action on the database and will also gets a acknowledgement .

3. Database layer

After getting the request or command form the database management the database layer will process it and will update the request.

The below diagram is the in-depth process of how the database layer will function.

DATABASE LAYER FUNCTION FLOW:

• The request from the work processor will first enter into the session manager and the session manager will makes user to automatic behaviour and transaction isolation level.
  
• Once the request got established the request moves to the planning engine which analyses SQL.
  
• And here SQL engine will runs the machine.
  
• The transaction manager assigns a transaction ID and ensures that every operation follows the principle, transactions to the SQL engine and data engine.
  
• The data engine takes over the user request and performs it on the database.
  
• Index Server → Executes SQL/MDX queries, does actual processing.
  
• Name Server → Knows where the data lives.
  
• Pre-processor → Text & search.
  
• XS Engine → Application services.
  
• Persistence Layer → Save points + logs.

In 2015 the SAP S/4HANA has been introduced and here the database is HANA, and this is SAP’S own database. The Hana database can also be called as in-memory database.

S/4HANA is also called 4th generation SAP.

Versions of SAP S/4HANA are released in the following years: –

SAP S/4Hana works with Fiori NetWeaver GUI.

Advantages of sap s/4hana:

• The performance and speed have been improved due to databases.
  
• Embedded analytics have been embedded in sap s/4hana
  
• In ECC we can only perform operations, and some extract basic reports can be extracted in ECC, but not more complex reports can be extracted, when it comes to s/4Hana we can easily extract the complex reports easily.

OLTP – Online Transaction processing (ECC)

OLAP – Online Analytical Processing (BI/BW)

OLTP + OLAP + Planning – SAP S/4HANA

Planning ->

• MRP line
  
• PD MRP
  
• ATP (advanced available to promise)
  
• PDS (production planning and detailed scheduling)

SAP HANA: This Hana is a database which is also called an in-memory database, and this provides or is capable of analytics, data models and library for code writing.

The HANA database can be accessed through HANA STUDIO.

SAP HANA: This Hana is a database which is also called an in-memory database, and this provides or is capable of analytics, data models and library for code writing.

The HANA database can be accessed through HANA STUDIO.

SAP BW powered by HANA (BW for HANA):

SIDE CAR: For suppose you have an ECC system which is working on any database and now you want to connect it with the HANA database then there will be a middle wear SLT which is a software brings the data from table to HANA database.

• HANA live is a tool which can be used to view the analytics of data.
  
• Lumera system is a toll which is being used to represent or visualize the analytical data.

Benefits of a side car:

• Main cars are not being distributed.
  
• It can be implemented in 1.5 to 2 months.

Drawback:

• Data footprint increases: the data is being replicated from the production system to the side car so more space will be occupied.
  
• The landscape is very complex.

SAP BW POWERED BY HANA: It was introduced in 2012 and here the analytical can be obtained. The complex reports can be fetched within seconds only.

SAP BUSINESS SUIT POWERED BY SAP HANA: It was introduced in 2013 in this enhancement pack (EHP 7 or and here the system is ECC, and the database is HANA.)

OLAP + OLTP.

SAP SIMPLE FINANCE POWERED BY SAP HANA: ECC with HANA Database but the difference between this and SOH is only the fico module as they have simplified the data module for FICO and introduced Fiori apps separately for fico and ACDOCA table which is single source of truth table.

Apart from fico modules the other modules will work as they were functioning in the same manner as ECC on any other database.

S/4HANA: This was introduced in 2015 they have simplified the data model for all the modules. They have introduced MATDOC, ACDOCA table and innovations + Fiori apps for all the modules

APP_L -> Technical application for ECC.

S/4 core -> Technical application for HANA.

The post SAP S/4HANA Architecture Functional Flow appeared first on ERP Q&A.

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.

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.

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.

The “AL11” Tcode in the SAP system is a tool used to inspect and manage data and structures in the file system. This Tcode provides access to and the ability to manipulate data in the file system within the SAP system. AL11 Tcode is commonly used to inspect, backup, restore, and perform other file operations in the SAP system.

One of the biggest advantages of AL11 is the ability to process files via ABAP by storing them in the SAP system instead of locally saving files received from third-party systems.

Generally, three operations are carried out via AL11:

1) File Viewing
2) File Uploading
3) File Deletion

Let’s briefly talk about the “CG3Z” and “CG3Y” Tcodes, which are used for file operations in the SAP system. These Tcodes are commonly used for managing and processing data within the file system, including tasks such as file transfer, upload, download, and deletion. “CG3Z” is typically used for uploading files into the SAP system, while “CG3Y” is used for exporting files from the SAP system.

CG3Y and CG3Z:

EPS2_GET_DIRECTORY_LISTING is a function used in the SAP system to list the files in a specific directory within the file system. This function is used to retrieve a list of files located in the specified directory. EPS2_GET_DIRECTORY_LISTING is used to examine the contents of a specific directory in the file system and retrieve details such as the names, sizes, dates, and other properties of the files within that directory. This information allows users to manage and process files in file operations and data integration processes. The EPS2_GET_DIRECTORY_LISTING function is commonly used when performing file-based operations within the SAP system, serving as a useful tool for file management and processing.

DATA: lt_dir_list  TYPE eps2filis .
    DATA: lv_xstring   TYPE xstring .
    DATA: lv_mess      TYPE string .


    DATA(lv_path) = CONV eps2filnam( '\\test\path\' ). " Path in Al11
    CONCATENATE lv_path  sy-sysid '\in' INTO lv_path .


    CALL FUNCTION 'EPS2_GET_DIRECTORY_LISTING' " this function reads file names from directory to table
      EXPORTING
        iv_dir_name            = lv_path
      TABLES
        dir_list               = lt_dir_list
      EXCEPTIONS
        invalid_eps_subdir     = 1
        sapgparam_failed       = 2
        build_directory_failed = 3
        no_authorization       = 4
        read_directory_failed  = 5
        too_many_read_errors   = 6
        empty_directory_list   = 7
        OTHERS                 = 8.

    IF sy-subrc <> 0 OR lines( lt_dir_list ) EQ 0.
      WRITE 'Directory ist leer'.
    ENDIF.

In ABAP programming language, the “OPEN DATASET” command is used for file operations. This command is used to open the specified file for reading, writing, or other operations. Here is how the “OPEN DATASET” command is used:

1. Opening a File:

OPEN DATASET <file_name> FOR INPUT|OUTPUT|APPENDING|... [IN LEGACY TEXT ENCODING|IN BYTE MODE] [MESSAGE <message_variable>].

• <file_name>: The name of the file to be processed.
• FOR INPUT: Open the file for reading.
• FOR OUTPUT: Open the file for writing. If the file does not exist, it is created; if it exists, it is overwritten.
• FOR APPENDING: Open the file for appending data at the end.
• IN LEGACY TEXT ENCODING: Opens the file with legacy text encoding.
• IN BYTE MODE: Opens the file in byte mode.
• MESSAGE <message_variable>: Allows returning a message based on the operation.

2. Closing a File:

CLOSE DATASET <file_name>.

• <file_name>: The name of the file to be closed.

3. Writing to a File:

TRANSFER <data> TO <file_name>.

• <data>: The data to be written to the file.
  
• <file_name>: The name of the file where the data will be written.

4. Reading from a File:

READ DATASET <file_name> INTO <data_variable>.

• <file_name>: The name of the file to be read.
  
• <data_variable>: The variable where the read data will be stored.

These commands are fundamental for file operations in the ABAP programming language and provide a wide range of functionality for file manipulation.

Let’s complete the explanation by providing a complete code example.

DATA: lt_dir_list  TYPE eps2filis .
    DATA: lv_xstring   TYPE xstring .
    DATA: lv_mess      TYPE string .


    DATA(lv_path) = CONV eps2filnam( '\\test\path\' ). " Path in Al11
    CONCATENATE lv_path  sy-sysid '\in' INTO lv_path .


    CALL FUNCTION 'EPS2_GET_DIRECTORY_LISTING' " this function reads file names from directory to table
      EXPORTING
        iv_dir_name            = lv_path
      TABLES
        dir_list               = lt_dir_list
      EXCEPTIONS
        invalid_eps_subdir     = 1
        sapgparam_failed       = 2
        build_directory_failed = 3
        no_authorization       = 4
        read_directory_failed  = 5
        too_many_read_errors   = 6
        empty_directory_list   = 7
        OTHERS                 = 8.

    IF sy-subrc <> 0 OR lines( lt_dir_list ) EQ 0.
      WRITE 'Directory ist leer'.
    ENDIF.


    LOOP AT lt_dir_list INTO DATA(ls_dir_file).
      CLEAR : lv_xstring , lv_mess .
      DATA(lv_file) = lv_path && '\' && ls_dir_file-name .

      OPEN  DATASET lv_file FOR INPUT IN BINARY MODE MESSAGE lv_mess .
      READ  DATASET lv_file INTO lv_xstring .
      CLOSE DATASET lv_file .

      APPEND VALUE #( file_name    = ls_dir_file-name
                      file_content = lv_xstring
                      customer     = 'CustomerName'
                      path         = lv_path ) TO mt_files.  " mt_files is coming from class as attribute
    ENDLOOP.

In the code example above:

1) We retrieve the names of the files located in the directory ‘\\test\path\’ using the ‘EPS2_GET_DIRECTORY_LISTING’ function and store them in the table ‘lt_dir_list’.
2) By looping through the ‘lt_dir_list’ table, we retrieve the file names along with their respective directories.
3) We open, read, and close the file using the OPEN, READ, CLOSE DATASET commands, and after reading the content, we store it in ‘lv_xstring’.
4) Finally, we transfer the read data into a table.

The post AL11: File Management and Inspection in the SAP System appeared first on ERP Q&A.

Enhancing Standard Fiori Apps in S/4HANA: A Comprehensive Guide to How to Adding Custom Fields in Standard SAP Fiori Apps and How to Adding a Fields in a Filter Bar of a Standard SAP Fiori App.

Detailed Steps:

1. Navigate to Fiori Library: here

1.1 Enter SAP Fiori App Name or Fiori App Id

Ex: “Overdue Materials – Goods Receipt Blocked Stock” Or “F2347”

1.2 Navigate to ‘ IMPLEMENTATION INFORMATION’ Tab then ‘ Configuration ’

1.3 Get OData service : MMIM_OVERDUE_GRBLOCKED_SRV.

2. Navigate to SAP GUI and go to T-Code SEGW :

2.1 Open new project and add your OData project: MMIM_OVERDUE_GRBLOCKED.

2.2 Follow the steps below to get CDS view.

3. Open Eclipse Editor:

3.1 Create Extend View: ” ZMM_GR_BS_DDL ” and enter your logical code.

@AbapCatalog.sqlViewAppendName: 'ZMM_GR_BS_DDL'
@EndUserText.label: 'Add custom field in GR Blocked Stock'

extend view C_MaterialOverdueGRBlocked with ZMM_GR_B_STOCK
association [1..1] to ekkn as _Extend_EKKN on $projection.purchaseorder = _Extend_EKKN.ebeln  and $projection.purchaseorderitem = _Extend_EKKN.ebelp
association [1..1] to eban as _Extend_EBAN on $projection.purchaseorder = _Extend_EBAN.ebeln  and $projection.purchaseorderitem = _Extend_EBAN.ebelp
{   
    @Search.defaultSearchElement: true
    @Search.fuzzinessThreshold: 0.8
    @Search.ranking: #HIGH
    @EndUserText.label: 'Job Order'
    @Consumption.valueHelpDefinition: [{ entity: { element: 'AUFNR' , name: 'ZMM_JobOrdGRBlockStock_VH' } }]
    _Extend_EKKN.aufnr ,
    
    @Search.defaultSearchElement: true
    @Search.fuzzinessThreshold: 0.8
    @Search.ranking: #HIGH
    @EndUserText.label: 'PR Number'
    _Extend_EBAN.banfn,
    
    @Search.defaultSearchElement: true
    @Search.fuzzinessThreshold: 0.8
    @Search.ranking: #HIGH
    @EndUserText.label: 'PR Item'
    
    _Extend_EBAN.bnfpo,
    @Search.defaultSearchElement: true
    @Search.fuzzinessThreshold: 0.8
    @Search.ranking: #HIGH
    @EndUserText.label: 'Storage Location'
    
    _Extend_EBAN.lgort,
    _Extend_EKKN ,
    _Extend_EBAN
   }

3.2 Go to SAP GUI -> T-Code SE16N. You will find that custom fields are appended to the CDS view C_MATERIALOVERDUEGRBLOCKED.

3.3 Go to SAP GUI -> T-Code SEGW. You will find that custom fields are appended to the CDS view in OData service.

4. Navigate to SAP Fiori Launchpad :

4.1 Navigate to Fiori App from T-Code /UI2/FLPTE_ALL

4.2 Choose Settings.

4.3 Select the fields that you have added.

4.4 Choose Adapt Filters.

4.5 Select the fields that you have added.

4.6 You will find the fields you have added.

Conclusion:

At the end, I hope this blog was helpful, uncomplicated, and clearly detailed for the entire process of adding custom fields in standard Fiori apps. In the upcoming blogs, we will delve into adding custom fields in more complex Fiori apps that require extending standard OData services, such as ( Stock – Multiple Materials, Monitor Purchase Order Items, etc.)

The post Adding Custom Fields to Standard Fiori App of S/4HANA appeared first on ERP Q&A.

Identifying the changes present between different versions of workflow templates can be a challenge. Unlike other objects, there isn’t a built-in functionality for direct comparison. Manually scrutinizing each step of the templates side-by-side can be both tedious and error-prone.

This lack can be frustrating, as I’ve witnessed firsthand through inquiries from few of my colleagues struggling to identify changes between versions for troubleshooting or maintaining consistency across environments. Fortunately, I’ve been able to help them by employing a couple of effective techniques that help bridging this gap.

While there are few solutions available online, I haven’t encountered a comprehensive resource specifically dedicated to guiding users through this process. Therefore, I’m writing this post with the hope of empowering you with effective method for comparing workflow template versions in SAP. Additionally, it serves as a future resource for my colleagues whenever they encounter similar challenges, allowing me to simply direct them to this guide.

Comparing Workflow Templates

Gearing Up:

• For this post, I’ll be using two workflow templates which are nearly identical, except for a few differences which I have deliberately introduced in order to demonstrate the process.
• We are going to need a text editor which supports two key functionalities: “Find” feature using regular expressions, as well as has feature to compare two text files (diff tool). I will be using Visual Studio Code for this as it offers both features seamlessly.
• We will be comparing the two workflow templates by exporting the templates as XML file and comparing the exported files in Visual Studio code. However, there’s a catch. By default, these exported files may be compressed and lack proper formatting, making it difficult to see any changes. To address this, we’ll need to format the XML files using the “XML Tools” extension within VS Code. This extension transforms the raw XML into a human-readable format, allowing us to easily identify any modifications/differences when comparing the files using the built-in diff tool.

Now that we’ve got our list of tools prepared, let’s explore the steps to identify differences in two workflow templates.

Step 1. Export the templates as XML file.

In this step, we will open both templates in Workflow Builder (SWDD) and export the templates as XML file. The menu option to export the files can be found at Menu > Workflow > Import/Export > Export to XML File > Export Workflow as Internal XML

Step 2. Open exported files in Visual Studio Code

In this Step, we will move the two exported files to a separate folder named “Compare” and open this folder in Visual Studio Code. To open the folder in Visual Studio Code, File > Open Folder command can be used from the menu bar.

Step 3. Formatting the XML files

It can be seen that the exported XML files are compressed and do not contain proper indentation. We will need “XML tool” extension to convert these XML files to readable format so that the changes are easily visible when compared.

The “XML tools” extension can be installed in Visual Studio code by following these simple steps:

• Navigate to View menu.
  
• Select Extensions
  
• Search for “XML Tools” in the search bar
  
• Click the install button.

Once the “XML Tools” extension is installed, go back to the XML files, right click on the XML code, and choose Format Document With > XML Tools. Do this for both XML files.

After formatting, the files will be transformed into a more readable format, similar to the files in following screenshot.

Step 4. Comparing the two files

In this step we will finally compare the differences between two XML files. To compare two files, right click on first file and chose “Select for Compare”, then right click on the second file and choose “Compare with Selected”.

The difference checker tool should now open in the main panel of Visual Studio code, and the differences between two files should be highlighted in Red and Green. An overview of all changes present throughout the whole file can also be seen at the right-hand side present in a panel called mini-map (highlighted in below screenshot). This mini-map offers a quick glimpse at all modifications throughout the files and facilitates scrolling when clicked on the highlighted part on minimap.

As can be seen in the mini-map every difference present in two XML files is highlighted. However, the changes including workflow IDs, version numbers, and timestamps have also been highlighted. These differences aren’t relevant to our goal. These irrelevant differences are creating noise in the difference checker tool, making it harder to identify the actual changes we’re interested in. To address this, we’ll strategically remove these irrelevant differences from both files, ensuring only the significant modifications remain highlighted.

To eliminate these irrelevant differences, we will leverage the Regular expressions powered “find” feature of Visual studio code.

Let’s begin by addressing the discrepancies caused by different workflow IDs within the two XML files. Press Ctrl+F to open find feature, enter the workflow ID in the find box and replace all occurrences of workflow ID with an empty string. Do this for both files.

In my case, removing the workflow IDs significantly reduced irrelevant highlights, however, the differences in “Changed Date” and “Changed Time” were still creating noise (highlighted below). To achieve a cleaner comparison, let’s eliminate these discrepancies as well.

Removing individual <CHANGED_ON>, <CHANGED_AT>and similar tags would not be efficient due to their multiple occurrences with different enclosed timestamp within each XML file. Simple find and replace operation would not help because the timestamp enclosed within tags are different in same XML file. Instead, we’ll utilize a regular expression to target all such tags effectively.

Here’s how to proceed:

• In the Find input box, enter the following regular expression: <(CHANGED|ACTIVAT)_(ON|BY|AT)>[^<>]+
  
• Enable the “Use Regular Expression” option (highlighted in screenshot below)
  
• Replace all matched occurrences with and empty string in both XML files.

The above regular expression effectively targets all occurrences of Changed/Activated on/at/by tags and replaces those with empty string.

While much of the noise was removed after performing above step, examining the mini-map revealed additional noise in the form of <VCYPOS>, <VCXPOS>, <LCXPOS>, and <LCYPOS> tags (can be seen in below screenshot). My understanding of these tags is that they represent the X and Y coordinates of object/node positions within the workflow. As we’re not interested in these changes, we can eliminate them from both XML files as well.

To achieve this, we will use <(LC|VC)(X|Y)POS>\d+ Regular expression. Enter this regular expression in the “find” box and replace all matched occurrences with empty string in both XML files.

Finally, with all the irrelevant differences eliminated, the comparison tool now displays only the four key changes within the XML files that we were originally looking for.

With the help of highlighted differences, I found the following changes that were made in workflow template:

1. The template name was changed from ZTICKET1 to ZTICKET2 (Line 6).
   
2. The description of the template was changed from “Example workflow for Ticket system (V1)” to “Example workflow for Ticket system (V2)”. This can be noted in line 7.
   
3. The Object ID, similar to the workflow template ID, differs between the files. This is expected and is irrelevant to our analysis. We could’ve removed it during the de-noising process if it had numerous occurrences.
   
4. Further down the file (line 1118, as indicated by the mini-map), I encounter another important change.

This modification suggests that the Expression binding of node 50 has been changed from &_WF_INITIATOR& to &AGENT& which is indeed correct and can be confirmed from below image

Conclusion:

By following these steps, I was able to identify the exact changes that were made in the workflow template. This approach streamlined the process and ensured accurate identification of modifications made between different versions/templates of workflow.

The post Comparing Workflow Templates in SAP appeared first on ERP Q&A.