Extracting user-defined session name in SDK

Question

question

BillS asked Nov 20, '09 BillS posted Nov 20, '09

Extracting user-defined session name in SDK

(continuing from email, so other folks can see the questions and answers..)

I have an open step, such as:

open, s1, project://com.cisco.foo

And via the SDK I want to extract that user-defined session name (s1), which is needed for a variety of wierd but important reasons in my tool.

While I could make "s1" the contents of a variable, then extract that variable data, I'd like to avoid extra steps for the end users.

What options are there for getting that data? In the old SDK (yes, I'm one of the odd ones who developed things with the early forms of the SDK..) I used to use:

String session = this.getExecutionContext().getStep().getSession();

So maybe it's available in the Step data model of the new SDK somewhere?

Thanks,

-Bill

iTest sdk

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2009-11-20T22:34:10Z

AdamB answered Nov 20, '09 AdamB posted Nov 20, '09

So the model should have the name of the session, this will be s1.1, s1.2, s1.3 etc. Does the session name that your tool is using have to be explicitly what is typed in by the user? Or will it work if you later just use the string "s1.1" for all the procedure calls? "s1.1" appears to be a valid tcl variable name.

I'll give it some more thought to see if I can come up with something better. The way it could eventually be available via the ISessionContext in the session. It currently is not available there.

8

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

BillS commented · Nov 21, 2009 at 01:12 AM

It needs to be the name the user provided that they'll refer to in later steps. In this case model.getName() returns the name of the profile with an incremented counter, such as:

Step: open,s1,project://my_project/session_profiles/Csccon1.ffsp

model.getName() = Csccon1.23

So no joy there. If it was at leats "s1.23" I could parse out the last portion and get it.

When I run in debugging mode I can see that there's _something_ that has access to the session name:

2009-11-20T20:03:57.470: Thread 1: Executable Step main/1: Executed Step 1: started
Action: open, Session: s1, Description: project://my_project/session_profiles/Csccon1.ffsp

I just can't find what to extract or cast to get that...

-Bill

0 ·

AdamB BillS commented · Nov 24, 2009 at 08:53 AM

Ahh... though, it will be the same "name" for every step in that session, so whether it is s1 or csccon.23, every step will have the same session name.

I will double check, I thought that during execution we were supposed to be passing the actual name used, i.e. s1.23, if s1 was the session provided in the step. I might be able to sort out a workaround to get you that infromation. It won't be sanctioned (i.e. it will use reflection) and we will have a better solution later.

0 ·

KumarS AdamB commented · Nov 25, 2009 at 05:53 PM

Is it possible to get access to "session" field of a step in testcase by a tool session?

0 ·

AdamB KumarS commented · Nov 25, 2009 at 07:05 PM

Unfortunately it isn't. The IRequestResponse is already associated with a session, so the session infromation is not passed in and is not directly available.

0 ·

KumarS AdamB commented · Nov 26, 2009 at 05:03 PM

I think we should have the model access to the actual session string in the step as well as the dynamic session name and session id of the run time.

Bill - will it be OK if you changed your logic to use runtime id which is available to you? From what I can sense, it seems like you need a constant string to associate with some other objects/sessions your tool creates. Instead of getting "s1" from the testcase, you will end up getting a string like "t1" - but good thing is you will get t1 for all steps of session "s1". So instead of "s1.command foo", you will end up invoking "t1.command foo" in your tool. Will that work?

0 ·

BillS AdamB commented · Nov 30, 2009 at 02:42 PM

Unfortunately the name isn't specified by the end user, so they have no visibility into what it is. Eg, If I open in step 1, and I want to pass that session name value into step 2, I don't know what it is. Additionally, the session names are typically created to reflect roles, such as "client1" or "pe3", so using an auto-generated name is kludgy at best.

Why was it removed from the current SDK when the step-based extraction was available previously? My concern is if a workaround is used we'll run into a need to recode it with other releases, etc.

0 ·

KumarS BillS commented · Nov 30, 2009 at 06:09 PM

We never thought that step session id will be meaningful to the applications. But it seems like your application does need it. But I am still curious that when a testcase is executing, why does it matter if the session id is "client1" or "t19623" (dynamically generated)? Does the user end up seeing this id somehow when a testcase is executing?

0 ·

BillS KumarS commented · Nov 30, 2009 at 06:31 PM

It's pretty safe to assume that if it's a property in a step, something built with the SDK will want access to it at some point. :)

The session name is important because it's a parameter the user must supply to other Tcl libraries which use the underling connection lib. eg:

open, mysession1, //myplugin.ffsp

Creates a user-friendly handle of "mysession1" for iTest to use in later steps, and the Tcl library under the plugin creates a "mysession1" user-friendly handle (in this case it literally creates a Tcl command named "mysession1") for passing through by reference to other Tcl procedures.

When later procedures receive that name, they call it as a Tcl command with methods, such as:

mysession1 exec "show ip route"

mysession1 reload

.. etc..

0 ·

question