Script: OData Batch Creator [007]

Introduction

Welcome to the current episode. This episode is about the OData batch Creator, a tool we wrote ourselves. Before we get into the tool, however, let's take another look at the API pattern for Rap. The RAP pattern involves providing an endpoint that can receive data. The object is very simply structured. We have a service and a custom entity, which acts as a structure. We build a behavior for it that routes the data through the RAP framework, allowing us to process the data flexibly. Within the RAP framework, we use the CREATE, CHECK_BEFORE_SAVE, and SAVE methods. To pass the data from the Create method, we use a local buffer within the class.

Let's take a look at the implementation in the ABAP Development Tools. We've already integrated the package into our structure for this. To do this, we first open the custom entity and look at the structure. Here you'll find four fields that reflect our data. Next, we go to the behavior implementation, where we look at the CREATE method. In the Create method, we simply transfer the data to the buffer; this method has no other tasks. In the CHECK_BEFORE_SAVE method, we have the option to retrieve the data from the buffer and check it. If we find errors or the data is incomplete, we can reject the records, and these are returned to the caller as errors. The last method is the SAVE method, which is only responsible for passing the data for further processing.

You can find the article in the video description for further details on how the RAP pattern works.

Metadata

In the next step, we need the service's metadata. For this, we use the online version of the Postman tool. We've already prepared a query here; this is a GET query. Behind the service, you'll find $metadata; otherwise, there's nothing else to consider except that we need to log in to the service. The login and URL are already assigned in the background. We can copy the contents of the result using the button and save it in a new XML file.

OData Batch Creator

You can find the tool on our website in the menu under SAP. The tool is currently still in beta status. The first step is to load the file to provide all possible information from the service. After loading, we can define new actions—these are the various actions we want to assign to the batch request. We define a total of three actions to create three new data sets. We then load the data into the display using the Refresh button. There we see the extension for the URL, the new content we need, and the payload, which we now need to adjust. Finally, we adjust the individual data sets. The location ID must begin with an "L"; you can use a free number here. We use a place as the location name, and to simplify things, we use a random direction for the coordinates. We also define the population number randomly to obtain some test data. Finally, we copy the content type and the payload.

Test

Finally, we begin the actual test. To do this, we copy the payload into the body of our query and the content type into the header fields. The content type is important because it contains the unique batch ID. It is important that we have a $batch at the end of the URL.

In the next step, we need an X-CSRF token, which we retrieve via a simple GET query. To do this, we must include a FETCH in the header fields. Once we have executed the query, we find the corresponding token in the response header, which we can then use in our batch request.

We then copy the token and paste it into the header of our batch request. Make sure that it does not contain any special characters or blank lines. Before we send the query, we set a breakpoint in our SAVE method. It is important to set the breakpoint to the external user with which we log in to the system. Once we execute the query, the debugger starts and we are in the SAVE method. There we can then check the entries we received. The data corresponds to the configured data of the request.

Finally, we run the debugger and save the result. If we then go back to Postman, we can check the result by looking at the response. There we find a separate response for each data record, which should have the status 201.

Conclusion

The API pattern is a special pattern for endpoints in which we primarily reuse the RAP framework. This allows us to easily implement endpoints in the system and make further processing very flexible. With the OData Batch Creator, we can then easily test this endpoint and simulate mass processing. If you would like more information about the tool, please visit our website.

Thanks for watching, and see you then.

YouTube
Video