Search

Login Enterprise Script Editor

Overview

The Login Enterprise Script Editor is a tool designed to assist administrators in creating custom application workflows. These workflows can be seamlessly incorporated into various testing scenarios, including Application, Load, and Continuous Tests. By leveraging the Script Editor, administrators can streamline test creation and execution, ensuring comprehensive and efficient testing processes tailored to specific application requirements.

Starting from Login Enterprise 5.10, the Script Editor comes with v1 of the Script Editor, capable of recording WinApps. To learn more about the Script Recorder, its use cases, benefits, and more, see the Script Recorder.

Benefits of using the Script Editor

The Login Enterprise Script Editor offers several key benefits for administrators:

  • Efficient workflow creation: Simplifies the creation of custom application workflows, whether creating new scripts or modifying existing ones.
  • Debugging tools: Provides in-line syntax error detection and a comprehensive Error List for efficient debugging.
  • IntelliSense support: Enhances scripting accuracy with context-aware suggestions and auto-completion of the Login Enterprise native commands.
  • Integrated Script Recorder: Includes a built-in Script Recorder for capturing and automating user interactions, enhancing script development efficiency.
  • CLI Automation with // TARGET: Comments: Facilitates Command Line Interface (CLI) automation by using // TARGET: comments in conjunction with the Script Recorder.
  • Application type flexibility: Supports both executable and browser-based applications, with options to customize scripts according to specific testing needs.
  • Standalone and portable: The Script Editor is standalone and portable, allowing it to run off a network share without needing installation.
  • Simpler and cleaner UI: Compared to Visual Studio (Code) (VSCode), the Script Editor has a simpler and cleaner user interface.

While you may still prefer using Visual Studio Code (VSCode), our Script Editor is designed to provide a more integrated and supported experience. Although you can still use VSCode for scripting, it is not officially supported, and continued functionality is not guaranteed. For those who wish to use VSCode, see Installing prerequisites for application scripting. However, we recommend using the Script Editor for the best results.

Requirements

  • Windows 8 and later
  • Windows server 2012R2 and later
  • .NET Framework 4.6.1

Downloading and installing the Script Editor

1. In the Login Enterprise sidebar menu, navigate to Configuration > Applications.

Frame 217.png

2. In Applications > Download Script Editor, click Download on the top right (the file with the integrated Script Recorder will start downloading immediately).

Frame 388.png

3. Extract the contents of the zip file onto your machine.

4. Open the folder and run the ScriptEditor.exe file.

Frame 220.png

When you click on the .exe file, a blue window may appear advising you not to run the file. This warning may be due to the file being unrecognized or from an unknown source. To proceed and run the file, click More info, and then Run anyway.

Script Editor functionality breakdown

At the top of the editor, you will find several options:

  • New: Creates a new application script.
  • Open: Opens an existing application script.
  • Save: Saves the script. A "Save As" option is also available from the drop-down menu.
  • Run: Saves and executes the script against your target application.
  • Stop: Stops the script execution.
  • Record: Records interactions with the target application to generate a script automatically. For more information, see Starting the recording: recording the script.
  • Run and record: Allows you to execute an already created script and then automatically opens the recorder at the end of the script, enabling you to continue recording from where it previously left off. For more information, see Run and continue recording. 
  • Properties: Allows you to change the properties defined when creating the application.
  • Application X-Ray: Opens Application X-Ray to analyze the target application.

Frame 498.png

From the options menu (…), there are additional choices:

Frame 391.png

Creating a new Application script

When starting the Script Editor, you can create a new Login Enterprise application or open an existing Login Enterprise application.

Frame 390.png

Application type

Selecting "Create a New Login Enterprise Application" prompts a new window where you need to provide the following details:

  • Script Location: Specifies where the application script should be saved.
  • Application Type: Choose between "Executable" or "Browser."
  • Target: Enter the path to the executable you wish to test.
  • Start in: Specifies the working directory for the application script.

Frame 393.png

Browser type

If you select the "Browser" option, you need to specify:

  • Browser Type: Choose from supported browsers:
    • Chrome
    • Edge (v44, v42 are deprecated)
    • Firefox
  • URL: Provide the URL to be loaded when launching the browser.
  • Profile location (Optional): This option enables custom paths for storing browser profiles. This is helpful for specific configurations, often for centralized management or compliance needs. For more information, see the Non-default profile paths.

Frame 470.png

Using // TARGET: comments for CLI automation

You can leverage command-line parameters and arguments to automate application tasks. This section explains how to use the // TARGET: magic comment to specify the target application, its executable path, command-line arguments, and environment variables. It covers both legacy behavior and recent enhancements.

Why use // TARGET: comments?

Using the // TARGET: comment in your scripts allows you to:

  • Specify executable paths: Define the exact path to the executable you want to run.
  • Pass command-line arguments: Include additional parameters or options needed by the executable.
  • Utilize environment variables: Leverage system environment variables to create more portable and adaptable scripts that work across different systems and configurations.
  • Maintain compatibility: Ensure scripts work seamlessly across different systems while incorporating new Script Recorder features.

