Accessing Content Services (deprecated) using Web Scripts

Remarque : Adobe is migrating Adobe® LiveCycle® Content Services ES customers to the Content Repository built on the modern, modular CRX architecture, acquired during the Adobe acquisition of Day Software. The Content Repository is provided with LiveCycle Foundation and is available as of the LiveCycle ES4 release.

LiveCycle Content Services (deprecated) lets you interact with it by using web scripts. Using web scripts, you can perform tasks such uploading, managing, deleting, and cross-linking content that is stored in Content Services (deprecated). Web scripts perform operations on data in various file types, including PDF files, XML files, and XDP files. For example, consider the PDF document shown in this illustration.

Using a web script, you can, for example, delete the MortgageForm.pdf file from a Company Home/Test Directory. Likewise, you can place a new PDF document in this location. (See Creating a web script that uploads files.)

Web scripts allow content that is located in Content Services (deprecated) to be accessible to external client applications, such as a web application. Each web script is bound to an HTTP method and custom URL. You can develop a library of web scripts to provide a set of HTTP APIs that can perform multiple tasks. That is, you can access different URLs from the same client application, where each URL executes a different web script that performs a specific task.

To create a web script, you require some knowledge of JavaScript™ and FreeMarker templates. However, you do not need to know Java or .NET programming. Web Scripts are invoked by using simple URL calls. That is, using a web script, you can delete a PDF file that is located in Company Home/Test Directory by using a URL such as:

  • http://[host]:[port]/contentspace/service/sample/deletedoc

    Remarque : The deletedoc web script is an example of a custom web script that is created in this section. (See Creating a web script that deletes files.)

    Likewise, to list the contents of the Company Home/Test Directory, use an URL such as this one:

    • http://[host]:[port]/contentspace/service/sample/folder/Company Home/Test Directory

Web script components

A web script consists of the following components:

  • Description document: Describes the URL that invokes the web script. The description document specifies the script name, the URL that is used to invoke the web script, a description of the web script, and authentication information. (See Creating a description document.)

  • Execution script: A script that written in JavaScript that performs the specific task. For example, an execution script can delete a PDF file from a specific location, such as Company Home/Test Directory. (See Creating an execution script.)

  • Response templates: Renders output in the correct format (for example, HTML, ATOM, XML, RSS, JSON, CSV, or any combination of these file types). The URL response is rendered by using one of the supplied templates where the chosen template is based on the required response content-type or status outcome. The template has access to all URL arguments, common repository data entry points, and any data items built by the execute script. (See Creating a response template.)

Web script component interaction

This illustration explains how web script components interact together.

The following table describes the steps in the above illustration.

Step

Description

1

The URL that contains the request arrives at the web script REST dispatcher.

2

The dispatcher finds the appropriate web script for the specified URL. If one is found, the dispatcher invokes the web script but only after successfully authenticating first (if necessary).

3

With JavaScript, you have access to Content Services (deprecated) content. For example, you can search for information, navigate around the repository, modify information, create new documents, set properties on those documents, move content to another location, and delete data.

You cannot use JavaScript to invoke LiveCycle operations that are supported by Content Services (deprecated) such as StoreContent. These operations are available using Workbench. (See Using Workbench.) After you create a process that invokes Content Services (deprecated) operations, you can invoke the process using a client application. For information, see Programmatically accessing LiveCycle Content Services (deprecated).

4

The results from the JavaScript are rendered by using FreeMarker response templates. The response format can be HTML, ATOM, XML, RSS, JSON, CSV, or any combination of these file types. You must provide the appropriate templates.

5

The web script dispatcher sends the rendered results back using a response using the same web protocol as the URL request.

6

The web script client receives the response in the request format.

Creating your first web script

Writing a web script consists of creating all components that a web script requires. You must create an XML description document, an execute script written in JavaScript, and a response template.

To create a web script, perform the following steps:

  1. Write the web script. (See Writing the web script.)

  2. Store the web script. (See Storing web scripts.)

  3. Register the web script. (See Registering web scripts.)

  4. Invoke the web script. (See Invoking web scripts.)

