047: ABAP - ADT for VS Code (Part 3)

Table of contents

• Steps
• Copilot
• MCP
• Agent
• Example - Roman Numbers
• Outlook

In the last few episodes, we looked at VS Code and how you can call the various functions for ABAP development. We went through the editor step by step and examined the different features. A major point, however, is that Agentic AI is now very easy to implement and possible in code over a large portion of the time. Therefore, in this episode, we'll look at Agentic AI with a focus on ABAP development and which features you can already use today.

 

Steps

Agentic AI essentially describes how a generative Large Language model iteratively works on a problem. There's a so-called agent, which we define and which has certain properties and skills. This agent then processes the problem or the actual prompt and implements it in the system. This can create an agent loop: If, for example, the goal isn't reached, the agent continues working until, for example, errors are fixed and the code can be activated.

For configuration in VS Code, we use Copilot. You have two options: Either you activate your GitHub account and log in with it, or you use an API key, for example, if you've subscribed to a Large Language Model such as Gemini or Claude. Next, we need to activate further tools, in this case, the built-in MCP server in ABAP. We activate this and then integrate it into Copilot so that the tools are used. In the third step, we define the actual agent, our ABAP developer, who will later carry out the development and receive certain guidelines from us. In the last step, we could add custom instructions, which are additional work instructions that we can then assign to a prompt. However, this step is optional for now, and we won't be performing it in this video.

 

Copilot

We naturally want to look at the next steps live in the system, so we'll switch back to our editor to configure it. At the top, you'll find the sidebar, which we can open to see the built-in chat. In the chat, you have various settings options at the top to create new chats, adjust settings, update, or change the width. In the lower section, you'll find the input window. For our agent, or rather, our ABAP developer: If we click on "Models," we see that we currently have no models available. However, we can log in to Copilot to load them. You'll find the Copilot icon in the lower section, and you can then choose how you want to log in, either via GitHub, Google, Apple (for example), or other authentication methods.

After authenticating in the browser, we'll find further settings behind the GitHub Copilot icon. For example, we can see our used credits, and we can also disable inline suggestions here. These suggestions that Copilot makes while we're working in the editor also have disadvantages: When we're working in an empty class, we sometimes get suggestions that are completely irrelevant to our actual project and our actual class. Therefore, for the sake of simplicity, we'll disable the ghost text. If you now go to the model selection in the chat window, you'll find the available models offered via GitHub Copilot. Here, we select Claude 4.6 Sonnet, as this model is perfectly adequate for generating ABAP code with good context. Behind the model, you have further configuration options to increase the model's effectiveness or save costs, for example, by reducing context performance.

 

MCP

An important component for the good performance of an agent and for enriching information is an MCP server. This server is now delivered with the ABAP Development Tools and runs directly on the Language Server, as we already discussed in theory. Currently, however, this server is delivered inactive, and we must first activate it via the settings. To do this, we switch to the settings, for example, using Ctrl + Comma, and can then navigate to the Extensions section. There you will find the ABAP Development Tools. Open them and scroll all the way down to find the settings for the MCP server. Before activating the MCP server, you can also set the port if you want to choose a different port on your device. After starting the MCP service, a corresponding message will appear in VS Code indicating that the server is now starting up. You might otherwise receive error messages if there are problems during activation.

Let's now switch back to the Copilot chat. Here, behind the selected model, we find the option to configure the tools. We click the button and get an overview of all the tools in our editor. This setting defines the tools that our agent is allowed to use later. Tools such as file editing and workspace search are already enabled here. The ADT-MCP server is located in the lower section. Here, you should ensure that all tools you intend to use are enabled. For simplicity, we'll enable all available tools. You could also disable write tools or tools that create data in the system if you only want to use read-only mode.

 

Agent

The final configuration step is creating the actual agent that will support ABAP development. You'll find another option for this in the Copilot chat, this time on the left side of the model, where the agent mode or the agent mode icon is also active. Basically, you can create different agents, each with a different context and different instructions. For example, you could create a review agent that performs code reviews for you to ensure a certain code quality before you then pass the review on to your colleagues. We create a new agent in the system using the "Custom Agent" button. To do this, click on "Create New Agent" to start the wizard. Next, we need to define the storage location. Here, for example, we have the option of storing it in the current workspace, or we can also store it globally in the Copilot area so that the agent is available globally. In this case, we ensure that the agent is available for the Copilot and select the directory. Now we give the agent a name. This name is stored in the file but will also be displayed later when the agent is selected. A Markdown file is then created, which we can now enrich with our instructions. Basically, an agent consists only of descriptions that describe the actual tools and which rules it should follow, no great magic involved.

