What is the future of GUI Scripting?
GUI scripting is an SAPGui automation service that useful for many purposes. Especially administrator of SAP Systems perform heavy wizardry with using Spreadsheets and GUI scripting. If you don’t know what I’m talking about just visit the scripting homepage that is available at SAP GUI Family by clicking on the SAP GUI Scripting link in the lower right section. If you still don’t know what I’m talking about a small video can show you the basics of scripting: http://www.youtube.com/watch?v=I3i9TLhRXFc .
The Present…
Let me give some examples. I know an admin who maintains software logistics of complex systems landscapes with dozens of systems with an excel sheets. His Excel sheet controls transactions STMS, SE03, SE09 and SGEN. He downloads protocols, adds them to his sheets and can even start imports and much more. Using this sophisticated sheet he can install SAP systems and make them ready to run within shortest time. Another admin controls SM37 (job execution) and get the results (job log & spool) back to his Excel sheet. When I first saw those excel sheets and I couldn’t believe what I saw.
And the Future?
SAP told us that ABAP Dynpro therefore GUI scripting is obsolete. What are the consequences?
At first the good news: I think that all transactions above mentioned admins used will be the last ones who will ever be migrated. The same is probably true for transaction SPRO and most of the “infrastructure”. But the question still remains: will there be a solution for WDA dialogs? At the moment I don’t know anything comparable but I may be wrong. eCATT is much too heavyweight to perform this task and the same seems to be true for test tools like Selenium.
If we only have to evaluate data we could start get more familiar with BI on demand or perhaps Xcelsius. But nevertheless it should be possible to do GUI scripting in web environment. It should be possible to access the content of a WDA foorplan or the views (resp. context) of a single WDA component using REST web services. If we write an API that is at least as comfortable as the SAP Scripting API then this could solve our problems
really good and and overdue promotion for an underestimated access method!
>>"Using this sophisticated sheet he can install SAP systems and make thmen ready to run within shortest time"
Can you please verify if this is really done with GUIscripting?
I don't see any chance to do an installation this way, because without an installed SAP-System, there is no GUI to control via scripting.
see: "The chicken or the egg?"
Everything else you described is possible when real(!) admins with scripting knowledge don't like to repeat steps again and again.
Laziness leads to improvement! Yeah! Great work of your admins!
It is an API, but we shouldn't we keep in mind, that bulding interfaces to the SAP-system via the GUI is a work-around only?
The main intention of the View-layer (GUI) is to visualize the data/information for the users.
Interface interaction and data requests should happen on a lower level whenever there is an API for it (BAPI/WebServices).
It reminds me of to a current talk about the request for BDC for WebDynproABAP to make mass-data inserts possible.
http://enterprisegeeks.com/blog/suggestions/comment-page-2/#comment-3276
GUI-scripting as well as the GUI-XT won't be able to cover all kinds of user-frontends in future.
But as long there are no APIs for an issue, go and try to script it via the GUI!
Christian
you are right, within the installation process of setting up an SAP system GUI Scripting won't help you but it will during installation and implementation of an application. Within those procedure you have to import transports, activating BC Sets, setting up RFC destinations, run installation report and so, and after each step you have to check the results (protocols, spools, content of transparent tables and so on). If you have little experience this will take you weeks. If you are experienced you can do it manually within days - but using scripting you can do it in one day and there are further benefits: you get a protocol of the procedure as well as the steps. So this can be seen as a checklist that can be executed again after slight modifications.
There are another aspects: I hope I can remind SAP architects that they shouldn't forget non-functional requirements when "reinventing" SAP Business Suite in new releases. There are SAP architects who are well aware of that (let me mention Carsten Ziegler and his great framework BRFplus) but there are other negative examples I don't want to mention here. Those produce software "designed as specified" but forget about non-functional aspects.
You are right when you said that APIs are the better way to get access to a system. But we learned that an API has got to be easy to use. I hope I don't annoy people but I want to mention the whole XML vs. JSON and SOAP vs. REST debate. Most of the time I'm one of those "old fashioned" XML / SOAP guys because I learned to use heavyweight APIs - but I'm well aware that most innovations at SAP TechEd Demo Jams are using lightweight techniques (REST) and project Gateway shows that SAP is well aware of that. We can learn that exposing functionality as API is useful but this API must be easy to use. There will be new APIs an I hope SAP architects will look at old-fashioned APIs to get inspiration.
Cheers,
Tobias
Only GUIXT solution was available for users to distinguish between real Prod & Clone as SID was same
Created 2 scripts
saplsmtr_navigation.e0100.txt
Esession.txt
BOTH having identical code
if V[_ashost=10.3.3.18]
TitlePrefix "CLONE18"
TitleSuffix "(CLONE8)"
endif
if V[_ashost=10.3.3.25]
TitlePrefix "PROD25"
TitleSuffix "(PROD25)"
endif
After much research - this was only solution.
GUIXT will be around; like SAPSCRIPT & SMARTFORMS
despite the enticement of Adobe Forms!
But, this clearly shows the schism between the old and the new worlds. In the brand new world of OO, MVC and strict de-coupling between the presentation layer and the "model", we are taught to encapsulate all functionality in the underlying objects/classes, and that the presentation itself is a fluid concept. Ideally, when you have a rock-solid object model, you should be able to add the visualisation more or less as an afterthought, based on the preferred flavour of the day (GUI, browser, hand-held device etc.) Of course, when it comes to some of the more "technical" areas of SAP, there simply are no OO-based foundations that can be used to tailor the system to your own needs. Instead, you have to rely on transactions, function modules, classical reports as your "API's".
SAP is still heavily mired in the procedural world. I believe it will take another few ages before we see a situation where "everything" has been objectified and modelled, and features such as GUI scripting has gone away.
One could argue that this diversity makes life more interesting 🙂
Regards,
Trond