Skip to Content

Since the release of BI 4.0 (and going back as far as XI 3.x and XI R2), we’ve had various issues related to stale user sessions.  I’m referring to a user session initiated from the BI Launchpad, CMC or other SDK application that should have expired and been deleted by the CMS hours or days ago, but is somehow still listed in the CMC > Sessions page.  These open sessions not only consume a license but also take a small bit of CMS resources as long as they’re kept open.  BI4.1 SP3 has a nice new feature that brings us one step closer by offering a way to manually drop a session.  But this still leaves it up to the Administrator to manually do this periodically.  See screenshot below from prereleased copy of SP3:

/wp-content/uploads/2014/03/sp3_feature_420100.jpg

As you can see above, here’s a session that has been active for almost a week.  The new SP3 feature will now allow you to select one or more sessions and click ‘end session’.  This is no doubt a step in the right direction.  Prior to BI4.1 SP3, you really had two options:  1.) Recycle the CMS or  2.) run an sdk script to do the delete.  I think we can do better than this.

I’d love to be able to solve the real issue(s)… which would be for the BI product to always close the session when it expires (or possibly even sooner, for instance when the user is finished with it).  But unless we knew the exact workflow a user followed that led to a stale session, we can’t prevent and fix these types of problems in a patch or code correction.   If you find a specific workflow that can cause a session to linger for hours or days after it should have  expired, please raise an incident with SAP in the BIP-BI-SRV component and we’ll do our best to resolve it.  Also, be sure to read kbase# 1862925 – “Session handling and tuning”.  Until the workflows are each identified, I’m offering you more of a reactive approach to this problem. 

I’ve seen a few scripts on the SCN offering a way to delete user sessions.  But I couldn’t find one that offered a way to automate the task, delete it safely and most of all delete a user session based on its age.  The script I created can be uploaded to your BI 4.x environment as a Program File and automated via a recurring schedule or it can be run on from a command line manually on or off the BI server. I’ve tested it under various locale and regional settings and it works well on both Windows and Linux installations.  As any program, there are probably flaws so please use at your own risk and let me know if you run into problems.

Due to file format restrictions on the SCN, the ‘biUserSessionKillScript’ (both .biar and .jar) can be downloaded from:

kbase#:  996692 – How to Automate the Cleanup of Stale BI4 User Sessions

Uploading as a Program File:

There’s two ways to insert the Program File into your BI4 environment.  You can either add it via CMC as a Program File or import it via Promotion Management via an .lcmbiar file.

CMC insert method:

  1. Login to the CMC, Navigate to a folder, click on the ‘Manage’ menu and select:   ‘Add’  > ‘Program File
  2. Browse to the biUserSessionKillScript.jar file and change the ‘Program Type‘ radio button to ‘Java’. 
  3. Select OK

Promotion Management method:

  1. Log into the CMC and open the Promotion Management page.
  2. Choose ‘Import’ > ‘Import File’ and select the attached .lcmbiar file.
  3. After clicking OK, select the destination dropdown and login to your CMS.  Click ‘Create’.
  4. In the next screen, click ‘Promote’.

Scheduling the Program File:

Scheduling a Program File is very similar to scheduling a report.  The only difference is you’ll need to specify a few arguments to tell BI how to run the program.

  1. Right click on the Program File and click ‘schedule
  2. Select the ‘Program Parameters’ option on the left
  3. The only argument the script needs when run within BI is the Age of a Session in Minutes
  4. Specify this value in the Arguments textbox.  For safety reasons, the value must be >= 60. Anything less and you risk deleting an active user session.
  5. In the ‘Class to run” textbox, type:   biUserSessionKillScript
    • /wp-content/uploads/2014/03/schedule_page_412458.jpg
  6. From here, you can specify any of the other scheduling settings you need like recurrence, notification, etc. and then click ‘Schedule’ to run the job.
  7. Regardless if the script succeeds, there will be a text file saved to the Output FRS with the results.  Click on the instance title to view the output.
    • /wp-content/uploads/2014/03/output_file1_412459.jpg/wp-content/uploads/2014/03/output_file_412412.jpg

