Scripting Engine - Running reports simultaneously

[Ivan_Horvath]

Hi,

I'm working on a .net core WPF desktop application, which interacts with SAP GUI Scripting Engine to execute reports.

Up to now only one report could be executed, but there are reports, which runs for more then an hour, so users are requested to have the possibilities running the reports parallel.

I believe this could be done with creating additional Sessions. However as I'm studying how sessions works there are some difficulties.

Like

• GUIApplication.ActiveSession is sometimes null
• I can create maximum six sessions per connection? or per Application?
• Once the report data collection from the server is started, the UI is locked, and I can not create new session until the data is displayed in the data grid. Is it possible somehow to force UI unlocking and creating a new session? I haven't found any solution for that so far.
  
• Therefore my plan is to create one additional session before the report execution is started. So, if another report must be executed while the first report is getting data from server, that 2nd session can be picked up and run the 2nd report. I can do that simultaneous executions for maximum six reports.
• If the first report is finished, the result is exported into Excel, that session, which is used to run the report can be destroyed.
  
• What is the timeout error for session? I saw sometimes that session is automatically destroyed after some time. Is the Application.destroysession event firing for that case as well?

I have SAPGUI 7.7 release.

FYI: this post is submitted in Application Development and Automation Discussions group, but no answer so far ...

thank you!

Ivan

[jude_bradley]

SAP GUI is not the option you want to use when considering batch or simultaneous programs.

The limitations are described here:  311440 - Batch input and controls 

Symptom

Errors occur when you process or record batch input sessions if the application uses frontend controls such as the ALV grid or tree. Typical cases:

(1)The batch input recorder does not record any actions or frontend control data.

(2) When you process batch input sessions in the background, a termination or an ABAP short dump with the exception condition CNTL_ERROR occurs. The exception condition is caused in the control framework (program SAPLOLEA or also CL_GUI_*).

(3) When you process batch input sessions in the background, a termination occurs with the message
'Editor could not be initialised' in the batch input log.
Processing a Call Transaction ... Using (processing mode N) in the background, a termination occurs with the message:
'Exception condition ERROR_DP initialized'
Since controls are only used more frequently as of Release 4.6A, these problems generally do not occur in Releases < 4.6.

Reason and Prerequisites

1. Frontend controls are generally not 

capable of batch input. Therefore the batch input recorder does not record any data for them and they cannot be supplied with data or actions during a BI session run.

2. Frontend controls cannot be accessed from a background process because it does not have an active SAPGUI connection. If such a communication is attempted by the application nevertheless, an exception condition is triggered by the control framework which causes a termination if it is not caught by the application.

              This also applies to the background batch input (mode E) or a Call Transaction ... Using (mode E or N or P, respectively) in dialog processing.

3. The application uses a frontend textedit control. As with all other frontend controls, it cannot be accessed in batch input. If you try to run an application which uses this control in batch input, the system will terminate with the message BMEN 802, as for point (2). This occurs with the PFCG Transaction, for example.

Solution

1.

• If an application is to be capable of batch input, you must make sure that the desired functions can also be executed without participation of the existing frontend controls.

• If this is not possible or cannot be achieved without investing considerable time and effort, you must use alternative methods for the data transfer (direct input, BAPIs).

2.

• If an application is running in the background or is processed in the background in dialog operation, no frontend controls may be generated and called (query on sy-batch and sy-binpt!).

• The application developer should check whether the action that caused the termination was designed to be capable of batch input. If it was not, the batch input session must be changed accordingly. If it was, the application must make sure that no communication with frontend controls is attempted in the background or during batch input. This can be achieved with a consistent query.

3. As for problem (1), the user needs to check whether another editor can be used in the application instead of the edit control. For example, the editor must be based on a step loop or table view control, so that it can also be accessed in batch input. This question will be answered by the relevant development department.

Additional information on problems (1) and (2)

• The question that is usually asked in practice is "Can I operate a transaction in batch input if it uses frontend controls?"

• Although the batch input cannot run actions on controls, this does not necessarily mean that you can no longer run a transaction via batch input. This would only be the case if the controls were absolutely necessary for navigating in the transaction. A particular transaction can include several simultaneous actions that can be executed via batch input and some that cannot be executed this way at all.

• One particular problem associated with this is that batch input can allow a transaction to run in the background. In this case, the application must ensure that no controls are created and used, in order to enable batch input.

(All statements in this note also apply to applications that use fast input or CALL TRANSACTION USING.)

[Ivan_Horvath]

hi,

I don't want to use Batch processing. I just use Scripting engine to execute the reports.
this multi-session idea seems working