Writing the web script

Before you write a web script, decide which URL and HTTP method to use. A web script URL must start with http://[host]:[port]/contentspace/service/sample. The remainder of the URL is flexible, but it must be unique. For example, consider this URL:

  • http://[host]:[port]/contentspace/service/sample/folder/Company Home/Test Directory

    To demonstrate how to create a web script, this section creates a web script that lists the contents of a specified directory. To create this web script, create the following files:

  • A description document named folder.get.desc.xml. (See Creating a description document.)

  • An execution script named folder.get.js. (See Creating an execution script.)

  • A response template named folder.get.html.ftl. (See Creating a response template.)

Creating a description document

The first step is to create an XML description file that describes the URL used to invoke the web script. The postfix .desc.xml informs Content Services (deprecated) that this script is a web script description document. Consider the following folder and file name:

service/sample/folder.get.desc.xml

Part of this URL defines the package, the service identifier value of folder, and a binding to the HTTP Get method. That is, the get part of the URL specifies that the HTTP GET method is used to invoke the web script. Likewise, to invoke the web script by using the HTTP POST method, the name needs to be folder.post.desc.xml.

The folder.get.desc.xml file consists of the following XML code.

<webscript> 
      <shortname>Folder Listing Sample</shortname> 
    <description>Sample demonstrating the listing of folder contents</description> 
    <url>/sample/folder/{path}</url> 
    <format default="html">argument</format> 
    <authentication>guest</authentication> 
    <transaction>required</transaction> 
</webscript>

To invoke this web script, specify the following URL:

http://<host>:<port>/contentspace/service/sample/folder/Company Home/Test Directory

The following list describes the elements in this XML file:

  • shortname: Represents human readable name for the web script.

  • description: (Optional) Represents a description for the web script.

  • url: Represents a URL that the web script is bound to. There can be more than one url element.

  • format: Represents how the required response content type is declared. These values are valid:

  • argument: specifies that the required content type is declared by using the format URL argument (for example, /search?q=tutorial&format=atom).

  • extension: specifies that the required content type is declared by using the URL extension (for example, /search.atom?q=tutorial).

  • any: specifies that either of the above is supported (this is the default).

    Remarque : If the URL does not specify a required content type, the default content type is taken from the (optional) default attribute of the format element. By default, if not set, the “html” format is assumed. In some cases, a URL may decide on a response content type at run time. For these URLs, specify an empty format (for example, format="").
  • authentication: Represents the required level of authentication. These values are valid:

    • none: Specifies that no authentication is required (this the default value).

    • guest: Specifies that at least guest authentication is required.

    • user: Specifies that at least named user authentication is required.

    • admin: Specifies that at least a named admin authentication is required.

  • transaction: Represents the required level transaction. These values are valid:

    • none: Specifies that no transaction is required.

    • required: Specifies that a transaction is required (and will inherit an existing transaction, if open).

    • requiresnew: Specifies that a new transaction is required.

    Remarque : If not specified, the default value is none if authentication is also none; otherwise, the value is required.

URL templates

A URL template contains tokens that can be substituted with actual values. Common types of a URL template include the following:

    /content/a/b/c/d.txt /blog/search?q={searchTerm} 
    /blog/search?q={searchTerm}&amp;n={numResults} 
    /blog/category/{category}?n={itemsperpage?} 
    /user/{userid}

A token of the form {<name>?} means that it is optional. Typically, tokens are used for URL arguments, but can also be used for path segments.

Remarque : The third example passes two parameters to the web script. Usually, an ampersand (&) is used to separate parameters. Although, in your template, one must use the escaped literal &amp; instead.

Web scripts do not currently enforce mandatory arguments. URL templates are specified relative to http://[host]:[port]/contentspace/service.

URL sections used for binding