Understanding the "magic comment" // TARGET:

The // TARGET: comment is pivotal for specifying the application to invoke, allowing you to define the executable path and any associated arguments within your script.

Format for // TARGET:

General syntax:

// TARGET: path_to_executable [options] [arguments]

Note there's an option to have the executable path encapsulated or not in double quote characters.

For example:

// TARGET:"%ProgramFiles%\Microsoft Office\root\Office16\EXCEL.EXE" /t "%ProgramFiles%\TestExcel.xlsx"

The following example is acceptable and will also work. The .exe path doesn’t have double quotes around it, even though the path includes a space character:

// TARGET:%ProgramFiles%\Microsoft Office\root\Office16\EXCEL.EXE /t %ProgramFiles%\TestExcel.xlsx

Clarifications:

  • There has been no change in how the target path is handled in the target engine, Script Editor, or Application X-ray compared to previous versions.
  • The Script Recorder now supports invoking the defined target app with command line options.
  • The initial target app path can optionally have double quotes around it, even if it contains spaces. For consistency and clarity, it is recommended to always use double quotes around paths with spaces in example code blocks.
  • Any argument or path after the initial target app path must have double quotes around it if it contains spaces. This ensures the command line is parsed correctly.

Example with optional quotes around the executable path:

// TARGET:%ProgramFiles%\Microsoft Office\root\Office16\EXCEL.EXE /t "%ProgramFiles%\TestExcel.xlsx"

Example with quotes around the executable path:

// TARGET:"%ProgramFiles%\Microsoft Office\root\Office16\EXCEL.EXE" /t "%ProgramFiles%\TestExcel.xlsx"

Both examples above are valid, but for clarity, we recommend using double quotes around paths with spaces.

Using environment variables

Environment variables are placeholders that automatically resolve to specific paths or values within the operating system environment. For instance, %ProgramFiles% resolves to the Program Files directory in Windows.

Adding command-line options and arguments

Command-line options modify the behavior of the executable. These can range from simple flag options, e.g. -v for verbose mode to key-value pairs, e.g. --output=filename.

Practical examples

Here are examples demonstrating the use of command-line options and environment variables:

Example 1: Launching an application with environment variables:

// TARGET:"%ProgramFiles%\Microsoft Office\root\Office16\EXCEL.EXE"

This launches an application using predefined environment variables for paths.

Example 2: Opening a file in Excel with command-line options:

// TARGET:"%ProgramFiles%\Microsoft Office\root\Office16\EXCEL.EXE" /t "%ProgramFiles%\TestExcel.xlsx"

This opens a specific Excel file using Excel with command-line options.

Example 3: Running a script with environment variables and options:

// TARGET:"%ProgramFiles%\MyApp\myapp.exe" --config="%AppData%\MyApp\config.cfg" --verbose

This launches an executable with a configuration file and enables verbose mode using environment variables.

Specifying the "Start in" path

In addition to defining the executable path and command-line arguments, you can specify the working directory of the executable using the "Start in" path. This path indicates where the executable should run from and is crucial for applications that rely on relative paths.

Example of specifying the "Start in" path:

// START_IN: "%ProgramFiles%\MyApp"

This sets the working directory for the executable to the specified path, ensuring that any relative paths used by the application are resolved correctly.

Best practices

  • Consistent naming: While the specific names for command line arguments and options are determined by the developers of the target applications, e.g. /t for Microsoft Office, ensure that any custom parameters or arguments you define within your scripts are clear and consistent.
  • Quotation usage: Encapsulate paths and arguments in double quotes to handle spaces correctly.
  • Help messages: Include comments or help messages within your script to guide users on using // TARGET: effectively.
  • Testing: Validate // TARGET: paths and arguments thoroughly before distributing scripts to ensure functionality across different environments.

Designing Application scripts

After creating your first application, you will be presented with a default template that you can use as a foundation for building your script.

We recommend utilizing the Login Enterprise Script Recorder or Application X-Ray for scripting your applications.

However, for scenarios where the Script Recorder or Application X-Ray might not suffice, the Script Editor provides IntelliSense for the Login Enterprise native commands. This feature simplifies the creation process by offering context-aware suggestions and guidance.

Frame 395.png

Debugging with the Script Editor

Syntax errors are identified both in-line within the script and listed in the Error List at the bottom of the Script Editor interface.

Frame 396.png

Once you execute your script, the debug output will comprehensively display all actions performed by our engine.

Frame 397.png

All in all, the Script Editor is a powerful tool for administrators, offering essential features to create, debug, and optimize custom application workflows. Built-in capabilities like syntax error detection, IntelliSense, and detailed debug outputs, along with the integrated Script Recorder, support efficient script development and troubleshooting within the Login Enterprise environment.

Verbose logging

To enhance debugging, you can enable the verbose logging option to include line numbers in the debug output. For this:

In the Script Editor, select the Verbose Logging checkbox.

Frame 497.png

The debug output will display the script line that encountered the error whenever the script fails. For example, see the screenshot below:

Frame 503.png

Note that enabling verbose logging may affect script runtime.