SAP script

[YounesB3]

Hi, I'm new to the SAP GUI scripting and I'd like to understand some line of codes.

Set SAPGUIAuto = GetObject("SAPGUI")  'Get the SAP GUI Scripting object
Set SAPApp = SAPGUIAuto.GetScriptingEngine 'Get the currently running SAP GUI
Set SAPCon = SAPApp.Children(0) 'Get the first system that is currently connected
Set session = SAPCon.Children(0) 'Get the first session (window) on that connection


If IsObject(WScript) Then
   WScript.ConnectObject session, "on"
   WScript.ConnectObject Application, "on"
End If

The code works, but I'm not sure what it does. Could someone explain line by line?

Also, WScript seems to never be an object, so I'm not sure of the purpose of those last lines.

Thanks!

 

[RickXL]

Hi,

My SAP days were a while ago now but I will see what I can remember.

First, there are several ways to link to an SAP session. Here are some: Scripting with Vbscript against SAPGUI

When you log in to SAP you usually do it via the SAPLogon pad or similar. That is the "real" SAP application. When you are in a client that is really just a screen internal to that. It is a bit like Excel in that regard. You tend to think of the Workbook as the top level object but in fact the Application is a step higher up and all the Workbooks run under it.

So, to use SAP, you need to make a link to the SAPGUI object. I believe the SAPGUI in quotes here: GetObject("SAPGUI") will be located in the registry. That will tell the script which program it needs to look for. That is assigned to the name SAPGUIAuto - it could be any valid name but it has to be the same as the one used in the next statement.

The next line finds an SAP application that is currently running and the answer is given the label SAPApp.

The "Set SAPCon = SAPApp.Children(0)" line goes through all the SAP instances that you have started from the SAPLogon screen. You might have logged into the DEV, QA and PRD boxes, for instance. The (0) means that it will return the first such instance. The instances go in the order you started them, that is, the order you selected them from the SAPLogon screen.

Finally, you can have several sessions running on each client. The Set session = SAPCon.Children(0) line will connect to the first session in the first instance.

I have to say, I used to log out of everything and just go into one session if I ran a script. That way you can be sure which session you are going to be affecting. It can get a bit embarrassing if your spreadsheet of test data intended for the DEV box is loaded straight into a production system!

I am not too sure about the WScript part. I seem to recall that if you go into SAP and run a script you cannot use WScript commands e.g. WScript.Echo. However, if you start "outside" SAP and run a script to fire up SAP then you can. The "If IsObject(WScript) Then" line will check which way you are running the script and will make a couple of extra assignments if WScript is available.

I hope this helps.


Regards,

 

[YounesB3]

I am not too sure about the WScript part. I seem to recall that if you go into SAP and run a script you cannot use WScript commands e.g. WScript.Echo. However, if you start "outside" SAP and run a script to fire up SAP then you can. The "If IsObject(WScript) Then" line will check which way you are running the script and will make a couple of extra assignments if WScript is available.

I hope this helps.


Regards,

Yes, your whole description helps tremendously, thanks a lot! Makes sense!

As for the last part, would it mean that if you have a username and password, then you can login into SAP via Excel without having the screen open-up and actually do all the coding with WScript commands instead of using the SAPGUI recorder?

 

[RickXL]

As for the last part, would it mean that if you have a username and password, then you can login into SAP via Excel without having the screen open-up and actually do all the coding with WScript commands instead of using the SAPGUI recorder?

I think the short answer is Yes, but it is something I never tried.

There are at least four ways to run SAP:

1) Open SAP then go to the Scripting menu and play back a script.
2) (My favourite) Put your data into a spreadsheet and write a VBScript (WScript) to use the first session of the first instance. Logging in to SAP first was required. VBScript can be used to start Excel and commands can be passed to Excel from VBScript.
3) It should be possible to control everything from Excel using VBA without VBScript - but I never tried that. In those days I was better at VBScript than VBA.
4) Log in to SAP using a VBScript. I think one of the examples in the link I provided above shows you how to do it.

For option 1, the WScript object will not exist to WScript.Echo etc will not be available. This hampered my attempts at debugging. I am not sure what happens with option 3. You probably do not need WScript.Echo if you do it that way so it probably does not matter much.



Regards,

 

[YounesB3]

I think the short answer is Yes, but it is something I never tried.

There are at least four ways to run SAP:

1) Open SAP then go to the Scripting menu and play back a script.
2) (My favourite) Put your data into a spreadsheet and write a VBScript (WScript) to use the first session of the first instance. Logging in to SAP first was required. VBScript can be used to start Excel and commands can be passed to Excel from VBScript.
3) It should be possible to control everything from Excel using VBA without VBScript - but I never tried that. In those days I was better at VBScript than VBA.
4) Log in to SAP using a VBScript. I think one of the examples in the link I provided above shows you how to do it.

For option 1, the WScript object will not exist to WScript.Echo etc will not be available. This hampered my attempts at debugging. I am not sure what happens with option 3. You probably do not need WScript.Echo if you do it that way so it probably does not matter much.

Regards,

Alright, thanks! I'm guessing the more efficient way is #4 since you do not have all the interface.

Kind of like using ".Select" in VBA vs not using it at all (much quicker & cleaner).

For now, I'll go with #3 because that's what I know.

I may learn VBS in the future or even stuff from the command prompt (bach files & co.) since those seem to permit even more possibilities.

 

[RickXL]

I think all the above options use the interface. Basically, if you need to enter a transaction and execute the transaction steps then you are using the interface.

There are other tools. We used to use a third part tool called Quick Test Pro. That used the interface but its sister program LoadRunner, I believe, did not. Then there are SAP options. CATT is one that is usually used for testing and LSMW for loading data.

Or you could use an ABAP program, or call ABAP functions from VBA or similar. Or you can run BAPIs the same way. BAPIs are safer than functions. If you just need data out then there are lots of reports available that can download data. If there isn't a suitable report then you can write one with either report painter or report writer.

As usual with SAP, there are always more ways to do things than enough.


Regards,