guixt.sjs

Parameters

The guixt.sjs file contains a number of parameters, which are defined as follows:

directory1 - directory4 = "C:\\directory\\directory";

This entry defines the script directories where GuiXT WS will search for script files. Users can have up to four directories specified and these are searched in order. The directories can be either local directories or network/HTTP/FTP/SAPWR shares. The syntaxes for each type of storage location are as follows.

• Local directories:

  directory1= "C:\\guixt\\scripts";

• Network directories:

  directory1 = "\\\\server\\directoryName";

• Web directories:

  directory1 = "http://server//directoryName";

• FTP directories:

  directory1 = "ftp://server//directoryName";

• SAP Web Repositories:

  directory1 = "sapwr:z.guixt.demo"

Key="Synactive.xxx.xxxxxx";

For all releases prior to March 2011, the actual license key for the various components would be entered following the 'Key' parameter in the guixt.sjs file. This parameter is not used in post-March 2011 releases. Please consult the license=[]; entry below. The pre-March 2011 format is shown below:

Key = "Synactive.xxx.xxxxxx" 

license=[];

For all WS releases subsequent to March 2011, the license key will be in the array format. Multiple individual license keys can be included in this format. Please consult the Licensing section of the WS Install Guide or the WS Reference Library for more information. The format is shown below.

license = [ ];
  license.push({"license":"x-xxxx-xxxxx-x-xxxx-xxxxx-xxxxx", "data":{"company":"company1", "systemid":["systemid1"]}});
  license.push({"license":"x-xxxx-xxxxx-x-xxxx-xxxxx-xxxxx", "data":{"company":"company2", "systemid":["systemid2"]}});
			

historyononlyguixt=true/false;

When this option is present, popup history will function only on GuiXT-created controls. Native controls will exhibit the default behavior only. If this option is not present, popup history will be available for both SAP and GuiXT controls. This option's syntax is as follows:

historyononlyguixt = true;

domains="sapwr:z.domain";

Any localvaluehelp domains would be specified in this parameter. An example is as follows:

domains = "sapwr:z.domain"

enablesystem="XXXX";

This option specifies that only the listed SAP system will be active. If a single system is listed, a statement is used as in the following example:

enablesystem="XXX";

However, if multiple systems are listed, an array will be used as shown below:

enablesystem ["XXX", "YYY", "ZZZ"];

trimlabels=false;

This option is for ensuring that when a screen control is moved closer to the label, the label is not overlapped by the screen control. This is particularly important for edit fields. Trimlabels are turned on by default in WS, but if a user wishes to turn it off, he or she can turn off trimlabels by adding the 'trimlabels=false;' parameter to the guixt.sjs file as shown below:

trimlabels=false; 

replication

The replication parameter specifies if file replication is active or not. File replication will function by copying files located on a central server onto a local machine. The first time this local file copy is accessed during a new SAP session, GuiXT will check the time stamp and compare it with the update time on the server. If the server file is newer, the file will be re-loaded from the server. But on all subsequent occasions that the file is accessed during the session, it will be read locally. To activate file replication, users can specify either 'yes' or 'no' as shown in the following examples:

replication = "yes";
			replication = "no";
			

Note:

In order for replication to function correctly, you must have a valid rfcconnect statement in the guixt.sjs file. The rfcconnect statement must include the following information:

• rfcuser: The user name for the RFC connection.
• rfcpassword: The password for the RFC connection.

You must also define following parameters in the guixt.sjs file:

• directory0: The server directory where the files are located.
• directory1: The local directory where the files will be replicated.

You must also use the versionnumber command either in the ESESSION.SJS or the ELOGON.SJS file.

rfcconnect

There are two ways to write rfcconnect statments. The first is an array holding the RFC information for either a single user or multiple users. Please see the rfcconnect section of the WS Reference Library for more detailed information. The RFCConnect array will take precedence over either the guixt.sjs RFC single user entry explained below or over a RFCUser statement contained in a Call command. The Call command usage is explained in the WS Reference Library.

Note: Beginning with WS release 1.2.157.0, the username and password are no longer required for an rfcconnect statement. Instead, this data is read from the rfcuser and rfcpassword entries in the guixt.sjs file.

rfcconnect

The second way to write the rfcconnect statement is as a string holding data for a single RFC user. This is the weakest of the three RFC calls - both the array explained previously and any RFC user data contained in a Call command will take precedence over the single RFC user data. This has three components, which are as follows:

• rfcuser = "xxx"; RFC username. Always in plain text.

• rfcpassword = "xxx"; RFC password. Used for both plain text and encrypted passwords.

rfcuser

Defines the username for a remote function call. Beginning with 1.2.157.0, the RFC username must be placed in a separate rfcuser statement instead of being contained in the rfcconnect statement. The syntax is as follows:

rfcuser="rfc_userName";

rfcpassword

Defines the password for the rfc connection. This can be either encrypted or in plain text. Beginning with 1.2.157.0, the RFC password must be placed in a separate rfcpassword statement instead of being contained in the rfcconnect statement. The syntax is as follows:

rfcpassword="rfc_password";

switchto:

The switchto command enables users to map a user's individual guixt.sjs file to a main guixt.sjs file hosted on a server. For more infomration, please see the switchto section.

components = {"component1":1, "Component2":1, "Component3":1};

List of installed components. Any installed component will be in this list and marked '1' to indicate that it is present and active.

Note: Please note that this parameter is not necessary for post-March 2011 WS releases.

dump

If WS encounters a critical problem, it will create a dump file. These dump files can increase to the point where your hard disk's free space will be impacted. Beginning with WS release 1.2.180.0, the guixt.sjs file has an option to set the number of dump files that are retained on your hard disk. The syntax is as follows:

dump=1;

The number following the option name specifies how many dump files will be stored on your hard disk. If the number is higher than one, then only the most recent dumps will be retained. For example, if the setting is 'dump=2', then the most recent previous dump will be retained, when a new dump file is created. If the setting is not present in the guixt.sjs file or if the setting is the default (dump=-1;) new files will be constantly created and all older files will also be retained. To prevent any dump files from being retained, set the dump option to dump=0.

TRACEFLAGS

Traceflags are used for developer debugging. This option should normally be set to 'FLG_REDIRECT_CONSOLE' in order to display logs. An example is shown below:

TRACEFLAGS = FLG_REDIRECT_CONSOLE;
			FLG_REDIRECT_CONSOLE = 0x00008000;
			

Dynamically changing script directories and files

In previous versions of GuiXT WS, you had to define script directories manually in the guixt.sjs file. Once a new directory was specified in the guixt.sjs file, you would have to stop GuiXT WS and then restart it for the changes to take effect. However, in all WS releases since build 1.1.98.0, this is no longer necessary. In current releases of WS, you can specify a new script directory directly into the transaction field. THe syntax is as follows:

/n[tcode]/dX=C:\\directoryName

The script directory is specified by the 'dX=' part of the code where 'X' is set to 0-4. The numbers specify the script directories as in the following examples:

/nva01/d0=c:\\guixt\\newdirectory0
/nva01/d1=c:\\guixt\\newdirectory1
/nva01/d2=c:\\guixt\\newdirectory2
/nva01/d3=c:\\guixt\\newdirectory3
/nva01/d4=c:\\guixt\\newdirectory4
		

In SAP GUI, this would look as shown in the following example:

The command can also be used to specify a new script for a given transaction, as in the following example for the VA01 transaction:

/nva01/f=newva01.sjs

This functionality is available anywhere so it can also be performed as an enter command within a script as shown in the following example.

onscreen 'SAPMV45A.0101'
/nva01/f=newva01.sjs
enter();