A script defining a mashup that may combine, filter or otherwise process the results from one or more publicly accessible services (component services) or web sites.
The optional logical name for this mashup. Names must be unique and can contain ASCII letters, numerals, underscores (_) or dashes (-). Names must start with a letter.
The root element for a file containing one or more macro definitions that may be included in many EMML scripts. By default, each EMML Engine has a global.emml-macros file with global macros. You can add custom macro library files to EMML Engines.
One EMML built-in metadata property to assign to this mashup or macro.
This statement marks the beginning of a SQL transaction that includes all <sqlUpdate> statements until a <sqlCommit> or <sqlRollback> statement is encountered.
This statement marks the successful end of a SQL transaction that includes all <sqlUpdate> statements since the <sqlBeginTransaction> statement.
This statement marks the unsuccessful end of a SQL transaction that includes all <sqlUpdate> statements since the <sqlBeginTransaction> statement.
Declarations define the variables, meta data or macros used within a mashup. Variables include input parameters and the result of the mashup. Meta data may be user- or system-defined.
Optional element to declare parameters that can be used as input to a mashup, operation or macro. Input parameters can be used to provide values for EMML statements including input parameters for component services.
Typically empty. The input data can be defined as text and any well-formed literal XML.
The parameter that holds the result returned from this mashup, operation or macro.
Typically empty. Can contain text and any well-formed literal XML. If content is defined within this statement, this is the sole output for the mashup or operation.
One user-defined metadata property to assign to this mashup. User-defined property names should be unique within a given mashup script and cannot use reserved property names. You assign the value for this property as the value of this element.
Can contain text and any well-formed literal XML. Valid content is user defined.
The name of this user-defined metadata property.
Statements are the actions that the mashup performs.
This statement adds attributes or children nodes to node(s) of a document-type variable. Each added node is defined in text within the body of <annotate> in the form:
[element | attribute] name value
Both the name and value of attributes or children can be a static or dynamic expressions. Separate multiple annotation definitions with commas.
This statement appends the well-formed document fragment defined in its content to the specified variable. This is commonly used with repeating statements, such as <for> or <foreach>.
The document fragment contains literal XML with static values or dynamic mashup expressions. Elements in the structure should use a namespace, so that they are clearly separated from EMML markup.
Use <assign> to assign values to a variable. Values may be:
Literal values
Fragments of another variable
A whole variable
You use XPath expressions to define the fragments or variables to assign or otherwise modify the resulting variable content.
Use <assert> to add error checking assertions within a mashup, operation, macro or other statement. Assertions are evaluated at runtime and throw exceptions if they evaluate to false.
Assertions may compare any two of the following:
A variable
An XPath expression of any kind
A literal value
A count of nodes identified by an XPath expression
A count of the levels of descendants from a node or node set identified by an XPath expression
This statement constructs a well-formed document, wrapped in a root node, and assigns it to an input or output parameter or to a variable. You define the structure as literal XML and assign static data or use dynamic mashup expressions to assign data dynamically.
it is a good practice to use a separate namespace for the elements in the structure being constructed, so that they are clearly separated from EMML markup.
Use <directinvoke> to invoke services or web sites that are publically accessible on the Web or accessible internally within your organization. Web services must have a REST, SOAP or syndication (RSS/Atom) interface.
This statement sends a debugging message to the standard output (both log and console) when the mashup script is processed. Messages can contain both static and dynamic content.
This statement filters the content of a variable based on a condition and places the result in a new variable. You can also simply update the input variable with filtered results.
The filter condition is defined in an XPath expression. You can use comparisons, position, XPath functions and dynamic expressions in the condition. You can also combine multiple conditions.
This looping statement processes any children statements in a repeated loop for the specified count. The count may be static or may use expressions to define a dynamic limit. The increment is always one.
You can use most EMML statements within <for>. You can also use <break> within this statement to forceably stop loop processing.
This looping statement processes any children statements in either a repeated loop or in parallel for each node in a node set. The node set is defined in an XPath expression.
You can use most EMML statements within <foreach>. You can also use <break> within this statement to forceably stop loop processing.
This statement groups repeating nodes, optionally filtering and sorting them, based on an XPath expression. It constructs a document structure from the group using literal XML you define and dynamic expressions to determine content or perform calculations. Groups can be nested, allowing any level of detail.
This statement is not yet implemented. It is reserved for future use to invoke an operation for a component service that is governed by another system.
This conditional statement follows the well-known if-elseif-else control pattern to processes specific children statements based on one or more conditions. Both <elseif> and <else> are optional.
You can use most EMML statements within <if>, <elseif> or <else>. You can also use <break> within these statements if they are descendants of a looping statement to forceably stop the ancestor loop processing.
This statement defines how the data from disparate variables should be joined. Variable data should have repetitive structures that are related based on some criteria in those structures - the foreign keys that define the relation. Optionally, you can also select specific nodes from the result and modify them to build the resulting document structure.
Merges the results of two or more variables with a uniform structure or type. The structures of the variables must be identical, except for root node names, and they must be document type variables. Optionally, this can also select specific nodes to be included in the output.
This container statement processes one or more groups of statements in parallel. Each group of statements to be processed concurrently is defined within a <sequence> statement.
This statement includes scripting code to execute as the mashup script is processed. Script code can be included as the content of <script> or <script> can import code from an external file from the local server.
JavaScript and JRuby are supported as scripting languages.
This statement selects specific nodes in all repeating children from an input variable and places the result in a variable. This acts as a 'column filter,' selecting specific nodes within all repeating children.
This statement sorts the content of a document-type variable or variable fragment based on key expressions and places the result in another variable.
Use <sql> to issue individual SQL queries to a data source that you have declared in the mashup script. You can also use this command to invoke stored procedures that return result sets.
Use <sqlUpdate> to execute any SQL statement that is not a query against a data source that you have declared in the mashup script. This includes basic statements to update database records or stored procedures that do not return result sets.
This statement defines an expression with dynamic parameters and assigns that to a variable. This variable can then be referred to dynamically in other mashup script statements that use expressions.
This looping statement processes any children statements in a repeated loop as long as its specified condition remains true or until a <break> statement is executed. You can use most EMML statements within <while>. You can also use <break> to explictly stop further loop processing.
This statement processes an XSLT 2.0 stylesheet that has been deployed in the EMML Engine.
This statement forceably stops loop processing for <for>, <foreach> or <while> statements. You can also use this in <if>, <elseif> or <else> statements if they are descendants of a looping statement.
A named operation for this mashup service.
Macros define custom statements for use in a specific mashup or in any mashup hosted by a given EMML Engine. They are 'mini-mashups.'
Include statements allow you to include macro definitions from a macro library in a mashup or in another macro library.
A statement to include the macro definitions from a macro library file in a mashup script or another macro library. The included macro library must be deployed in the EMML Engine that hosts this mashup service.
The name of the macro library file containing EMML macros to included here.
One macro definition in an EMML script or a macro library. Macros define custom statements that can be used in mashup scripts.
Macros can contain any EMML declaration except for definitions of another macro. Macros can contain any EMML statement, except for the statement to call another macro.
Macros allow behavior to be parameterized. They support both input parameters and an output parameter.
Macros have access to the variables defined within the macro plus all variables in the calling EMML script.
The use of a custom EMML statement defined in a macro of that name. To use macros in a mashup script, you must declare the macro reference namespace and use the namespace prefix with your custom macro name.
Pass input parameters to the custom macro as attributes in this statement. Use the outputvariable attribute to identify the variable that should receive the results of the macro, if any.
Optional element to declare the connection information to a database. Connection configuration can be specified as a JDBC connection or using JNDI. This connection information is used to execute SQL commands.
You can declare any number of named datasources in a mashup script. You can also use a single, unnamed datasource that is considered the default. EMML statements that execute SQL commands and do not have a datasource name use the default datasource.
Datasource names must be unique within a given EMML Engine.
Optional name for this datasource. If omitted, this becomes the default datasource for SQL commands that do not define a datasource.
The URL for a JDBC connection to this datasource in the form jdbc:name:protocol://host:port. If omitted, you must specify connection information for this datasource in the jndiname attribute.
The class name of the driver for a JDBC connection to this datasource. This is only relevant if urlcode is specified. If omitted, this defaults to the HSQLDB JDBC driver class.
The user name for the JDBC connection to this datasource. This is required for JDBC connections (with url), but is not relevant for JNDI connections.
The password for the JDBC connection to this datasource. Unless you specify a JNDI connection, this is required, but can be empty when no password is needed.
The JDNI name for this datasource, in the form java:/comp/env/jdbc/jndi-name. If omitted, you must specify JDBC connection information in the url and related attributes.
A list of variables to use for input, output or to hold any intermediate data or document content in the flow of mashup processing. Variables must be declared as direct children of <mashup>, <macro>, <operation> or any looping statement that can contain other EMML statements.
Variables declared in <mashup> or <operation> have a global scope and are accessible in any statement. Variables declared in <macro> or looping statements have only a statement scope.
One variable to hold input, output or any intermediate data or document content.
The specific syntax for annotations.
The relative path within the input variable to the node to be annotated.
Can contain text and any well-formed literal XML.
The variable to copy. <assign> must have either a fromvariable, a fromexpr or a literal attribute.
An expression identifying a variable or variable fragment and any functions to apply before copying the result. <assign> must have either a fromvariable, a fromexpr or a literal attribute.
A literal value to assign. <assign> must have either a fromvariable, a fromexpr or a literal attribute.
An XPath expression defining a specific node in a variable that is the target to be assigned. <assign> must have either a toexpr or an outputvariable attribute.
The variable that is the target to be assigned. <assign> must have either a toexpr or an outputvariable attribute.
An XPath expression identifying one or more nodes, values or any valid calculation to be used in the comparison for this assertion. Assertions must contain at least one of actualexpr or actualvar.
The variable to be used in the comparison for this assertion. For variables that are a document type, the comparison is made for all nodes.
Assertions must contain at least one of actualexpr or actualvar.
Optionally determines what operator is used for the comparison of this assertion. True (the default) uses equals as the operator or false uses not equals.
An XPath expression identifying one or more nodes, values or any valid calculation that the actualexpr or actualvar should be compared to. Assertions must contain at least one of expectedexpr, expectedvar, literal, count or elementdepth.
The variable that the actualexpr or actualvar should be compared to. Assertions must contain at least one of expectedexpr, expectedvar, literal, count or elementdepth.
The literal value that the actualexpr or actualvar should be compared to. This value is treated as a string.
Assertions must contain at least one of expectedexpr, expectedvar, literal, count or elementdepth.
An XPath expression identifying a set of one or more nodes. The actualexpr or actualvar is compared against the number of nodes found in this node set.
Assertions must contain at least one of expectedexpr, expectedvar, literal, count or elementdepth.
An XPath expression identifying a set of one or more nodes. The actualexpr or actualvar is compared against the number of levels of descendants plus 1 (for the node itself) of the nodes in this node set.
Assertions must contain at least one of expectedexpr, expectedvar, literal, count or elementdepth.
Can contain text and any well-formed literal XML.
The URI to the endpoint for the publicly accessible web service to invoke.
Either GET or POST.
An optional attribute for the name of the variable containing the body of the request to send when method = 'POST'.
An optional attribute for syndication feeds identifying the protocol for normalization.
Normalizes the feed results to RSS 2.0.
Normalizes the feed results to Atom 1.0.
An optional attribute for the name of the variable to receive HTTP headers from the response.
An optional attribute for the name of the variable to receive the HTTP status code from the response.
An optional attribute for the name of the variable to receive cookies from the response.
An optional attribute to have the invocation bypass the proxy server, if any. This is false by default.
Any service-related attribute. Service-related attributes are passed to the ungoverned web service as input parameters. They can be unqualified (no namespace) or any namespace other than the EMML namespace.
The static portion of a debugging message for this mashup script.
An optional XPath 2.0 expression to provide a dynamic value as part of a debuggning message for this mashup script. You cannot have both an expression and a variable in a debugging message.
An optional variable to provide a dynamic value as part of a debuggning message for this mashup script. You cannot have both an expression and a variable in a debugging message.
An expression for the condition to test for the <elseif> statement. If this condition is matched, the statements that are direct children of <elseif> are processed and any subsequent <elseif> statements or the <else> statement is skipped.
The name of the input variable to filter.
An expression that defines the filter to apply to the input variable. All matching nodes are included in the result.
The name for the counter variable for this looping statement. The scope for this variable is limited to the <for> loop.
The number or expression that defines the number to use as the counter for the first loop. The increment is always one.
The number or expression that defines the number of the last loop to execute. Expressions must evaluate to an integer value.
Optionally, defines the literal XML structure and specific nodes or computations to include in the result when loops are processed concurrently for <foreach>. If this is omitted, loops are processed concurrently, but the results of each loop are not bound to any variables.
How results for each loop are fused together and assigned to variable(s) depends on the value of the merge attribute in <foreach>. The <fuse> outputvariable attribute identifies the variable for the fused result, and if applicable the base name for variable names for the results of each loop.
The structure inside <fuse> must be well-formed, enclosed in a root node. Elements in the structure should use a namespace, so that they are clearly separated from EMML markup.
Can contain text and any well-formed literal XML.
The name for the variable to hold each 'item' for this looping statement. The scope for this variable is limited to the <foreach> loop.
An XPath 2.0 expression that defines the set of nodes (or sequence) to loop through. The length of this set defines the limit for looping and typically also defines a context for relative expressions used in statements or content within the <foreach> loop.
Determines whether each loop is processed sequentially (the default) or concurrently (parallel="yes").
Process each loop concurrently.
Process each loop sequentially. This is the default.
Determines how many loops are processed when loops are processed concurrently (parallel="yes"). This can be all loops or any one loop (the first loop to complete ends all loop processing).
Process all loops.
Process all loops.
Process all loops.
The completion of any one loop ends loop processing.
The completion of any one loop ends loop processing.
The completion of any one loop ends loop processing.
Determines how the results from multiple concurrent loops are fused into one or more variables:
true = the single output variable defined in <fuse> holds all the results of concurrent loops "by value".
false = the output variable defined in <fuse> holds a structure that references iterative variables containing the results of each concurrent loop - results "by reference". The output variable name is the base name used for iterative variables, such as $summary (the output variable), $summary1 (one loop's results), $summary2 and so on.
This attribute is only meaningful when parallel="yes" and tasks="invokeall".
The order in which concurrent loops are assigned or fused in variables is not determinant.
( group | literal XML and dynamic expressions that define the resulting output for the group)
Literal XML must be well-formed, starting with a root node. Elements in the structure should use a namespace, so that they are clearly separated from EMML markup.
An XPath expression that defines the set of nodes to group and the value for each item in that node set that defines how they are grouped. For nested groups, this XPath expression is relative to the XPath expression for the parent group.
An XPath expression that defines a criteria to select the set of nodes in the group.
An optional, alternate condition with a set of statements to process if this condition is matched.
A optional statement with a default set of children statements to process if no conditions are matched.
An expression for the initial condition to test for the <if> statement. If this condition is matched, the statements that are direct children of <if> (not including <elseif> or <else>) are processed.
The service ID for the governed service to invoke.
Optional. Reserved for future use.
The operation ID to invoke in this service.
An optional list of input or variable names, separated by commas, to use as input parameters to the operation. Variables must be listed in the order in which the service operation expects input parameters.
The name of the variable to hold the response from this invocation. This is optional.
The name of the variable to receive headers in the servoce response from this invocation. This is optional.
An optional XPath expression to use as a filter for the result of this service.
Optionally, defines the literal XML structure and specific nodes or computations to include in the result of the join. If this is omitted, all nodes matching the join condition are included in the result.
The structure inside <select> must be well-formed, starting with a root node, that is repeated for each included node. Elements in the structure should use a namespace, so that they are clearly separated from EMML markup.
Can contain text and any well-formed literal XML. Data can be literal text or assigned with dynamic mashup expressions.
The name to assign to the root node enclosing all selected results for the join.
An XPath 2.0 expression defining the variables to join and one or more conditions to apply to determine how variables are joined.
The name for this macro definition. This becomes the custom statement name within the calling EMML script, so macro names must be valid XML names. They also must be unique within an EMML Engine. They can contain ASCII letters, numerals, periods (.), underscores (_) or dashes (-). Names must start with a letter.
Metadata for this mashup.
The name of this metadata property.
The optional name for this operation.
Defines a group of statements that should be processed sequentially as one concurrent task within <parallel>.
The JavaScript code to execute. Inline scripting is only supported for JavaScript. If no inline code is provided, you must specify a source file for the code to execute.
The MIME type of the scripting language used, such as 'text/javascript'.
The local file with the scripting code to include and execute here. This is required for JRuby scripts and optional for JavaScript. If omitted for JavaScript scripts, the content of <script> should contain the scripting code to run.
An optional attribute identifying a folder containing JAR files with Java classes that are used within this script code. The EMML Engine loads classes from this application folder first.
Applications allow POJO services to use third-party libraries that may conflict with your Java application's libraries. Application folders must be deployed in the Application Server hosting the EMML Engine.
A list of mashup variables separated by commas that the script should have acccess to.
The mashup variable to contain the result of the script.
The set of nodes to select from each repeating item in the results of the select expression.
An XPath expression identifying one node to include in the output variable for each repeating item in the results of the select expression.
The name of the input variable to select from.
An XPath expression that defines the set of repeating nodes in the input variable to use as the source to select from.
The name of the input variable to be sorted.
The path to the set of nodes to be sorted.
The node, relative to the the sort expression path, that should be used to define sorting.
The direction for sorting.
Sort is ascending. This is the default.
Sort is descending.
The name of the data source for this query. If omitted, the query is sent to the default data source.
The query to execute. The actual SQL syntax supported depends on the database and driver class for this data source.
Optionally, the index for the first row in the result set to return. If omitted, this defaults to one.
Optionally, the total number of rows in the result set to return. If omitted, this defaults to the end of the result set.
The name of the data source for this SQL transaction. If omitted, the transaction applies to SQL commands for the default data source.
The name of the data source for this query. If omitted, the query is sent to the default data source.
The SQL statement to execute. The actual SQL syntax supported depends on the database and driver class for this data source.
An optional variable to accept the output of this SQL command.
The XPath expression to assign to the output variable. Typically, this XPath expression also contains one or more mashup expressions that will accept input parameters at runtime.
A list of comma-separated input or variable names to use as input to the operation.
An expression identifying the specific nodes within the merged result that should be the only nodes included in the output of this statement. This expression must define a well-formed XML structure.
One variable to hold input, output or any intermediate data or document content.
Typically empty, but can contain text and any well-formed literal XML.
An expression for the condition to test at the beginning or each <while> statement loop.
The file name of the deployed XSLT stylesheet to execute. This must be just the file name, no relative paths, folders or URLs.
An optional variable to provide input parameter(s) for the XSLT stylesheet. You can only specify variable as an input parameter to the stylesheet. Use a document-type variable to pass multiple input parameters.
The required name for a variable, input parameter or output parameter. Parameter names must be unique within the scope of the mashup script. Names for variables must be unique within the scope of the mashup, if the variable has a global scope, or within the statement in which the variable is declared.
The required data type for this parameter or variable. Valid values for this include:
Input parameters for the mashup script cannot be a document type. Only simple types are supported for mashup input.
The optional name of the service that has metadata defining the data type for this parameter or variable. This is required if the value of the type attribute is a token.
The optional default value to use for this variable, input parameter or output parameter.
The required variable to accept the output of this statement.
The required input variable for this statement.
The name of a variable containing headers to use when this service is invoked. The payload in a headers variable must be in the form:
<header> service-specific payload for headers </header>
The maximum number of minutes to wait for a response before terminating this service invocation. The default timeout is 5 minutes.
The behavior for the mashup script if errors occur when this service is invoked.
Stops all further mashup script processing after an invocation error.
Continues mashup script processing after an invocation error.