Liquid UI - WS Reference Library

Configuring guixt.sjs file


The settings of Liquid UI WS in a local implementation are present in the guixt.sjs file. (For Liquid UI Server, please see the Liquid UI Server documentation.)

The Liquid UI WS license key data is added in the relevant guixt.sjs file. In other words, the Liquid UI WS license resides in the Liquid UI WS guixt.sjs file. A sample guixt.sjs file is shown in Figure 1.

Figure 1: Sample guixt.sjs file

Parameters

The guixt.sjs file contains a number of parameters, described in the following table:

directory1 - directory4 = "C:\\directory\\directory";
  1. 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 the order of sequence. The directories can be either local directories or network/HTTP/FTP/SAPWR shares.

  2. 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"
    
usercatalog="C:\\Directory\\SubDirectory\\usercatalog.txt";
  1. The purpose of the User Catalog is to Assign/Change the Directory 1 of the Scripts based on the Group assignment for SAP User/Role.

  2. usercatalog = "C:\\Folder\\subfolder\\usercatalog.txt";
  3. UserCatalog File: //----- User Configurations // User groups: // make correspondence to 1-4 script directories.
    • M1 "C:\LiquidUI\Scripts\Directory"
    • M2 "\\network\Scripts\Directory"
    • M3 "SAPWR:Z.SAP_OBJECT"
    • XX None
  4. //User: Make correspondence to one user group. Because there is no '*' user designation, only specified users are allowed.
    • 200/USER1 M1
    • 300/USER2 M2
    • 200/USER3 M3
Key="Synactive.xxx.xxxxxx";
  1. 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

  2. Key="Synactive.xxx.xxxxxx";
license=[];
  1. 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 Installation topic or the WS Reference Library for more information.

  2. 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"]}}); 
history = "C:\\directory\\directory";
  1. Navigate to the path where you want the system to generate the script’s history.

  2. history = "C:\\LiquidUI\\History";
historyononlyguixt=true/false;
  1. This shows history information in form of popup. true --> This option displays popup history on Liquid UI (GuiXT) created controls. Native controls will exhibit the default behavior only. false --> This option displays popup history for both SAP and Liquid UI (GuiXT) controls

  2. historyononlyguixt = true;
    historyononlyguixt = false;
historyonrightbutton = true/false;
  1. This works in relation with historyononlyguixt parameter. The source of information depends on the boolean value. true --> This option displays localvaluehelp content from the text file in a popup window. false --> This option displays SAP help in a popup window

  2. historyonrightbutton = true;
    historyonrightbutton = false; 
domains="sapwr:z.domain";
  1. Any localvaluehelp domains would be specified in this parameter.

  2. domains = "sapwr:z.domain";
enablesystem="XXXX";
  1. 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:

  2. Single System - 
    enablesystem="XXX";
    Multiple System - use array
    enablesystem ["XXX", "YYY", "ZZZ"]; 
trimlabels=false;
  1. 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

  2.  trimlabels=false;
replication
  1. 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'. 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 local directory where the files will be replicated. directory1: The server directory where the files are located. You must also use the versionnumber command either in the ESESSION.SJS or the ELOGON.SJS file.

  2. replication = "yes";
    replication = "no"; 
rfcconnect
  1. There are two ways to write rfcconnect statements. The first is an array holding the RFC information for either a single user or multiple users. The second way to write the rfcconnect statement is as a string holding data for a single RFC user. Please see the rfcconnect section of the WS Reference Library for more detailed information.

  2. rfcuser = "xxx"; // RFC username. Always in plain text.
    rfcpassword = "xxx"; // RFC password. Used for both plain text and encrypted passwords.
     
rfctimeout
  1. rfctimeout is an option to set the time for the RFC call receive. By default, it takes 120 seconds. The RFC timeout is necessary as sometimes SAP's LIBRFC32.DLL does not come back. As a result, the other processes will be in kernel's waiting state and make other thread to not to own the call. To efficiently use the RFC calls and not to keep any other threads in waiting state after the thread termination, we have introduced RFCtimeout. Set the timer to rfctimeout to terminate the thread after it exceeds the timeout value.

  2. rfctimeout=n;
