如何实现SAP GUI的自定义语法检查(Syntax check)

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.

Limitations

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 tableWBREGISTRY. 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 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:

Note:

(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.