Running the jsp outside of BI

Run manually on the server console via cmd line:

  1. Copy the ‘biUserSessionKillScript.jar’ into the equivilant folder in your BI4 installation directory:
    • C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\java\lib
  2. If your path is different than above, then you’ll need to also edit the ‘biUserSessionKillScript.bat‘ file so the correct path is referenced.
  3. Execute the .bat file directly.
  4. To prevent the cmd window from disappearing at the end ofthe program, open a cmd window first, drag the .bat file into the window and click enter.
  5. Or you can copy the syntax within the .bat file and paste directly into a cmd window.

Run manually on a non-BI server via cmd line:

The biUserSessionKillScript.jar was compiled without including the BI4 dependency jars.  This helps keep the file small and allows for a quick and easy download.  Also, when the .jar is scheduled, BI already knows where to find the corresponding dependencies so there is no need to package them.  However, if you want to run the script on a pc manually where neither BI4.x nor the client tools are installed, then you will need these depencies inserted into the jar.  In this case, follow the steps below.

  1. On the BI4 Server, open the ‘biUserSessionKillScript.jar’ file with WinRar.
  2. Navigate to the path ‘C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\java\lib’ and insert all of the files below into the .jar.
    • aspectjrt.jar
    • bcm.jar
    • biarengine.jar
    • ceaspect.jar
    • cecore.jar
    • celib.jar
    • ceplugins_core.jar
    • certjFIPS.jar
    • cesession.jar
    • corbaidl.jar
    • cryptojFIPS.jar
    • ebus405.jar
    • logging.jar
    • TraceLog.jar
  3. Prior to adding the jar files into biUserSessionKillScript.jar, it will look like:
    • small-jar.JPG
  4. After adding the files, it should look like:
    • large-jar.JPG
  5. To Execute the file, open a command prompt and run:
    • <path to java.exe> -jar <path to biUserSessionKillScript.jar> <username> <password> <CMS servername> <Auth Type> <session age in minutes>
    • manual cmd.JPG
To report this post you need to login first.

