Shared Scripting

This shared scripts feature lets you create code snippets that you can reuse for multiple rules, and simplify your script rule code.

In this topic:

Shared Scripts

The Solution pane in the Service Virtualization project includes an folder called Shared Scripts. Within this folder, you add C# or JavaScript files through the context menu.

You can create new scripts or download existing scripts from the Internet that meet your requirements.

Once you create a shared script file, it is stored inside the project folder along with other Service Virtualization files. If you store the project in ALM, the shared scripts will be stored with the project.

You can use SV Designer or an external tool such a Visual Studio, to edit a shared script file.

When working with C#, you add a new class.

For JavaScript, you add new functions with an explicit directive to make them available from script rule.

Back to top

Sharing Objects

To share custom objects between multiple operations or services:

1. Define them in the shared script.

2. Store them in the context.

3. Retrieve them using the TryGetDeserializedValue() method on a particular context.

   This method performs binary serialization/deserialization to avoid class cast problems. For more information, see the API documentation for HpsvContext class.

Back to top

Create a Shared Script

To create a shared script:

1. In the Service Virtualization project's Solution window, select Shared Scripts node and choose Add New File > C# File or JS File.
2. If you already have a script you want to share, simply choose Add Existing File and locate your file.

3. For a new shared script, add at least one function. For example, for Javascript:

   Example:
   function pageHeaderScripts()
   {
    return 'Hello';
   }

4. For Javascript, make it available externally. For example:

   Example:
   module.exports.pageHeaderScripts = pageHeaderScripts;

5. In the Data Model editor, select Script > Insert Script and choose the shared script. This adds an internal directive to the rule to deploy the shared script with the virtual service and also make this functionality available within the rule. For example:

   Example:
   //#svinclude="./pageHeaderScripts.js"

   var pageHeaderScripts = require("./pageHeaderScripts.js")

6. Modify the scripts if necessary, for example by removing the functionality performed by the shared script.

Back to top

Use Case 1 - Remove repeated code

In this first use case, the shared scripting feature lets you remove repetitive code that appears in several rules, and reuse it using a shared script.

For example, when you realize that you need the same function in multiple rules, extract it to a shared script and reference it from all of the rules.

Back to top

Use Case 2 - Use public libraries

In the second use case, you can further simplify your code by using public libraries to do common tasks. These library functions have been tested and are usually less prone to errors.

To use public libraries:

1. Download the libraries, and add the relevant files to the Shared Script folder in the Solution Explorer.
2. If you are working with JavaScript, edit the files to make the function available to external files, as described above.
3. In the Data Model editor, add the shared script : Script > Insert Script.
4. Substitute your manual code with the function from the public library file.

For example, let's say you have a line of code in your rule:

This code uses your in-house function getTenDaysFromNow() that gets the date in ten days time. In a public library you found a function that does the same thing, called moment().add(). Substitute that function call instead of yours.

Back to top

Use Case 3 - Data Model Manipulation Helper

In this use case, you simplify your code by taking segments of code that appear in your rule, and creating a function. This is especially useful when you know that certain values do not change often, such as page titles.

For example, let's say you have a line of code in your rule:

Create a new shared script that defines the string as a function:

Once you create this shared script, modify your rule:

Back to top

Tips and Guidelines

• Do not use svinclude directives inside shared scripts; they are ignored. Instead, specify which other files to use within your scripted rule. They are compiled together with the scripted rule.
• A newly created JavaScript has an initial content. This content is a JavaScript module that can be included in other JavaScript code using the standard 'required' JavaScript keyword. A JavaScript module needs to declare which parts of the code it is making public. If you want to make it accessible to the public you need to add an export directive, for example module.exports.new_script = new_script. For details, see Create a Shared Script.
• A newly created C# code file contains a dummy C# code class. You can remove it altogether and write your own. There are no special requirements on the C# file content. It is like any project file that you add to your C# Visual Studio project.
• To use a JavaScript shared script in a scripted rule you need to specify a special directive: //#svinclude="./new script.cs". You can add this manually or choose Script > Insert Script in the Data Model editor and choose the files to include. If you have many files, the manual option may be easier with a copy-paste. This directive instructs the Designer to include this script when compiling the code for this scripted rule. When inserting a script using the Insert Script menu item, additional code is generated to make the script available to the rule. For example, var new_script = require('./new script.js');. This is the most common way to make external code accessible in the scripts.
• When saving a scripted rule, the code gets compiled with the included shared scripts. The console displays errors along with hyperlinks that link to where the error was detected. This may be inside the scripted rule itself, or inside some of the included script files.

Back to top