For my purposes here, I made use of an existing BAdI implementation that I created previously using the Custom Logic application available within the SAP Fiori Launchpad for my SAP S/4Hana Cloud instance. I entered a search text of 'Order Operation', which resulted in my implementation being displayed in the list. I was then able to hover over that entry so that the technical implementation name is displayed as a tooltip.
Another way that I could have found this information would have been to make use of the personalization available for this list, by clicking on the gear icon.
Within the popup that is opened, I selected the 'Implementation ID' entry so that it would also be included in the list.
Now that this value was displayed in the list, I was able to easily select and copy it to my clipboard.
Within my local ADT (which already had my SAP S/4Hana system displayed as a project in the Project Explorer and which was already connected), I then chose to perform a Search operation in order to find my implementation.
The search results were then displayed, which showed both the implementation as well as the implementing class.
By double-clicking on the object name, the implementation was then opened and displayed in my editor.
I was then able to click on the 'Implementing Class' link to have the class be opened in the editor.
Once I scrolled down a little, I was able to see where my custom logic was located (i.e. between the 'payload' comments).
After deciding the point in my custom logic where I wanted the debugger to stop, I double-clicked on left-hand-side of that line of code (within the blue-shaded area) in order to set a breakpoint, which is then indicated with the blue dot.
In my case, I knew that my breakpoint was going to fall within a loop, but I did not want to have it stop repeatedly. So I wanted to make this breakpoint be conditional, so that it would only stop when the condition that I provided was actually met. I right-clicked on the breakpoint in order to invoke its context menu, which gave me several options. The one that I needed was for the 'Breakpoint Properties...'.
The condition that I wanted to put in place was to only stop for the first entry in the loop.
The conditional breakpoint was then saved and was visibly identifiable as a blue dot with a curly tail underneath.
At this point, I only needed to productively make use of an SAP Fiori application that enabled the use of the custom logic (i.e. that called the BAdI implementation) on my SAP S/4Hana Cloud system. In my case, my custom logic was invoked by my opening an order for editing using the Change Production Order application. The SAP Fiori application will then be left in a waiting state until the breakpoint is handled in someway.
Generally speaking, if a breakpoint was encountered, then the ADT would be activated and come into focus (in my own case, the ADT was highlighted in my Windows Taskbar, so I opened that window).
Because I had the ABAP Perspective open, it prompted me to indicate how I wanted the ADT to proceed with respect to whether it should switch to the Debug Perspective. I chose to switch perspective.
The ADT then displayed the debugger and indicated the current line at which it had stopped the execution, and provided a list of all variables currently in memory, as well as the call/execution stack trace. I was interested to see what the values were for the MFGORDEROPERATIONS_CHANGED internal table, so I expanded that information within the Variables display.
Once I was ready to have the execution continue, I then clicked on the Resume button.
There was more than one entry to be processed in the loop within the custom logic, but because of my breakpoint's condition, the debugger never again stopped, as expected. The processing within my SAP Fiori application resumed and completed successfully. The processing in the ADT then terminated.
Since I wanted to keep the implementing class for future reference, I made use of the 'Add to Favorite Objects' feature available in ADT, but right-clicking on the object displayed in the Search results list.
Because I wanted to make use of the ABAP Trace functionality in the ADT, I needed to switch to the ABAP Profiling Perspective to easily see the relevant views.
I switched to the ABAP Trace Requests view, and right-clicked on the tenant to open the context menu, so that I could choose the 'Create Trace Request...' option.
The trace request popup was then opened, which allowed me to define some of the general aspects required for the tracing, such as what request types are to be traced for what user and what title should be used for the trace files. I chose to trace all HTTP requests for my own user, and to use the title 'MyFirstTraceFile'. I then clicked on the Next button in order to see the remaining configuration options available.
Although I had chosen to leave the default option in place, so that HTTP requests would be traced, there actually does exist more options than just that one.
The trace parameters were then displayed. I chose to leave most of them as they were, although I did choose to use the Custom Statements option so that I could select all of the areas that I was interested in seeing traced. By clicking on the Finish button, the tracing is started.
After I clicked on the Refresh icon, I could then see that my trace request had been created and that the tracing had started.
Back within ADT, I switched to the ABAP Traces view and clicked on the Refresh icon again, and the list of trace files was updated and showed the results.
I double-clicked on the latest entry and the Overview page was opened. Within it I was able to see some high-level information, as well as being able to navigate to more detailed information.
I chose to view the Hit List results and to filter them (using the prefix for my implementing class). This gave me some further details on the execution of my custom logic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
7 | |
5 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 | |
2 |