53 Comments

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

    1. Surendra Singh

      Hello,

      I am little confused as how it is different from SP3 feature. Is it better same like SP3.

      The author is well aware of the new feature in SP3 as mentioned below –

      BI4.1 SP3 has a nice new feature that brings us one step closer by offering a way to select a session in the CMC to end it.  But this still leaves it up to the Administrator to manually kill these sessions.

      Your clarification in this regard will be greately appreciated.

      Regards

      SS

      (0) 
      1. Joshua Kuhn Post author

        Jawahar / Surendra,

        Thanks for the comments.  I’ll edit the blog shortly and add a screenshot of what the new feature looks like in SP3.  Maybe this will add some clarity.  In short, the new feature in SP3 gives an admin the ability to select a user session in the CMC > Sessions page and click delete.  This requires manual intervention.  The .jar in the blog offers a way to schedule a Program File periodically (once or twice a day) to do this cleanup automatically based on the age of the session.  And it determines the age based on the session’s creation time.

        (0) 
  1. Pawan Racha

    Hi Joshua,

    Great article. I especially like the way you described to schedule the java app in the CMC console for recurrent executions.

    To kill idle sessions, would you suggest using the SI_UPDATE_TS property of the Connection InfoObject, and compare it with the SI_CREATION_TIME to determine the idle time of the BOE user session?

    Thanks,

    Pawan.

    (0) 
    1. Joshua Kuhn Post author

      Hi Pawan,

      Its a good idea and this would be a cleaner way.  Unfortunately, the SI_UPDATE_TS field can’t be trusted in this way for this infoobject type.  From what I’ve seen, the SI_UPDATE_TS, SI_CREATION_TIME, SI_LAST_ACCESS and SI_LASTLOGONTIME properties do not get updated within the lifespan of a session object.  The original date-time value that is written when the user logs in doesn’t change for any of these fields.  This was why I chose to go off of the SI_CREATION_TIME.

      (0) 
  2. Brian Thomas

    Great contribution Josh!  There’s been a few situations where we’ve needed the ability to clean up a stale user session. 

    Im really glad integrated this functionality in the CMC in SP03, but your script makes it even possible for environments pre-SP03 🙂

    (0) 
  3. Dan Pirato

    Hi,

    I just ran this in our dev system as a test.  I had a few users logged on for about 10 minutes so just as a test I ran it with 7 minutes as the parameter. 

    It ran successful and the output report showed the users but non of the sessions were killed.

    I did this through the CMC as a program file

    Any thoughts?  I would love to have this feature working until we upgrade to SP3.

    Thanks!!

    (0) 
    1. Joshua Kuhn Post author

      The minimum value the tool will accept is 60 minutes.  This was done for two reasons.

      1.)  User sessions typically take ~60 minutes to timeout when an idle page is left open.  Using any value less than 60 and you risk deleting an active user session.

      2.) I didn’t want the tool to be used to circumvent the licensing model.

      The tough part about this whole idea is that there’s no real way to tell the difference between a valid user session and one that isn’t.  The only method I could think of was to make an assumption based on time and leaving this up to the admin seemed the safest approach.  I’ve yet to hear of an issue with anyone running the script where it doesn’t work, or where it deletes more than it was intended.  But I’d urge you to look at the output file that gets created after the program file is run.  This will log the settings used when it was run and which sessions were left alone vs which ones were deleted at that time.  Hope this helps.  The blog explains how to find this output file.  Thanks for the feedback and please continue to let me know if you have issues.

      (0) 
      1. Dan Pirato

        Awesome!  thanks for the quick response.   I will test out with a user logged in for over an hour.

        Ill let you know how it goes.

        Thanks!

        (0) 
      2. Dan Pirato

        Worked like a charm.   Very nice program!

        One question……obviously if reports are running under a users name they will not be stopped right?   a session requires you to be  physically logged on right?

        (0) 
        1. Joshua Kuhn Post author

          When a report is scheduled, a user session is created for the duration of the schedule as the user that scheduled the document.  However, this session is created with SI_AUTHEN_METHOD = ‘server-token’.  When you login as a user to BI Launchpad, for example, the SI_AUTHEN_METHOD = ‘secEnterprise’ , ‘secWinAD’ , etc.  The script uses the following query to pull back session objects before it determines the age of each session:

          select si_id, si_name, si_creation_time from ci_systemobjects where si_kind=’Connection’ and si_parentid=41 and si_name != ‘System Account’ and SI_AUTHEN_METHOD != ‘server-token’

          As you can see, the server tokens are already being omitted from the query, so these should never be removed as a part of this script.  Also, a ‘server-token’ isn’t a visible session that you would see in the CMC > Sessions page.

          (0) 
          1. Dan Pirato

            looks like this solution is working great for me client.  there was quite a stir-up with people not being able to log in:

            a few notes- I set it to run every 4 hours with the 60Min threshold.  Additionally I kept the number of instances allow to just 50.  no reason to have 10000s of these read outs.

            Could be a nice way to retroactively check on your team and who was logged when!

            thanks again!

            (0) 
  4. Shaheen Usman

    Hi,

    This has been really helpful in our environment. I am using this to kill the stale sessions in DEV/QA and PROD.

    From past couple of weeks Iam getting error on the schedules in Dev “

    The specified JVM ‘”F:\Program Files (x86)\SAP BusinessObjects\SAP

    BusinessObjects Enterprise XI 4.0\win32_x86\jre”\bin\java.exe’ does not exist or

    is not a valid executable file.”

    The schedule is still running fine in QA and Prod.

    Appreciate your help.

    Thanks,

    Shaheen

    (0) 
    1. Joshua Kuhn Post author

      The tool will be executed by the AdaptiveJobServer running the subservice:  ‘Program Scheduling Service’.  I believe this service should be looking for the java.exe in the 64-bit location, not the 32-bit location you’ve specified above.  Could it be you’ve added a JAVA_HOME env variable recently and pointed it to this location?  or did you recently make any changes to the AdaptiveJobServer that would force it to use the java.exe in the 32bit dir?  In any event, the AJS is a 64bit application and should load the 64bit jvm. 

      The error you’re getting is more of a problem with how the jobserver is loading the jvm, not the execution of the script itself.  The script has the ability to run in the 32 or 64 bit jvm in console mode.  But when scheduling it, the jobserver decides where to load the jvm.  The source of the issue is likely a recent java upgrade, env variable change, or something else related to java in this path.  If the BI4 environment is clustered across multiple hosts, try using a JobServer on a different host to test.  If you’re having this issue scheduling the program file, I would also expect scheduling any webi doc on the same AJS to also fail.

      Or you can try running the script manually from the command line.  That would allow you to point to whichever java.exe you want it to use.

      (0) 
    1. Joshua Kuhn Post author

      Not if you mean when scheduling within the CMC / BI Launchpad.  An enterprise session is passed to the program at schedule time just like any other scheduled report in the system.

      If the jar is run from the command line, then yes you will need to pass the CMS login information.

      (0) 
      1. Jawahar Konduru

        When i schedule from CMC without program logon, it failed with error “No operating system credentials were set for running the program”

        When i gave the credentials of Server account , it failed again with error “

        The Program Object reported an error while running, but no error code was

        provided”

        (0) 
        1. Joshua Kuhn Post author

          Feel free to private message me and we’ll work through it. But I have never had to set the “program logon” options when scheduling this Program File. 

          The Adaptive JobServer which is running your  ‘Program Scheduling Service’ will take the program from the FRS and execute it locally.  So as long as this Jobserver is running under an account that has permissions to the java.exe and can run the command mentioned in the blog, it will work.  It sounds like you have locked down your user accounts in some way where the SYSTEM account or whichever account is running your SIA might not have execute permissions to the java.exe.  Try testing with another jar and upload it as a program file, chances are this will also fail.

          (0) 
  5. Vinay Ponnekanti

    Hi Joshua,

    Thanks for providing the solution. It helped us a lot. I am facing the same issue as Jawahar stated above. I was able to implement this successfully in DEV/PROD but not in QA environment.

    When I schedule from CMC without program logon, it failed with error “No operating system credentials were set for running the program”

    When I give the credentials, I am getting the below error message.

    Error Message:Could not authenticate using the provided operating system credentials.

    Any help is greatly appreciated!!!

    (0) 
    1. Joshua Kuhn Post author

      I’ll be honest, I don’t know if the other issue ever got resolved.  Its the only time I had heard of the problem and now you’re the 2nd.  The last I spoke to Jawahar, I felt pretty confident the problem was specific to the Windows service account running the SIA.  I remember wanting to test running the SIA as local SYSTEM or possibly as local Administrator just to test the theory, but I looked back through email conversations and don’t see what the result of that test was or if it was ever tried.  You may want to do the same, look to the local security policies and maybe compare settings between the servers.

      (0) 
      1. Vinay Ponnekanti

        Thanks Joshua for your prompt response. I really appreciate it. I will try to work with windows admin team and try to find out the differences between the servers. I will let you know whats causing this if I find out 😕 .  Can I send you personal message on this particular issue where If  BI expertise is needed?.

        (0) 
  6. Bill Taylor

    Thanks Joshua for the example! I’ve done something similar, but I need to add multiple argument values into the args array in the program. I can’t seem to figure out the syntax in the “Arguments” box to specify multiple values to populate my array. Can you help with that?

    Thanks

    (0) 
  7. Bartosz Jedrzej

    Very nice and usefull script. As an improvement it could have option to kill sessions that are not active in last x minutes/hours.

    But looks like BI4 doesn’t hold that information, in CMC you can find only first logon time.

    (0) 
  8. Praveen kumar

    Hi Joshua,

    The script worked in my dev system where the installation in the default directory‘C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\java\lib . But in my production the installation is in D drive.  When scheduling, I am getting an error java class path not found. How to get this work?


    -Praveen

    (0) 
    1. Joshua Kuhn Post author

      I’m pretty sure the installation drive has nothing to do with it.  The /java/lib folder that its looking for is referenced in a placeholder variable in your BI system.  %CommonJavaLibDir%.  When the program file is scheduled, its loaded by the jobserver and the jobserver is what will fetch the libraries needed.  The script doesn’t tell it where to get these, only the names of the required jars.  If you unzip the biUserSessionKillScript.jar, there’s a manifest file that shows the classpath.  It shouldn’t have any paths referenced here, only a comma separated list of names.  Further to that, I’m pretty sure I’ve run the same script on a linux system. 

      This is likely more of a configuration issue on the 2nd server.  Did you possibly not do a full install on the server where its failing?  Maybe you’re missing a few jars or config settings.  Another idea would be to try copying the biUserSessionKillScript.jar into the /java/lib folder and executing it manually via command line from there?  There’s a batch file in the downloaded zip and instructions in the blog above on how to do this.  If that works, then so should the jobserver.  Lastly, try creating a new program file in the CMC and point to the same biUserSessionKillScript.jar file. 

      (0) 
    1. Joshua Kuhn Post author

      The download link above points to kbase article  which is password-protected via the Service marketplace.  You will need a login for SMP.

      (0) 
  9. Brojeshwar Ghosh

    I must say it is a great tool to control end user sessions. But unfortunately we are not able to identify the actual stale sessions. Sessions which are actually inactive for more than 60 minutes without any activity.

    Here in this code we are just deleting sessions by comparing last logon time with current time. Not able use this tool 🙁 😥 😥 .

    Actually I needed a tool to clear out the OpenDoc sessions. We are planning to use lot of Opendoc type reports. It will increase the user sessions. Was thinking may be I can use this tool to clearly identify such sessions and kill it after 60 minutes or so. I can see under CMC–>sessions, sometime it is marked as “Open Doc” or “Logon without Client ID”.

    Is there a way to kill specific sessions?

    (0) 
    1. Joshua Kuhn Post author

      Correct, this script only compares logon time to current time.  Each session, regardless if it comes in via openDoc, BI Launchpad or a client tool should adhere to the session timeout set on the web application server.  Although the session cleanup usually works correctly within BI, we found that every once in a while certain sessions would stick around for days. This script was designed to help automate the cleanup of sessions in this situation (when the built in session cleanup didn’t work), not a means of overriding the session cleanup already written into the BI4 product.  At this time, the only way to delete a session is to do it via the CMC > Sessions page, restart the CMS’s or to run a script such as this.  The idle session is maintained by the web application server.  When a user logs in, the clock starts counting down based on the session timeout setting.  Every click resets the timer.  When it reaches 0, then the web app server communicates this to the CMS and the CMS will eventually do its session cleanup.  Because the remaining time value is never shared w/ the CMS (until it reaches 0), there’s not a way for us to query the CMS via the BI SDK to determine HOW STALE a session is.  Make sense?


      It sounds like your concern is more about how to control sessions in a heavily used OpenDoc environment.  I believe your answer is going to be in finding a sweet spot for the idle session timeout.  What works for one system may be too short or too long for you.  Based on the types of reports viewed through openDoc, you’ll want to set the session timeout accordingly.  Then for the few instances where a session is never cleaned up, you can run this script once or twice a day just to clean out the remainder of the sessions missed by the internal BI session cleanup mechanism.  There used to be a workaround in previous versions for forcing an opendoc logout when the browser was closed, but this might not be possible anymore due to the BOE webapp changes in BI4.0 compared to XI3.1.

      (0) 
  10. CHRISTOPHER FROMANDI

    didn’t work for me at all.. im on SP7, latest patches.. I need it to kill users immediately upon closing the browser.. that’s SUPPOSED to work in SP06.. but for me it does not. I have a case with SAP, but getting help is like pulling my own teeth out since they are on the opposite side of the planet.

    (0) 
  11. Thomas Buxereau

    Hi Josh

    Thanks for creating this!!

    I have loaded the file via the lcmbiar file and scheduled it to run. All good so far, except it fails with the message:

    Could not create temporary directory for program files.

    Where is it trying to create this temp directory please?
    Thanks

    (0) 
    1. Joshua Kuhn Post author

      There is no temp directory specified in the script.  It’s likely the JobServer that is throwing the error.   The program file will rely on the jobserver to execute it and if any temp files are created during the processing of it, they would utilize the jobserver’s working folder.

      If you have multiple jobservers, try scheduling it to a server group where you can force the processing to a specific JS and rule out if this error occurs on all or just a specific JS.  Also check user security.  Its not required, but try scheduling the program file as administrator and maybe move it to another folder where advanced permissions aren’t denied.  Worst case, look at the jobserver logs to see what other information it offers.  Sorry, I haven’t heard of this error coming up for anyone else. Please update the post if you were able to narrow down the problem.

      (0) 
  12. Mahendra Singh

    hi Joshua, question, how does the script identify if the user session is active or stale? what if the user is active for 24 hours, and script argument is 720 minutes(12 hours), Will the user get kicked out because the user’s session age has crossed the limit?

    (0) 
    1. Joshua Kuhn Post author

      The script uses the SI_CREATION_TIME property of the session object to calculate how old the session is.  There are other date time fields in the session object, such as SI_UPDATE_TS, SI_LAST_ACCESS and SI_LASTLOGONTIME.  But at the time of writing the script, i found that these properties do not get updated within the lifespan of a session object.  This was why I chose to go off of the SI_CREATION_TIME.  The script will delete a session once its age is greater than the argument value (in  minutes).

      yes, once the session is deleted, if the user was actively using the BI Launchpad or CMC, they should receive a login prompt on their next click.  So you really don’t want to set the age argument too low for this reason.

      (0) 
  13. Shaheen Usman

    Hi Joshua,

     

    The script is working in our production environment, but fails on all other environments with an error

    “The specified JVM ‘D:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\sapjvm\bin\bin\java.exe’ does not exist or is not a valid executable file”

     

    The set up is same across all environments. Any  suggestions?

    Thanks,

    Shaheen

    (0) 
    1. Joshua Kuhn Post author

      Hi Shaheen,

       

      Is the path you entered a cut/paste mistake or did the error really have “\bin” entered twice in the path?  It should obviously only exist once.  As for the script failing, I’m not sure.  There’s nothing in the script that points to java.exe and when running as a program file, its up to the jobserver to find the java.exe on the host to execute the jar.

       

      Are you running it as a program file via the jobserver?  Or are you running the jar manually on the host using the .bat file?  I’d suggest running it manually via the bat file or you can use the Windows cmd prompt if you wish.  The jar file would need to be copied into the java\lib folder first so the required dependency jars can be found.  Once copied, if you use the .bat file, then first edit the file and change the path to your D:/ drive and test the path is correct.  If you use the cmd option, then  your command should look something like:

      “D:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\sapjvm\bin\java.exe” -jar “D:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\java\lib\biUserSessionKillScript.jar” Administrator <password> localhost secEnterprise 720

       

      See if that works for you.  If so, then there’s probably some kind of pathing issue on the problem servers when the jobserver tries to find the java.exe successfully.  In that case, look to your placeholders in the CMC and/or possibly your JAVA_HOME env variable.  Lastly, if you see the cmd above works, try it again by replacing the first path with just “java”.  This will let the OS use the env variables to find the java.exe instead.  If this fails, then what i just said about the java pathing is probably true.

       

      Also, as a last resort, make sure you haven’t split the services on your jobservers.  There could be a chance the request is being sent to a jobserver that doesn’t have a program job service member.

       

      Good Luck!

      Josh

      (0) 

Leave a Reply