When a URL request is made, Content Services (deprecated) locates the appropriate web script by finding the closest match to a URL template in a web script description document. The part of the URL template that is used for matching is the static part from the start of the URL template up to either the URL arguments or the first path token, whichever comes first. For example, URL templates are matched on the following:

    /content/a/b/c/d.txt (exact match) 
    /blog/search (starts with match) 
    /blog/category (starts with match) 
    /user/ (starts with match)

The following URLs match one of the above URL:

    /content/a/b/c/d.txt 
    /blog/search 
    /blog/search?q=tutorial 
    /blog/category 
    /blog/category/web20 
    /user/fred 

However, these URLs do not match:

    /content/a/b/c/d.txt.plain 
    /blog 
    /usr/fred

Response formats

A web script supports a default response format, which is a web script registered short name for a MIME type/subtype (for example, application/atom+xml). A web script can support multiple response formats. In this situation, it is necessary to determine which format to respond with when a web script URL is requested.

When the format is not specified in the URL, the default response format is returned. These formats are available:

  • html - text/html

  • text - text/plain

  • xml - text/xml

  • atom - application/atom+xml

  • rss - application/rss+xml

  • json - application/json

  • opensearchdescription - application/opensearchdescription+xml

  • mediawiki - text/plain (Media Wiki markup)

Creating an execution script

