Best Practices when working with Winshuttle Transaction scripts

By Winshuttle Staff Blogger on Jul 29, 2011

The beauty of working with Winshuttle’s products is that they are not prescriptive about how you manage the automation of a given process. There are some constraints around the automations such as not being able to bypass your SAP security authorization profile, not being able to log onto an undefined SAP system but for the most part it is at your discretion as to how you use the products.

Just like managing your PC files and music collection, the more disciplined and methodical you are about the way you use the products and their associated artifacts ultimately helps you in ensuring that you don’t cause confusion for yourself and your colleagues.

Human beings distinguish themselves from the rest of the world’s living creatures by being exceptionally good at sorting and ordering things and accordingly, if we categorize, order, sort and label our Winshuttle scripts and data repository in a meaningful way we can use the products to best effect and with minimized risk of using the wrong things to achieve routine tasks.

Some time back we released a guideline for best practices in using Winshuttle Transaction and Runner and I thought it would probably be a good time to brush that content off and refresh it based on the current state of the products. Watch this space for more postings on this topic.

Installation locations

First off is installation of the product. While you are given choices about where you install the product, you are strongly encouraged to use the default settings for product installation. The primary reason for this, is that if and when you need to call on our support organization to help you with problems, being able to easily find and locate the products on your machine, help to accelerate the problem or issue triage process

The document repository

If you are a user who authors content exclusively for others to use then consider how you will make the artifacts that you create, available to the Runners in your community. If you have implemented Central this Is not much of an issue as all the templates and scripts are stored centrally on the SharePoint Central site, however if you use standalone or network licensing, the repository for the objects is uncontrolled or at least is probably local to your machine unless you have designated a network drive or shared folder for them. Implementations of ten or more users are strongly encouraged to consider using Central instead of standalone or network licenses.

When creating enhancements to existing objects consider how you will manage versions and how you will ensure that people are using the latest version of the script. When you use SharePoint version control on the same script is easily managed by SharePoint itself however on a shared folder this is more difficult. Typically it is recommended that you include a version indicator in the overall file name for the purposes of easy identification.

File Names

By default, Winshuttle products make suggestions about the kind of file name you should give to an automation object and overriding this suggestion is a sound practice if you have a methodology for naming your objects. You’re encouraged to include the transaction or BAPI name somewhere in th description in order to facilitate easy identification of the associated business function , transaction or API used to create the object. Failure to include technical object call-outs in the file name mean that you have to physically open the script object and examine the meta data associated with it in order to determine which technical object it uses.

Given that Winshuttle products support a variety of modes of use of the product with different data sources you may also want to consider calling out the data source associated with the script such as EXCEL Form or Gsheet Form. In those extreme case where you have many SAP systems that have different attributes or configuration then you may even want to include the system name in the script description. Meta Data is a great way to get more information into the script but that ‘at a glance’ capability is not really possible yet with the file explorer in Windows desktops, for that you have to rely on SharePoint with Central.

So in concluding this post, consider the following diagram that illustrates the idea of one way you could perhaps consider naming your TXR’s or Winshuttle Transaction scripts.

If you have a way that you are organizing your context and you think it would be a boon to new and old users alike please share your thoughts here or at

About the author

Staff Blogger

The Winshuttle blog is written by professional thought leaders who are dedicated to providing content on a variety of topics, including industry news, best practices, software updates, continued education, tips and techniques, and much more.

Questions or comments about this article?

Tweet @Winshuttle to continue the conversation!