ABAP - XCO Libraries

Table of contents

• Introduction
• Structure
• Organization
• Fluent Interface
• Value
• Error handling
• Objects
• Overview
• Conclusion

In this article we will look at the library in general, how it is integrated and what other methods and ideas are behind it.

 

Introduction

SAP provides the so-called XCO (Extension Components) libraries, which can be used in classic ABAP as well as in ABAP Cloud. You can find the objects in your system based on their names. The classes begin with XCO*, and can then be followed by abbreviations such as CP (Cloud Platform) or KU (Key User Tools), which then further restrict the scenario. You can find an overview in the official documentation here.

In ABAP Cloud, the use of released APIs is becoming increasingly important, so a uniform understanding and uniformly used components are important. Which API you use for which use case should therefore become clearer in the future.

 

Structure

If you would like to get an overview of the different classes and the structure, you can display a new tree using the ABAP Development Tools in the Project Explorer. To do this, you can create a new tree using the context menu on the system.

 

In this case, we display the released objects. To do this, we restrict the names to XCO_* and we can remove the Object Type Group.

 

After the tree has been created, we can find the objects classified by ABAP Cloud and Key User Extensibility in the Project Explorer. All usable classes should now be there. Basically, it depends on the backend release how many classes are available to you and whether all methods are available.

 

Organization

In this section we will look at the design and structure of the classes and how you can best use them.

 

Fluent Interface

The classes are developed in the Fluent Interface Pattern, which means you can chain the various calls and objects together. Each method usually returns a new or the same object, so the calls can be chained together. The following example shows this:

DATA(ld_string) = `This is my new text string`.
xco_cp=>string( ld_string )->to_upper_case( )->append( ` with addition` )->split( ` ` )->value.

 

In this example, we create a new String object using the String class, convert the string to uppercase, append another part and split the string at the space. We then output the result at the end.

 

In addition to the Fluent Interface Pattern, there are also corresponding interfaces for all objects, which makes testability and mocking easier. You will also find local unit tests for many classes.

 

Value

As you have already seen in the example above, there are various methods available that each class has. To access the contents of the object, you use the VALUE attribute. Depending on the class, this can be a value, a table or an object.

xco_cp=>string( ld_string )->value.

 

Error handling

All classes are equipped with NO_CHECK. This means that you will not find any exceptions in the signature and therefore do not have to worry about exception handling. However, exceptions can be created that are of type CX_XCO_RUNTIME_EXCEPTION or exceptions that inherit from this class. For more information, see the core principles of the classes.

 

Objects

The objects are instantiated directly when called and even the various settings and configurations are available as objects in the main class. If you look for the interface and usage, you can quickly end up in a dead end. Let's take a look at the XCO_CP_JSON class, for example, and how we pass the correct formatting. To do this, we need to call the APPLY method to pass a table with instances of type IF_XCO_JSON_TRANSFORMATION.

 

Normally, we would now look at the "Type Hierarchy" (F4) to the interface to use the classes for creation. 

 

But if we now look at the class, it is set to PRIVATE and we cannot create an object from it.

 

If we then look at the global friend of the class, the instances are created in the constructor of the factory class.

 

Using the interface of the factory IF_XCO_JSON_TRANSFORMATION_FCT we then find the public attributes that we should actually use here. Therefore, it is worth taking a look at the main objects of the classes when it comes to configuration and additional settings.

 

Overview

We want to give you a general overview of the various libraries on our overview page and fill the page with further examples and classes over time. This will give you an easier overview of what is available and how you can use it.

 

Conclusion

The XCO classes are collected requests from the community and are intended to provide central functions for reuse. This should eliminate the need to search for the right function in the vastness of the classes and function modules.