ABAP Cloud - Date Functions

Table of contents

• Introduction
• Core Data Service
• Weekday
• Open Source
• Architecture
• Methods
• Performance
• Usage
• Testing
• Conclusion

In this article, we'll look at the new Core Data Service for date functions and why you no longer need function blocks.

 

Introduction

Date functions are an important part of software development, especially in finance or where various data needs to be calculated. In the past, function modules were primarily used to determine the last day of a month or, for example, to check which quarter you were currently in. Functions were also needed to determine whether a date fell on a Monday or a weekend. With ABAP Cloud, function modules became obsolete, but currently there is no released class with which these various functions can be executed and called.

 

Core Data Service

SAP now provides a Core Data Service that contains some of these functions. This is the view "I_CalendarDate", which we can find and execute in the system and which returns the corresponding calculated values for various dates. The various dates are not calculated at runtime, but read from the database. This means that all values have already been precalculated and persisted. The values from January 1, 1900 to December 31, 9999 are available, so the most common ranges should be covered.

 

Looking at the preview, we see the different fields. The day or calendar day is the key field, and we get a breakdown of the various pieces of information such as the year, quarter, month, week, and other combined information that depends on the date. This allows us to derive various date information using a SELECT statement on the Core Data Service.

 

There is also more complex information, such as the first day of a week, the day of the week, or the calendar day within the year. There are handy columns for this that you can read when you need them. Information like the year or month can also be derived from the date using substring functions.

 

Weekday

Here, however, the first small differences become apparent when we look at the details. For example, in the ABAP standard, the day of the week is numbered from 1 to 6, with Sunday being 0, as in the typical American calendar. This is represented in the system field SY-FDAYW. In contrast, the Core Data Service counts the day from 1 to 7, meaning Sunday is 7 and Monday is 1. Therefore, the two values cannot be directly compared; a mapping is required. of Sunday, depending on which field we reference.

 

Open Source

To this end, we have extended our project for the System fields to provide various date functions as standard, in addition to the actual system fields. Here, we also include the link to the days of the week, as this was already a method. We can now replace this with the new standard.

 

Architecture

As always, we want to build our class architecture to be testable and therefore create a factory and an injector to make the logic testable later. We handle all functions in a single instance to ensure reusability and implement an interface for this purpose.

 

Methods

We provide a corresponding interface and some structures and methods that we intend to use later. These are primarily the complex calculation methods that cannot be easily derived from the date or for which we already have XCO classes. For example, for the first and last day of the month. Similarly, for the week: the standard does not provide a method for this, so we calculate the last day of the week ourselves. The quarter, week, and day of the week are also part of the functions that we expose. Additionally, we have a GET_RAW_DATE method to return the complete data set if needed.

 

Performance

We tried to optimize performance by buffering the data set directly in the class after reading it, thus allowing us to perform different actions on the same date without having to read it again. Additionally, one date can be persisted per class instance, meaning that each instance represents exactly one date on which we can perform different operations. Creation is done via the factory or, for the current day, via the system fields.

 

Usage

If we want to use the object, we can currently choose between two different options: In the first step, we can go through the system fields and have the date functions returned to us. From these, we can then derive, for example, the day of the week. In another version, we can also chain everything together, retrieve the date functions via the system object, derive the day of the week from them, and assign a field to it.

" Via object 
DATA(today) = sy->date_functions( ).
DATA(weekday) = today->get_weekday( ).

" Chained
DATA(weekday_new) = sy->date_functions( )->get_weekday( ).

 

As a second option, we naturally have the Factory at our disposal. Using the Factory, we can create a new instance for a corresponding date; in this case, we take the system date minus 1, i.e., yesterday. We can then also execute a method on this object. This allows us to work with the system fields, but also to use the object directly if, for example, we need a different date as a reference.

DATA(yesterday) = zcl_date_factory=>create_date( CONV #( sy->system_date( ) - 1 ) ).
DATA(last_day_of_week) = yesterday->get_last_day_of_week( ).

 

Testing

To create the tests for the open-source project, we didn't perform manual tests in this case, but instead ran an ABAP agent on the code. We used Agentic AI via VS Code to generate unit tests for our class. Basically, we checked the results once after generation. It's noticeable that we map multiple test cases per test method, which doesn't correspond to best practice for ABAP units. Here, we could, in principle, tell the agent to split the methods, but this would generate correspondingly long test code.

 

The example for the date functions, however, can be used very well to generate automated unit tests. Overall, the agent generated data for various use cases and edge cases. It also applied different calculation methods for the calendar week, for example, which are defined according to ISO standards, to determine the correct calendar week. The comments and messages are also helpful for understanding the test cases more easily.

 

Conclusion

Various date functions are no longer located in function blocks to perform the determination, but can be read directly from a Core Data Service. Alternatively, for better handling, you can also create your own logic to use and read from the Core Data Service. The information about the Core Data Service can help you get the correct date without much effort and calculation.

 

Further information:
GitHub - System Fields