There are already blogs in SCN which introduce how to implement a custom check in ABAP code inspector or ATC check. For example this blog Code Inspector – How to create a new check from Peter Inotai.

Recently for training purpose I need to demo a custom syntax check directly performed in SAP GUI by hotkey Ctrl+F2.
Let’s first have a look what could be achieved:
Open a method in Class builder and click syntax check icon or press Ctrl+F2:
Then my custom syntax check is triggered and warning message is raised within class builder, if the total lines of the current method has exceeded a hard-coded threshold say 100. I feel this way of custom syntax check more convenient compared with custom Code inspector check or ATC check which will display check result in a separate window.
The custom syntax check against total number of source code lines in this example does not make too much sense, in the future I will provide another meaningful example.


Only works in Form-based class builder, no test is done in ABAP in Eclipse yet. ( I still use SAPGUI in my daily work )
Some prerequisite knowledge before custom syntax check implementation
The example in this blog is built on the Netweaver with version below:
We application developer might consider it is a natural part that our operations ( for example double click a method in class builder, double click a table field in ABAP Dictionary ) in SAPGUI is responded, however the processing under the hood is far more complex than our imagination.
Consider the following sequence diagram when you double click a class method in class builder:
Every operation in ABAP workbench issued by end user is encapsulated by an instance of class CL_WB_REQUEST containing all detail information about the give operation for example the object type and name of clicked object( class method, transparent table or any other repository object ), together with operation type.
Different operation type has different kind of handler class to serve the request, which are centrally maintained in table WBREGISTRY. The content of this table is exposed by class CL_WB_REGISTRY.
The class CL_WB_MANAGER works as a mediator which communites with these tools in a uniform way via instances of CL_WB_REQUEST.
Sometimes the handler logic operation is so complex that the corresponding handler class for it could not simply be determined by looking up static table WBREGISTRY. In this case the additional determination logic could be written by code via implementation of interface IF_WB_DECISION_CLASS.

Step by step to implement custom syntax check

Step1. Create a new class ZCL_WB_CLEDITOR by inheriting from standard class ZCL_WB_CLEDITOR. The complete source code could be found from here.
The main logic is done in the redefinition of method CHECK_METHOD_SOURCE. First the standard check logic in super class is done, if syntax error is found, display them to end user and skip my custom syntax check, otherwise perform custom syntax check in line 14.
You wonder why CL_WB_CLEDITOR should be inherited? Well I just know from debugging that when syntax check icon or Ctrl+F2 is pressed, this class is called:
Step2. Create a new class ZCL_OO_METHOD_REQ_DISPATCHER by copying from standard class CL_OO_METHOD_REQ_DISPATCHER.
Create a new post exit on method GET_TOOL_FOR_REQUEST:
The implementation is simple:
1. You can directly enhance standard class CL_OO_METHOD_REQ_DISPATCHER. I do not prefer this way since it is a standard class, although the enhancement is not actual modification on that standard class, by copying a new Z class from it and playing round with Z class, I can prevent my system admin from being too nervous…
2. You can directly modify source code of method GET_TOOL_FOR_REQUEST if you copy a new class. However it is the most convenient approach to simply replace all determination result of CL_WB_CLEDITOR with ZCL_WB_CLEDITOR in post exit.
3. If you choose to copy a new class ZCL_OO_METHOD_REQ_DISPATCHER, do not forget to replace the value in column TOOL from CL_OO_METHOD_REQ_DISPATCHER to ZCL_OO_METHOD_REQ_DISPATCHER. Once done, it should look like below:
Step3. Be default for performance reason the tool registration is stored in share memory instead of database table. As a result in order to make your changes take effect, you could declare the following user parameter explicitly:
I know this parameter by debugging this method:
So far all steps are done. Now you can test in Class builder with form builder mode. If you would like to achieve custom syntax check in SE38 instead, you could use the same idea ( find corresponding handler class for SE38 via debugging ) described in this blog.

Update on 2017-04-15

I have provided a real example to simulate Covariance syntax check in ABAP: Covariance in Java and simulation in ABAP.
To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Joachim Rees

    Hey Jerry,

    I would like to do kind of the opposite of what you describe here:


    Instead of creating my own custom syntax check, I would like to (in a well-defined case) “switch of” a SAP Standard Syntax-Check.

    (The one that always creates warnings about “the database feature “TABLE_LEN_MAX1”, which IMO is not justified in an “S/4HANA only-Landscape”; see also )


    Do you have an Idea for that as well?




      1. Joachim Rees

        Hey Jerry,

        Peters proposal( [Note: I see no way directly linking to an answer, so I’m linking to the first comment on that answer)   is only on how the behavior of SCI-Checks could be changed – this wouldn’t affect the “Standard Syntax Check” that’s used in SE80! -> and this is, where my problem is.


        So, no, I haven’t tried that yet, as it won’t solve my Problem.


        That’s why I jump onto you blog when I read that you know how to fiddle around with the SE80 syntax-check! 🙂




  2. Sandra Rossi

    You may also reload the tool registration by invalidating the instance(s) of Shared Memory Area CL_WB_REGISTRY_SHM_AREA in transaction SHMM (not sure for 7.50).



Leave a Reply