If you need to configure the agent initially, you can find further information in the SAP documentation. A test file with initial instructions is already defined here. You can copy this and then paste it into your agent. Later, the plan is to automatically include an agent.md file with the plugin initially, which you can use to configure a first standard agent. We will now insert our own agent file. In the upper section, you will see some configuration options such as the agent's name, a brief description of what the agent actually does, and various tools that will be available to the agent later. In the lower section, you will find information partly from the template and partly already added – so first, general information, and further down, instructions on testing. Since we have additional requirements, we will also include the topic of quality. For example, Hungarian notations should not be used, meaning no variable prefixes. Comments should only be used when necessary. The agent should adhere to the Clean ABAP Guidelines and use descriptive names for variables, thus fulfilling certain qualities that we want in our code. Finally, save the file and you're finished configuring the agent. The agent is now available and can be selected so that it's considered in the next chat.

 

Example - Roman Numbers

In the next example, we want to create a class from scratch that doesn't yet exist in the system. This means we start with our actual prompt and state that we need a class, which should also be stored in a specific package. We don't specify the name of the class yet. In terms of content, we say that Roman numerals should be converted to Arabic numerals. And we also need unit tests to validate that the logic works, and the various edge cases should also be tested.

The LLM now begins working and first creates a to-do list for us. This means we can already see what the agent wants to do in the next steps. We can expand this to-do list and see, for example, that it first wants to retrieve the list of destinations, since we haven't specified on which system the implementation should take place. Next, it would create the class, then add various unit tests, and finally attempt to activate the class. Activation is important because we then determine whether there are any errors in the class, which is quite possible. The LLM then receives the relevant information and can correct the errors.

In the upper section, the agent is already requesting the necessary permissions. We have to manually approve certain tool calls here because these are our default settings. You can find these default settings in the lower section and, for example, configure them so that all tools are accepted automatically. In this case, however, we want to maintain some control and examine the various calls. The first call is directly from the MCP server, and it's currently attempting to retrieve the available destinations. This means it wants to get an overview of which systems are available and which system it should actually be working on. In the next step, the Large Language Model first validates the corresponding class name against the destination it found, i.e., whether this class already exists in the system. We also accept this tool request. The context tells us what it's actually trying to do; in this case, it's checking the package to see if the corresponding class exists. The next request is then whether it's allowed to create the class. This means we say "accept" so that the class is created on the system. Which is what it now does. On the other hand, we can then refresh the workspace and see that the class already exists in the system. However, it is still empty. The agent has initially created the empty implementation and assigned it a suitable name. The agent is now beginning the actual implementation process. This means that in the chat, we can see what the agent is considering, which implementation it wants to create, what edge cases exist, and what else it should take into account. This is fundamentally interesting for understanding how iteratively the agent proceeds and what things it looks at and needs to consider. Currently, we don't yet have any changes in the system; this is the actual thought process running in the background.

The agent has now made initial changes to the class. We can see these very clearly: Firstly, the class is now populated with the first information. On the left, we see all modified objects or includes that have already been changed, and below the to-do list, we also see that files have changed. Here is the opportunity to confirm or undo changes, otherwise the agent will simply continue. We can view the changes by clicking on the file, and in the callout, we see the modified lines, which we can then confirm with "Keep" or undo with "Undo". You should invest some time in the review process here and look at what has actually been generated and whether it meets your requirements. The agent has implemented three methods: one for the actual conversion logic, one for validating the content, and another to retrieve the configuration of the various symbols. We can now click on the file and see that we land in the unit tests. Here, the agent has already built a fairly large number of unit tests. We also keep these with "Keep".

Finally, we confirm that the class should be activated. Copilot then activates the entire class accordingly. If there are still errors, as in this case, it makes further adjustments to the logic. If the activation was successful, Copilot now wants to start the final unit tests to check if the result is correct. Finally, we get an overview of what has happened: all unit tests have run, various edge cases have been tested, and the logic has been implemented. The actual agent loop is now complete, and we can view the result in the system. Our task now would be to validate that best practices are being followed. We can then, for example, either make adjustments ourselves or give the agent further instructions to modify certain code components with which we might not yet be satisfied.

 

Outlook

The agent has now been set up in the system, and its first class has been implemented. Therefore, the configuration must be carried out cleanly so that a corresponding Large Language Model is available and we can also provide the agent with context. The agent should, of course, know what kind of agent it is and what its capabilities are, which we implemented with "agent.md". In the next episode, we'll look at further examples from the area of unit testing and examine RAP development. After that, we'll go through the remaining episodes and conclude the presentation. So, thank you so much for watching and for your interest... and see you next time.

 

YouTube
Video