Once GuiXT Mobile is installed on he target mobile device, there are a number of configurations that can be performed. In this section, we will explain each of these configurations. Topics covered are as follows:
Smart Attributes are special settings that the script editor attaches to a given edit field. There are four available smart attributes, as follows:
There are several keys that can be used for the various Smart Attributes. These keys and their associated values are as follows:
These keys are used as shown in the following examples:
To specify that an inputfields will contain a pattern of '??' with an Auto-Submit tcode of 'MM01' and a auto-tab delay of 3 seconds, we would use the following code:
inputfield (1,14) size=6 rf_pattern=?? rf_page_autosend=/nmm01 rf_autotab=3
To specify an inputfield with a pattern of '1080-* and an autotab delay of 2 seconds, we would write the following:
inputfield (2,14) size=16 rf_pattern=1080-* rf_autotab=2
To create an inputfield with a pattern of '????-01-????????' and an auto-tab delay of one second, we write the following:
inputfield (3,14) size=16 rf_pattern=????-01-???????? rf_autotab=1
To create an inputfield with a pattern of ??? and an autotab delay of one second, we write the following:
inputfield (4,14) size=16 rf_pattern=??? rf_autotab=1
To create an inputfield with a pattern of *bin and an autotab delay of three seconds, we write the following:
inputfield (5,14) size=16 rf_pattern=*bin rf_autotab=3
To create an inputfield without any pattern matching and an autotab delay of three seconds, we write the following:
inputfield (6,14) size=16 rf_autotab=3
To create an inputfield without any pattern matching or auto-tab, but with a validation tcode of 'MMBE', we write the following:
inputfield (7,14) size=16 rf_validate=/nmmbe
Pattern-matching is used to match input received from either a user or from scans performed by a barcode reader to a specific field on a page. This is useful because in normal usage, users would have to manually ensure that they are on the correct field. If the field is not correct, the user will have to manually tab or click to the field in question. On a handheld, where there is often no Tab key, this is inconvenient at best.
However, pattern-matching enables a script to mark a field as containing a specific pattern of alphanumeric characters. GuiXT Mobile can then check the input against the patterns for each field and place the correct input in the desired field automatically. The way this works is that once a user enters input, the Mobile application will search each field for a match to the patterns contained in the user entry. Once a match is found, Mobile will enter the data matching the field pattern into the field in question, replacing any existing data. If no fields with matching patterns are discovered, the application will return an error in the Status bar at the bottom of the screen.
The user typically will execute a 'done entering text' action to signify that he or she is finished entering data. This action can take a number of forms. Some common examples are pressing the Tab or Enter key or moving the cursor into another field. Actions that change an attribute but do not cause any action to occur, such as selecting a radiobutton or checking a checkbox also are actions that will send the 'done entering text' signal to Smart Attributes. In addition to the actions that send the 'done entering text' signal, there are also some user actions that will override the Smart Attributes instead of performing them. These actions are typically those that are intended to cause an action to occur and therefore should not be interrupted by the Smart Attributes. Examples of these are as follows:
The variables used to define a particular pattern for a field are as follows:
See the following example:
Example: A page contains three fields with the following patterns:
The user will enter the following input, separated by a tab:
Result: GuiXT will automatically input the following based on the patterns associated with each field:
The Validation Smart Attribute determines whether or not the input entered by a user is valid. This determination is performed by matching the user input to the application's criteria for determining valid and invalid input. For example, if the valid input for a given field is restricted to numeric characters and the user enters alphabetic characters, the validation will fail for that particular field and return a message so informing the user.
When SAPGUI is used, the validation process is normally performed when a page is submitted to the SAP application server. However, individual fields can be validated prior to this step by marking them for validation. Marking a field for validation informs the application that the field should be validated immediately following any pattern-matching. The validation process is usually triggered by a 'done entering text' signal, as defined in the preceding Pattern-Matching section. If a single field is to be validated, the application displays a 'post-validation' screen. This can be either the previous screen with the user input or an entirely different screen. When an entire page is displayed, the post-validation screen does not appear- instead the ensuing screen in the process will display instead.
Any screens that already contain text are assumed by Mobile to be already validated. However, if any input is altered or modified by a user, then the field will be re-validated when the page is submitted for validation.
The validation process is mostly transparent to the user. When the 'done entering text' signal is transmitted, the screen will clear and the validation will be performed by the script. The author of the script can specify a number of variable actions, such as the following:
Screen to display when validation is complete
Field to have focus in post-validation screen
In addition, script authors can specify transaction codes, function codes (Fcodes) and internal Fcodes. In the case of Fcodes or internal Fcodes, the script author can identify the Fcodes and perform validation on the input.
The Auto-Tab smart attribute is designed to eliminate the necessity for users to manually tab after entering data into a field. While it can be used for situations where users are manually entering text, the most common usage is with bar-code readers where field entry is performed by doing a scan.
In either case, the value embedded in the Auto-Tab smart attribute specifies a delay time in seconds. The counter begins and resets when any character is entered into a field marked with this attribute. The way it works is that once a character is entered, Mobile will automatically tab to the next field when the delay time is passed. For example, if the Auto-Tab has a delay time of five seconds, then five seconds after the first character is entered, Mobile will automatically tab to the next field. Mobile automatically dete4cts whether a barcode is or is not being performed. If a barcode scan is performed, Mobile will auto-tab to the next field one second after the scan is completed regardless of the value specified for the Auto-Tab attribute. If there is a significant pause in the data entry (currently set at five seconds), Mobile will assume the user is done entering text on that field, but will not tab to the next field.
Since Auto-Tab is treated the same as a 'done entering text' signal, pattern-matching and validation can also be performed on the fields after an Auto-Tab occurs.
The Auto-Submit smart attribute is designed to execute a transaction code or function code after entering all data into all the fields on a specified page. It can be used for manual typing, but it is most commonly used in situations where barcode readings are being scanned. If any field on a given page is marked with the Auto-Submit attribute, then Mobile will automatically execute the transaction or function codes assigned to the attribute as long as all fields on the page contain valid input.
Because Auto-Submit takes place only when all fields on a given page contain valid entries, it can only occur after both pattern-matching and validation are performed. It is also mostly transparent to the user. Once pattern-matching and validation are performed on the screen in question, the script will clear the current screen, catch the instructions contained in the Auto-Submit attribute and then a new screen which can be either the same screen or a different screen will appear. The script author can specify what actually will occur when Auto-Submit is performed.
In order to connect to SAP, it is necessary to create a connection on the Mobile device. To create a connection to a SAP application server, please do the following:
It is convenient to have user profiles in order to utilize GuiXT Mobile. Profiles enable users to perform auto-logon as well as specify different SAP ERP systems. To create a new profile in GuiXT Mobile, please do the following:
There may be times when it is necessary to lock down the SAPLOGONPAD. To lock down the logon pad, first ensure that a default connection is set and that the GuiXTMobile.sy3 file attribute is set to 'read-only. Once these two actions are complete, please do the following:
It is possible to configure GuiXT Mobile so that the idle-time auto-logout is suppressed and the device will always stay connected to the SAP ERP application server. Based on the Server Detection Timeout setting defined in the Help section, constant network traffic to the SAP will be generated, resetting SAP's auto logout timer and ensuring the device remains connected.
In order to suppress the idle time auto-logout, users must have a profile for the specified connection to the SAP application server. Creating a profile is explained in detail in the Creating Profiles section of this document.
Once a profile is configured for the connection in question, please do the following in order to suppress the idle time auto-logout.