rfcdisconnect
  1. rfcdisconnect is an option to handle the RFC connections to and fro from the database. Beginning with the 1.2.286.0 the rfcdisconnect=value; must be placed in a separate statement instead of being contained in the rfcconnect statement. The rfcdisconnect parameter takes following values, 0 will keep the rfc handle until end of session. 1 will disconnect after every RFC call n will disconnect after n number of RFC call

  2. rfcdisconnect=0;
    rfcdisconnect=1;
    rfcdisconnect=n; 
rfcuser
  1. 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.

  2. rfcuser="rfc_userName";
rfcpassword
  1. 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.

  2.  rfcpassword="rfc_password";
rfcencryptedpassword
  1. rfcencryptedpassword is used to unencrypt the encrypted password for rfc connection.Beginning with the 1.2.286.0 the RFC encrypted password must be placed in a separate rfcencryptedpassword statement instead of being contained in the rfcconnect statement. Procedure: Generate an encrypted password of plain text password using any encryption technique. An encrypted password will be generated. Copy the encrypted password into the rfcencryptedpassword statement, which is located in the guixt.sjs file. This parameter can be edited using any text editor. Make sure the password is copied correctly, preserving uppercase, lowercase, special symbols, numericals, etc. The result would be an unencrypted password which is in turn used for making RFC calls.

  2. rfcencryptedpassword=”encrypted_password”;
rfcunencryptedpassword
  1. rfcunencryptedpassword is used to encrypt the password for rfc connection.

  2. rfcunencryptedpassword = "rfcpassword";
switchto
  1. 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 information, please see the switchto section.

  2. switchto = ["C:\\Folder\\subfolder\\guixt.sjs"];
dump
  1. If WS encounters a critical problem, it will create a dump file. 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. Note: These dump files can increase to the point where your hard disk's free space will be impacted. The number following the option name specifies how many dump files will be stored on your hard disk.

  2. dump=-1 --> This is the default value where new files will be constantly created and all older files will also be retain. dump=0 --> To prevent any dump file from being retain. dump=1 --> This will only retain the most recent dump file. dump=2 --> If the number is higher than one, then only the most recent n dumps will be retain depending on the number.

  3. dump=-1
    dump=0
    dump=1
    dump=2
TRACEFLAGS
  1. Traceflags are used for developer debugging. 0x00000000 --> This option disables Traceflags 0x00008000 --> This option opens the console 0x10008000 --> This option opens the console and prints the debug lines in the console 0x30008000 --> This option opens the console and prints the debug lines along with subclassing in the console

  2. TRACEFLAGS= 0x00000000;
    TRACEFLAGS= 0x00008000;
    TRACEFLAGS= 0x10008000;
    TRACEFLAGS= 0x30008000; 
logdirectory
  1. To create a folder to specify where you want the system to generate the log files. Beginning with 1.2.286.0 the logdirectory is the parameter of guixt.sjs file. Specify the desired location in the system so that the logs will be generated directly in that particular path.

  2. logdirectory = "C:\\LiquidUI\\Logs";
nolanguagekey = true/false;
  1. You can create *.sjs without specifying language identifier. This enables using same scripts across multiple languages. Liquid UI now searches the scripts without a language key. Example: Instead of "SAPMV45A.E0101.sjs" it reads the file "SAPMV45A.0101.sjs" [OR] instead of "ESESSION.sjs" it reads "SESSION.sjs".

  2. nolanguagekey = true;
_log = true/false;
  1. The log option is used to store debugging information.

  2. _log = true;
debug = true/false;
  1. The debug option is for debugging during development. This option enables you to debug the application when an issue takes place. To enable, debug = true;

  2. debug = true;
_blackbox
  1. To generate additional information in log files and dump files, _balckbox=true; should be added in guixt.sjs configuration file. WS Blackbox collect logs on Win32 exception WS Blackbox records more information

  2. _blackbox = true;

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();