Legacy-Expressions

The 446 Plattform® has her own expression language, which can be used for individual customization or substantial extensions at different locations. Expressions are particularly helpful, when it is not possible to solve a complex configuration problem by only using the user interface – the expression system thus offers extension options specially tailored to power users.

Expressions mainly can be used in three modules: in the Messaging & Collaboration module for the creation of custom message templates, in the Service Level Management for the computation of non-standard escalation dates, and in the Workflow Management. Because not all elements of the expression language can be used in every module, the following sections describe the application of the expression language in the respective module.

 

Note:

The Legacy In computing, a legacy system is an old method, technology, computer system, or application program, of, relating to, or being a previous or outdated computer system, yet still in use. Often referencing a system as "legacy" means that it paved the way for the standards that would follow it. This can also imply that the system is out of date or in need of replacement. [Wikipedia]-Expressions described in this section still work, but will not be developed further. Please use the Sharp-Expressions for your configurations.

 


 

Chapters:

  1. Operators
  2. Reference

 


 

Access to Ticket Fields

You can access the content of ticket fields via miscellaneous expressions. At this, please make sure that the ticket fields you want to access via expression do not use any mathematical operators (e.g. "-" or "+") or similar special characters. These special characters can prevent the proper access to the ticket fields.

 

Messaging & Collaboration

For every message type, there are several placeholders available, which will be replaced by the respective text on sending. Additionally to the default placeholders that are located on the right side (placeholder bar) and faded in dynamically on mouse over, there is an option of adding individually defined placeholders.

Prefix and Suffix

Every placeholder defined individually begins with the prefix {$ and ends with the suffix $} (start and end token). Between the prefix and the suffix, an arbitrary expression can be entered, which can be interpreted in context to the message to be sent.

If an expression cannot be interpreted, no text is inserted into the message in this spot.

Expressions

The following screen shot shows the use of expressions in a message template:

 

Workflow Management

Using Expressions in Workflow Plug-Ins

The following example shows the use of an expression in the plug-in Conditional Switch on Expression. It has two exits and decides whether the ticket should be directed to the exit Condition fulfilled or not, depending on the underlying expression. When phrasing the expression, it is necessary to express a relation, which enables the plug-in to make a yes/no decision. In this very example, the condition is fulfilled if the ticket owns a field called RequiresAnswer and if it has the content True.

The next example illustrates another use of the Conditional Switch on Expression plug-in. In this case, it should decide whether a ticket is to be assigned to a user. The special key word NULL is used here. This condition is fulfilled if the ticket is assigned to no user.

When defining workflow activities, expressions can be used for validation. If the validation fails (i.e. the condition phrased in the expression is not fulfilled), the workflow activity will not be processed. In the following example, pressing the OK button is only accepted, if the ticket contains a solution.

Using the Special Data Fields

Special data fields can be used in the workflow, in order to implement the solution of the last user/group action into the following action, for example. These data fields have to be distinct and there should not be multiple data fields of the same name, as the content of a field could be overwritten by another field otherwise.

The data fields are specified in the configuration without any additional characters, as seen in the first figure. If the content of the field is to be displayed, the name of the data field has to be set in double curly braces:

{{DataFieldName}}

An action of approval is used as an example. For this purpose, two user actions are configured consecutively in the workflow. The first action is to be processed by an approving authority, which is to approve a request.

If the approval is not given, the user has to enter a reason. This reason is displayed as a selection box with three alternatives.

In the following figure, the configuration of this action is displayed:

After performing this action, the ticket would return from the approving authority to the requester awaiting the result of the approval in order to be able to make a decision concerning the further process. In order not to have to browse several different tabs needlessly to find the solution, the second action is configured in a way to make the solution visible directly in the user task.

The fields framed in red demonstrate the configuration of the data field. The data field ApprovalReason is configured to save the user’s selection and to display it later on (or use it in another way).

In the following figure, the data field has been configured for display in the activities list. Thus, the user can see the result of the last action immediately – without having to open the ticket first.

It is furthermore possible to configure the entry of the reason for approval as a free text field, in which the user can enter the reasons.

Displaying these entries is then possible using the same measures as described in the example of the selection box before.

 

JSON

The 446 Plattform® also supports JSON In computing, JavaScript Object Notation or JSON is an open-standard file format that uses human-readable text to transmit data objects consisting of attribute–value pairs and array data types (or any other serializable value). for its own expression language.

Example:

Copy
{
"Owner": 
    {
        "Name": "Doe"
        "FirstName": "Bob"
        "Hobbies": [ "Riding", "Golfing", "Surfing" ]
        "Employee": [ { "Name": "Smith" }, { "Name": "Miller" } ]
    }
}

This makes it possible to process JSON queries in the following forms (Expressions always have to start with Json):

Json.Owner.Name > Doe
Json.Owner.Hobbies!1 > Golfing
Json.Owner.Employee!0.Name > Smith

JSON objects can be used wherever normal expressions are used to retrieve stored information.

Normal expressions can also be used together with JSON. If the above JSON object is e.g. in a ticket field, the following expression can be accessed by the name:

Ticket.Fields!<TicketFieldName>.Json.Owner.Name

 

Expression Parser

Administrators can use the 446 Plattform® Expression Parser (Expressions Debugger) to test expressions. First, an object ID is entered as the context object and the expression to be tested in the field below it. By Parse or Parse/Analyze the expression is executed and the result is displayed.

Note:

With Compile, syntactic checking can only be done by Sharp-Expressions.

The following table shows the object ID for the corresponding object types and an example for the expression:

Object type Context object ID Example Example expression
Ticket Full ID of the ticket CR_16754 {$ Ticket.Ticket# $}
CI Visible ID of the CI MyCI {$ Ci.VisibleId $}
KB ID of the KB article KB-0025 {$ kb.Article.Owner $}
Ex­pense Expense ID of the expense 605662 {$ expense.project.objectGuid $}
Task Full ID of the tasks TSK_451 {$ task.taskstatus.name $}
Work­flow item wi_ or wi- + data ID of the work­flow item wi_1638983 wi-1638983 {$ workflowitem.dataid $}
Mail ObjectGUID of the mail A4BF43CC-EE3F-495D-9998-2EB6C29E1276 {$ Message.FeedbackPageGroup!TXP Quality!Not so good.Url $}
JSON Complete JSON string { text: "Test", id: 200 } {$ JSON.id $}