An execution script is written in JavaScript and performs tasks such as querying or updating content. An execution script has access to objects such as these:

  • argsM: An array of URL parameters (where each key is a parameter name and each value is an array that contains the parameter values, even if only one is supplied.

  • url: Provides access to the URL (or parts of the URL) that invoked the web script.

  • formdata: Provides access to multipart/form-data requests that allow the upload of files using by using web scripts.

  • model: An empty array that may be populated by the web script. Values placed into this array are available as root objects in web script response templates.

  • roothome: Repository root node.

  • guest: Boolean indicating whether the web script is executing as Guest.

  • server: An array of metadata properties that describe the repository server hosting the web script.

Remarque : For a list of objects that an execution script can access, see Understanding web script root objects.

The following JavaScript code displays all content within a specified directory. The following script represents the code located in the folder.get.js file. (See Creating your first web script.)

// locate folder by path 
// NOTE: only supports path beneath company home, not from root 
var folder = roothome.childByNamePath(url.extension); 
if (folder == undefined || !folder.isContainer) 
{ 
    status.code = 404; 
      status.message = "Folder " + url.extension + " not found."; 
      status.redirect = true; 
    } 
    model.folder = folder;

Execution script file names have the following structure:

  • [serviceId].[httpMethod].js

    The folder.get.js file specifies that the name of the web script is folder and the http method is GET.

Response status

Web scripts use HTTP response status codes to inform a client application of an error situation (such as item not found), an occurrence of an event (such as item created), or to instruct a client to perform a follow-up request (such as authorization required), or plain success. Response status codes are set in the execute script by using the status root object.

Consider the following JavaScript code located in the execution script:

var folder = roothome.childByNamePath(url.extension); 
if (folder == undefined || !folder.isContainer) 
{ 
    status.code = 404; 
      status.message = "Folder " + url.extension + " not found."; 
      status.redirect = true; 
    }

Notice that this script uses status code 400 (Bad Request) if the folder is not valid. Redirect allows the rendering of a custom response template for the specified status code. If redirect is not set, the response header status code is set, but the relevant standard web script response template is used.

Creating a response template

Create a response template that renders a response for the request. That is, a response template creates a response in a format such as HTML that is returned when a web script is invoked. Multiple response formats may be provided and each response is rendered as a FreeMarker template. This illustration shows the results of the response template that was created in this section and that displays content located in a specific folder (the Company Home folder is used in this example).

The following code represents the folder.get.html.ftl file. (See Creating your first web script.)

<html> 
     <head> 
       <title>${folder.displayPath}/${folder.name}</title> 
     </head> 
     <body> 
       Folder: ${folder.displayPath}/${folder.name} 
       <br> 
       <table> 
        <#if folder.parent.parent?exists> 
        <tr> 
          <td><td><a href="${url.serviceContext}/sample/folder<@encodepath node=folder.parent/>">..</a> 
        </tr> 
        </#if> 
<#list folder.children as child> 
        <tr> 
          <#if child.isContainer> 
            <td>&gt;<td><a href="${url.serviceContext}/sample/folder<@encodepath node=child/>">${child.name}</a> 
          <#else> 
            <td><td><a href="${url.serviceContext}/api/node/content/${child.nodeRef.storeRef.protocol}/${child.nodeRef.storeRef.identifier}/${child.nodeRef.id}/${child.name?url}">${child.name}</a> 
          </#if> 
        </tr> 
</#list> 
       </table> 
     </body> 
</html> 
 
<#macro encodepath node><#if node.parent?exists><@encodepath node=node.parent/>/${node.name?url}</#if></#macro>

Response template file names have the following structure, where format specifies the format of the response template:

    <serviceId>.<httpMethod>.<format>.ftl

For example, folder.get.html.ftl specifies that the response format is in HTML.

The response template file has access to the following objects:

  • argsM: Associative array of URL parameters, where each key is a parameter name and each value is an array that contains the parameter values (even if only one is supplied), complements the root object args.

  • guest: Boolean indicating that indicates whether the web script is executing as Guest.

  • date: Date representing that represents the date and time of the web script request.

  • server: Associative array of metadata properties that describe the server hosting LiveCycle.

  • roothome: Repository root node.

  • url: Provides access to the URL (or parts of the URL) that invoked the web script.

  • webscript: Associative array of metadata properties that describe this web script.

Response template files also have access to the following methods:

  • absurl(url): Returns an absolute URL representation of the passed URL. Useful when rendering links within ATOM (and similar formats).

  • xmldate(date): Returns an ISO8601 formatted result of the passed date. Useful when rendering dates as XML.

  • scripturl(queryString): Returns a URL that references this web script. The passed queryString is added to the URL. System arguments such as guest and format are automatically added.

Remarque : Multiple response formats are supported by creating additional response template files. New and updated templates are used when the web script is invoked.

Storing web scripts

After you create the description document, the execution script, and the response template file, you must store these three files. You can store them in either of the following Content Services (deprecated) folders:

  • /Company Home/Data Dictionary/Web Scripts Extensions

  • /Company Home/Data Dictionary/Web Scripts

Within either of these folders, you can use subfolders to store web scripts.

To store a web script:

  1. Browse to the folder that is used to store the files that the web script requires.

  2. Click Add Content.

  3. Click the Browse button and locate the file to upload.

  4. Click the Upload button, and then click OK.

Remarque : Repeat this procedure to store the description document, execution script, and response template. That is, folder.get.desc.xml, folder.get.js, and folder.get.html.ftl files must be stored. (See Creating your first web script.)

Registering web scripts

The third step in creating a web script is to register it. If you do not register a web script, you cannot invoke it. New and updated web scripts can be registered without restarting LiveCycle.

To register a web script:

  1. Using a web browser, specify the following URL: http://[host]:[port]/contentspace/service/index

  2. Click Refresh list of Web Scripts.

Remarque : You can retrieve a list of all registered web scripts by using this URL: http://[host]:[port]/contentspace/service/index/all

Invoking web scripts

You can invoke a web script after it is registered by using its URL, which is defined in the description XML file. For example, the following URL is defined in the folder.get.desc.xml:

  • [url]/sample/folder/{path}[/url]

    This is only part of the invocation URL that is required to invoke the web script. You must combine this part with http://[host]:[port]/contentspace/service/. The entire invocation URL that is used to invoke the web script that is created in this section is as follows:

  • http://localhost:8080/contentspace/service/sample/folder/Company Home/Test Directory

    This URL returns a list of all content that is located in the Company Home/Test Directory folder. For example, assume that this folder contains two PDF files named AssemblerResultBatesPDF.pdf and Loan.pdf. This illustration shows the results of the web script that displays all content in a specified folder.

    Web scripts are executed as the currently authenticated user at the time the web script is invoked. Some web scripts do not require authentication, in which case, they either do not access the Content Services (deprecated) repository, or they execute as a predefined user. If a web script requires authenticated access and the request is unauthenticated, a login dialog box appears, as shown in this illustration.

Creating additional web scripts

This section discusses how to create the following web scripts:

Before you read this section, it is recommended that you be familiar with creating web scripts. (See Creating your first web script.)

Creating a web script that uploads files

This section discusses how to create a web script that uploads content to Content Services (deprecated). This web script is divided into two web scripts and shows how to create a file upload URL service. The first web script creates a basic HTML form that has three form fields, one that is of type file, as shown in this illustration.

The HTML form invokes the second web script that parses the posted data request and then uploads a new file.

Remarque : Before you read this section, it is recommended that you be familiar with creating web scripts. (See Creating your first web script.)

Upload Form web script

The following XML code represents an XML description file named upload.get.desc.xml.

<webscript> 
    <shortname>File Upload Form Sample</shortname> 
    <description>Form for uploading file content and metadata into Repository</description> 
    <url>/sample/upload</url> 
    <authentication>user</authentication> 
</webscript>

The following code represents a template response file named upload.get.html.ftl.

<html> 
<head> 
<title>Upload Web Script Sample</title> 
<link rel="stylesheet" href="${url.context}/css/main.css" TYPE="text/css"> 
</head> 
<body> 
<table> 
<tr> 
<td><img src="${url.context}/images/logo/AlfrescoLogo32.png" alt="Alfresco" / 
></td> 
<td><nobr><span class="mainTitle">Upload Web Script Sample</span></nobr></td> 
</tr> 
<tr><td><td>Alfresco ${server.edition} v${server.version} 
</table> 
<p> 
<table> 
<form action="${url.service}" method="post" enctype="multipart/form-data" acceptcharset=" 
utf-8"> 
<tr><td>File:<td><input type="file" name="file"> 
<tr><td>Title:<td><input name="title"> 
<tr><td>Description:<td><input name="desc"> 
<tr><td><td> 
<tr><td><td><input type="submit" name="submit" value="Upload"> 
</form> 
</table> 
</body> 
</html>

Upload script

The following XML code represents an XML description file named upload.post.desc.xml.

<webscript> 
    <shortname>File Upload Sample</shortname> 
    <description>Upload file content and meta-data into Repository</description> 
    <url>/sample/upload</url> 
    <authentication>user</authentication> 
</webscript>

The following JavaScript code represents a JS file named upload.post.js.

var filename = null; 
var content = null; 
var title = ""; 
var description = ""; 
// locate file attributes 
for each (field in formdata.fields) 
{ 
if (field.name == "title") 
{ 
title = field.value; 
} 
else if (field.name == "desc") 
{ 
description = field.value; 
} 
else if (field.name == "file" && field.isFile) 
{ 
filename = field.filename; 
content = field.content; 
} 
} 
// ensure mandatory file attributes have been located 
if (filename == undefined || content == undefined) 
{ 
status.code = 400; 
status.message = "Uploaded file cannot be located in request"; 
status.redirect = true; 
} 
else 
{ 
// create document in company home for uploaded file 
upload = companyhome.createFile("upload" + companyhome.children.length + "_" + 
filename) ; 
upload.properties.content.write(content); 
upload.properties.content.mimetype = "UTF-8"; 
upload.properties.title = title; 
upload.properties.description = description; 
upload.save(); 
 
// setup model for response template 
model.upload = upload; 
}

The following code represents a template response file named upload.post.html.ftl.

<html> 
<head> 
<title>Upload Web Script Sample</title> 
<link rel="stylesheet" href="${url.context}/css/main.css" TYPE="text/css"> 
</head> 
<body> 
<table> 
<tr> 
<td><img src="${url.context}/images/logo/AlfrescoLogo32.png" alt="Alfresco" / 
></td> 
<td><nobr><span class="mainTitle">Upload Web Script Sample</span></nobr></td> 
</tr> 
<tr><td><td>Alfresco ${server.edition} v${server.version} 
<tr><td><td> 
<tr><td><td>Uploaded <a href="${url.serviceContext}/sample/folder 
${upload.displayPath}">${upload.name}</a> of size ${upload.properties.content.size}. 
</table> 
</body>

Creating a web script that deletes files

This section discusses how to create a web script that deletes a file from Content Services (deprecated). This script deletes the first file from Company Home/Test Directory. After the file is deleted, a message is displayed to the user.

Remarque : Before you read this section, it is recommended that you be familiar with creating web scripts. (See Creating your first web script.)

The following XML code represents an XML description file named deletedoc.get.desc.xml.

<webscript> 
     <shortname>Document Deleter</shortname> 
     <description>This will delete the document specified in the path after "deletedoc/" on the url</description> 
     <url>/sample/deletedoc</url> 
     <format>extension</format> 
     <authentication>admin</authentication> 
     <transaction>required</transaction> 
</webscript>

The following JavaScript code represents a JS file named upload.post.js.

// locate folder by path 
var folder = roothome.childByNamePath("Company Home/Test Directory"); 
if (folder == undefined || !folder.isContainer) 
{ 
      status.code = 404; 
      status.message = "Folder Company Home not found."; 
      status.redirect = true; 
    } 
model.folder = folder; 
folder.children[0].remove();

The following code represents a template response file named deletedoc.get.html.ftl.

<html><head><title>File is deleted</title></head> 
The file was deleted. 
</html>

Creating a web script that performs a blog search

This section discusses how to create a web script that performs a blog search. When the web script is executed, a search term is specified. The content that conforms to the search term is returned (Company/Home), as shown in this illustration.

The following URL is used to invoke the web script:

http://localhost:8080/contentspace/service/sample/blog/search?q=Company/Home
Remarque : Before you readthis section, it is recommended that you be familiar with creating web scripts. (See Creating your first web script.)

The following XML code represents an XML description file named blogsearch.get.desc.xml.

<webscript> 
<shortname>Blog Search Sample</shortname> 
<description>Sample that finds all blog entries whose content contains the specified search term</description> 
<url>/sample/blog/search?q={searchTerm}</url> 
<url>/sample/blog/search.atom?q={searchTerm}</url> 
<url>/sample/b/s?q={searchTerm}</url> 
<url>/sample/b/s.atom?q={searchTerm}</url> 
<format default="html">extension</format> 
<authentication>guest</authentication> 
<transaction>required</transaction> 
</webscript>

The following JavaScript code represents a JS file named blogsearch.get.js.

// check that search term has been provided 
if (args.q == undefined || args.q.length == 0) 
{ 
status.code = 400; 
status.message = "Search term has not been provided."; 
status.redirect = true; 
} 
else 
{ 
// perform search 
var nodes = search.luceneSearch("TEXT:" + args.q); 
model.resultset = nodes; 
}

The following code represents a template response file named blogsearch.get.html.ftl. conform

<html> 
<body> 
<img src="${url.context}/images/logo/AlfrescoLogo32.png" alt="Alfresco" /> 
Blog query: ${args.q} 
<br> 
<table> 
<#list resultset as node> 
<tr> 
<td><img src="${url.context}${node.icon16}"/> 
<td><a href="${url.serviceContext}/api/node/content/ 
${node.nodeRef.storeRef.protocol}/${node.nodeRef.storeRef.identifier} 
/${node.nodeRef.id}/${node.name?url}">${node.name}</a> 
</tr> 
</#list> 
</table> 
</body> 
</html>

Understanding web script root objects

This section describes root objects that can used within web scripts. Most of these objects are used in the script examples located in this section. (See Creating your first web script.) The following list describes web script root objects:

  • cache: An array of cache control properties that enable control over how the web script response is cached. This object contains the following fields:

    • neverCache: A Boolean value that specifies whether the web script response needs to be cached. The value true means never cache. If not set, the default value is specified by the cache control section of the web script definition.

    • isPublic: A Boolean value that specifies whether the web script response needs to be cached by public caches. If not set, the default value is specified by the cache control section of the web script definition file.

    • mustRevalidate: A Boolean value that controls whether the cache must revalidate its version of the web script response to ensure an updated version. If not set, the default value is specified by the cache control section of the web script definition file.

    • maxAge: A long value that specifies the maximum amount of time (in seconds, relative to the time of request) that the response will be considered fresh. If not set, the default value is null.

    • lastModified: A date value that specifies the time that the content of the response last changed. If not set, the default value is null.

    • ETag: A string value that specifies a unique identifier that changes each time the content of the response changes. If not set, the default value is null.

  • companyhome: A script node that represents Company Home.

  • document: A script node that represents the current document.

  • formdata: A host object that provides access to multipart/form-data requests that allow file upload from a web script. This object contains the following fields:

    • hasField: A Boolean value that specifies the existence of a named form field in the multipart request.

    • fields: An array of formfield values where each element represents a field within the multipart request.

  • formfield: A host object that provides access to a form field within a multipart/form-data request. This object contains the following fields:

    • name: The name of the field.

    • isFile: A Boolean value that specifies whether this field represents a file.

    • value: A string value that represents the field value.

    • content: Script content that represents the content of the field.

    • mimetype: The MIME type of the content (null if isFile is false).

    • filename: The file name of the source file used to provide the content (or null if isFile is false or a filename was not specified).

  • person: A script node that represents the current user Person object.

  • server: An array of metadata properties that describe the server hosting Content Services (deprecated). This object contains the following fields:

    • versionMajor: A string value that specifies the major version number.

    • versionMinor: A string value that specifies the minor version number.

    • versionRevision: A string value that specifies the server revision number.

    • versionLabel: A string value that specifies the server version label.

    • versionBuild: A string value that specfies the server build number.

    • version: A string value that specifies the server version.

    • edition: A string value that specifies the server edition.

    • schema: A string value that specifies the server schema.

  • space: A script node that represents the current space.

  • status: An array of response status properties that enable control over the status and content of the web script response. This object contains the following fields:

    • code: The status code (primarily a HTTP status code but can be any number).

    • codeName: Represents the status code name.

    • codeDescription: Represents a description of the status code.

    • message: Represents a message that is associated with the status code.

    • redirect: A Boolean value that specifies whether to redirect the status reponse template.

    • exception: Represents an exeption that caused this status.

  • userhome: A script node that represents the current users home space.

  • url: A host object that provides access to the URL (or parts of the URL) that invoked the web script. This object contains the following fields:

    • context: The context path (for example, /contentspace).

    • serviceContext: The service context path (for example, /contentspace/service).

    • service: A web script path (for example, /contentspace/service/sample/blog/search).

    • full: The complete URL used to invoke the web script (for example, /contentspace/service/sample/blog/search?q=company/home).

    • args: The arguments passed to the web script (for example, q =company/home).

    • match: The part of the web script URL that matched the web script URL template.

    • extension: The part of the web script URL that extends beyond the match path (if there is no extension, an empty string is returned).

  • webscript: An array of metadata properties that describe the web script. This object contains the following fields:

    • Id: A string value that specifies the web script identifier value.

    • shortName: A string value that specifies the short name of the web script.

    • description: A string value that specifies the description of the web script.

    • defaultFormat: The default response format.

    • formatStyle: The accepted ways of specifying the format in the web script URL.

    • URIs: A string array of URL templates.

    • method: A HTTP method used in the request.

    • requiredAuthentication: The required level of authentication.

    • requiredTransaction: The required level of transaction.

    • storePath : The path of the persistent store where the web script is stored.

    • scriptPath: The path (within storePath) of the web script implementation files.

    • descPath : The path (within storePath) of the web script description document.