Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at [email protected].
The Controls Technology Framework,Automation Controller, and Automation Queue
In this months blog I will continue to take a look at the SAP Controls Technology and how we can use it in our development.
There is constant communication passed between controls on the SAP GUI and the application that resides on the application server. The SAP Controls Technology Framework and the Automation Controller are the vehicles by which these communications take place.
The Controls Technology Framework resides on the application server (the back-end), and the Automation Controller sits on the presentation server (the front-end). The integral component that optimizes the communication between the two is the Automation Queue.
Let’s take a closer look at the benefits this architecture offers by examining how the SAP Controls Technology Framework enables integration and use of your controls through ABAP OO methods, and how the Automation Queue provides a
buffer to the Automation Controller to help avoid decreased system performance.
The SAP Controls Technology Framework ABAP OO Methods
The Controls Technology Framework supports all the controls that are implemented within the SAP GUI. It encapsulates all available controls in global wrapper classes of ABAP Objects, and even maintains a list of the control instances you have created. To work with controls on your screen, you simply create objects of these wrapper classes, call their methods, and react on their events.Therefore, when integrating a control into your program, you are actually just calling delivered methods of the Controls Technology Framework.
The controls at the front-end are utilized by using the methods of the Controls Technology Framework classes CL_GUI_CFW, CL_GUI_OBJECT, and CL_GUI_CONTROL.
The SAP Controls Technology Framework offers you classes for:
– Creating, initializing, and positioning controls to be displayed on the front-end or Presentation Layer
– Making a control visible or invisible
– Checking whether a control is still active or has been destroyed
– Querying a control to retrieve information regarding its height or width
– Enabling the possibility to implement user interaction in the program by using events (examples of events are click, double-click, drag and drop, and so on)
– Buffering control methods in a queue and transferring them to the front-end for execution
– Destroying controls at the front-end and freeing the memory they occupy
Lets take a closer look at each of these classes in turn…
The CL_GUI_CFW Class
The CL_GUI_CFW class contains only static methods, which apply collectively to all the controls that exist at the front-end. The two most commonly used methods are dispatch and flush:
The dispatch method
In the case of certain events (application events) the event handler method is not called before the PAI (Process After Input) event. If you wish to call the event handler within the PAI event, the dispatch method is used:
CALL METHOD cl_gui_cfw=>dispatch
IMPORTING
return_code = return_code.
The value of return_code indicates whether or not the call was successful. If you do not call this method in your program (explicit), the system calls this method automatically after the end of the PAI event (implicit).
The flush method
This method is used to force synchronization of the Automation Queue. All the buffered methods in the queue are then transferred to the front-end via RFC for execution:
CALL METHOD cl_gui_cfw=>flush
EXCEPTIONS
cntl_system_error = 1
cntl_error = 2.
If there is any error, an exception is triggered. If you do not call this method in your program (explicit), the system calls this method itself after the end of the PAI event (implicit).
The CL_GUI_OBJECT Class
The CL_GUI_OBJECT class is the superclass of all control wrapper classes. The commonly used methods are is_valid and free:
The is_valid method
This method informs you whether or not a control for an object reference still exists at the front-end. Suppose you want to find out whether or not the variable my_control has the object reference of an instantiated control. In that case, you use the following code:
CALL METHOD my_control->is_valid
IMPORTING
result = result.
If the value of result is 1, then the control is active. A value of zero means it is inactive.
The free method
This method is used to destroy a control at the front-end. The method also deletes the entry of the control from the Controls Technology Framework system table. You should also initialize the object reference after this method call:
CALL METHOD my_control->free
EXCEPTIONS
cntl_error = 1
cntl_system_error = 2.
Free my_control.
The CL_GUI_CONTROL Class
The CL_GUI_CONTROL class is inherited from the superclass CL_GUI_OBJECT. All control classes are then inherited from this class. It contains the following methods for setting attributes of the control and implementing event handling:
The constructor method
This method is called by the control wrapper when you instantiate a control by the CREATE OBJECT statement.
The set_registered_events method
This method is used to register the events of the control (this will be covered in more detail in the upcoming blog, Part 3, on event handling):
CALL METHOD my_control->set_registered_events
EXPORTING
events = it_events
EXCEPTIONS
cntl_error = 1
cntl_system_error = 2
illegal_event_combination = 3.
The table it_events contains a list of the events that you want to register, and is based on the DDIC structure CNTL_SIMPLE_EVENT.
The get_registered_events method
This method returns a list of all events registered for a control:
CALL METHOD my_control->get_registered_events
IMPORTING
events = it_events
EXCEPTIONS
cntl_error = 1.
Again, the it_table events should be based on the DDIC structure CNTL_SIMPLE_EVENT.
The set_visible method
Use this method to make a control visible or invisible:
CALL METHOD my_control->set_visible
EXPORTING
visible = visible
EXCEPTIONS
cntl_error = 1
cntl_system_error = 2.
If the value of the variable visible is equal to “X,” the control becomes visible. When it is equal to space (“ ”), then it becomes invisible.
The is_alive method
If a control is already destroyed and you try to destroy it again, an error will occur. To avoid this we can determine the state of a control using the following code:
CALL METHOD my_control->is_alive
RETURNING
state = state.
If the control is active and visible, then the value of state will be equal to the attribute state_alive of the control.
How the Automation Queue provides a buffer to the Automation Controller to help avoid decreased system performance.
Each control class method, if called immediately from your ABAP program, could open a separate Remote Function Call (RFC) connection between the application server and the front-end. Too many RFC calls can result in poor system performance and excessive consumption of system resources. To avoid this, the Controls Technology Framework methods are not executed when they are called. They are instead inserted into a buffer called the Automation Queue before being sent for execution to the Automation Controller (the presentation server) at defined synchronization points. Automatic synchronization occurs at the end of the PBO (Process Before Output) event. Synchronization can also be forced by calling the static method CL_GUI_CFW=>FLUSH.
The Automation Queue follows a FIFO (First In, First Out) principle. At synchronization, the methods that are called first are executed first. For every internal session, there is a separate Automation Queue to handle its controls (see below).
At synchronization, the Automation Queue passes its contents (methods m1, m2, and m3, in that order) to the front-end. The methods are executed at the front-end and the results are returned to the back-end.
That was a brief overview of the Controls Technology Framework’s use of the Automation Controller, and Automation Queue. We also explored the OO Class structure and commonly used methods in ABAP development.
In the next blog we can look closer at the Events and Error Handling.
To read part 1 of this series on the Advanced Control Technology Framework, use the following link. SAP Controls Technology Part 1
