Page tree
Skip to end of metadata
Go to start of metadata

After recording and successful replay in EEM Editor of an http script you should ensure that all sessions in the backend systems are closed.

When a script is executed with a dialog user and the user has already an http session in the backend the system sends an additional screen/pop-up that this user is already logged on. This does not influence the script but an additional session is created which is not closed by the executor because he is not aware of it. As a result with each script execution you got an additional user session.

 

How to avoid these hanging sessions?

  1. Try to use a SERVICE user instead of a dialog user. A user of type SERVICE does not get this multiple login pop-up.
    Pro: This is the least effort and has the positive secondary effect that the password of the user does not expire.
    Con: Sometimes it is not possible or allowed to use SERVICE users (e.g. when calling /nwbc)
  2. Avoid that the script executes in parallel
    Pro: No additional change on script required
    Con: Could be very complicated to synchronize multiple scripts from several locations
  3. Implement the work-arround described below for a dialog user

Avoid hanging http sessions for parallel script executions

  1. Logon with the user before you record the login and keep the session open.
  2. Record the login with multiple logon pop-up ( unselect the checkbox for terminating existing sessions) 
  3. Record logoff step and stop recording.
  4. Import the script into the editor and execute it.
    1. If there is still a parallel session open all requests should be executed succesfully
    2. If there is no parallel session available the two requests with the multiple logon will fail with error:
	Too few occasions of Search, could not define variables from response: 
{pattern=(sap-contextid=)(.*?)("|&|\r\n), rule=ContextId, name=ContextId, left=sap-contextid=, right= , inHeader=true, notfound=3}

           => The messages dealing with multiple logon should be executed only if they are required

The following instructions show you how this is implemented, the general idea is that you generate a EEM search in the editor for the multiple logon UI and assign a value to a specific variable.  This variable can be used as an indicator if the multiple logon UI was transfered from serverside. If it has a value the "terminate other sessions" dialog should be executed. To avoid a frequent execution in an endless loop we need to delete the variables value inside the conditional loop after first execution.

 

 

We need now three changes:

1) Set the Error option (How to proceed if matches could not befound) of the first failed request to Ignore:



Remark: If you would execute the script now, the message 46 in this example will be green even if the search could not find the value sap-contextid in the response.

If the multiple logon UI is presented by the server the variable has a value. If there is no second logon active the variable stays empty but the failed search is not interrupting the script..


 

2) This second message must be set as conditional. This is not supported in the Editor UI but you need to enter the following string on the XML tab for this request ( in this case message 47):

repeatConditionVariable="ContextId_0"

The message which handles the dialog (in this example 47) is now only executed if the variable CONTEXT_ID has a value. Unfortunately until the variable is again without a value. In worst case forever...

 

3) To delete the variables value proceed like this: Enter for the conditional message an additional search that will never match (e.g. with left boundary XXXXXXXXXXXXXXXXXX and right boundary YYYYYYYYYYYYYY and set Error option to Clear with the variable value of the previous message ( ContextId_0):

When you now execute the script with parallel session the two messages (in this case 46 and 47) will be green. If the script is executed without a parallel session message 47 is not executed at all and 46 is green even with a failed indicator search.


 

 

  



 

 

  • No labels