Table Of Contents
ADS Bladelets Reference
Contents
Information About Bladelets
Bladelet Choices
PEP Markers Category
External Access Category
General Category
Logic Category
Message Handling Category
Routing Category
Security Category
Transformation Category
Miscellaneous Category
ADS Bladelets Reference
Revised: March, 2007, OL-11798-01
A Bladelet is an operation that is performed on a message. It is a user defined software component that implements certain interfaces and provides a useful unit of functions. For example, Authentication bladelet provides authentication against various authentication schemes such as, LDAP, Kerberos, and Netegrity; it will not do anything else.
Cisco AON Development Studio (ADS) provides a repository of standard Bladelets that are organized by category—for example, logic, message handling, security, transformation, and so on. This chapter presents detailed reference information that you need to choose and use ADS Bladelets.
Note 
For more information on implementing an AON network, see the following:
•Other chapters in this guide:
– Getting Started with Cisco ADS
– Setting Bladelet Properties, Variables, and Rules
– ADS PEP Attributes Reference
– ADS Message Types Reference
– E-Mail to Cisco ADS Support
•Other guides in the AON library:
–AON Installation and Administration Guide (for information on the AMC server and nodes)
–AON Programming Guide (for information on custom Bladelets, custom adapters, and application program interfaces)
Contents
• Information About Bladelets
• Bladelet Choices
Information About Bladelets
Bladelets are used in the construction of Policy Execution Plans (PEPs). You construct a PEP with the graphical-user-interface (GUI) ADS tool, which enables you to drag and drop icons representing Bladelets onto a canvas. You then "connect" the Bladelets, thus forming a PEP.
Bladelets are highly configurable. Using ADS, you configure Bladelets during normal PEP construction by setting their properties, which are grouped hierarchically into three levels:
<configuration-group>
<configuration-subgroup>
<parameter-group> and <parameter>
Figure 3-1 shows the various components of a Bladelet. (The example shown below is an Access DB Bladelet.)
Figure 3-1 ADS Bladelet
1
|
Whole Bladelet icon.
|
5
|
Bladelet input connection (connects to the output connection of another Bladelet).
|
2
|
Bladelet configuration status:
•Red—One or more critical errors
•Yellow—One or more warnings
•Green—No critical errors or warnings
|
6
|
Bladelet output connection (connects to the input connection of another Bladelet).
If two output connections exist, output paths usually designate the top one for a successful outcome and the bottom one for a failed outcome.
|
3
|
Bladelet graphic.
|
7
|
Bladelet label.
|
4
|
Bladelet exception PEP markers (connection points for specific types of exceptions).
|
|
|
Bladelet Choices
This section describes the predefined Bladelets that ADS displays in its Task Pane, in Getting Started with Cisco ADS. It also describes any Bladelet properties that you need to set in order for the Bladelet to function properly.
ADS provides the following Bladelet categories:
• PEP Markers Category
• External Access Category
• General Category
• Logic Category
• Message Handling Category
• Routing Category
• Security Category
• Transformation Category
• Miscellaneous Category
Note Many of the following windows allow you to specify values in one or more of the following ways:
•By typing them in directly
•By selecting them from a drop-down list
•By binding the parameter to a specific value
PEP Markers Category
In the PEP Markers category, there are two markers:
• Exception-PEP Marker
• Break Marker
Exception-PEP Marker
Use the Exception-PEP marker for tracking and recording exceptions in the PEP. It is a good way to create instances that you can store as database records to audit exceptions as information is routed through the PEP.
There are no properties to set for this marker.
Break Marker
Use the Break marker only inside loops. It is only allowed in a Loop and cannot be used elsewhere. You cannot place any other bladelets after the Break marker. The Break marker is used to exit out of the loops. For details, see the Loop Bladelet.
There are no properties to set for this marker.
External Access Category
In the External Access Category, there are two Bladelets:
• Access HTTP
• Access DB
Access HTTP
Summary
The Access HTTP Bladelet makes an outgoing HTTP call using the GET or POST method in either the Componentized or Normal URL Configuration groups.
Prerequisites, Dependencies, and Restrictions
AccessHTTP is synchronous, and thus cannot be used to execute a PEP running on the same node.
Details
Figure 3-2 to Figure 3-4 show required, optional, and advanced settings for the Componentized URL Configuration group.
Figure 3-5 to Figure 3-7 show required, optional, and advanced settings for the Normal URL Configuration group.
Figure 3-2 Access HTTP Properties Window—Input Parameters, Componentized URL, Required Tab
1
|
Configuration group
|
Configuration group, set here to Componentized URL.
|
2
|
Method
|
Method. Choices: Post and Get.
|
3
|
Host
|
Hostname or IP address of the HTTP server.
|
4
|
Path
|
Path portion of the URL (/index.jsp).
|
Figure 3-3 Access HTTP Properties Window—Input Parameters, Componentized URL, Optional Tab
1
|
Configuration Group
|
Configuration group, set here to Componentized URL.
|
2
|
Port
|
Port number to be used. Defaults to 80.
|
3
|
Content Type
|
MIME type of the content.
|
4
|
Headers
|
Header name and corresponding value (string types).
|
5
|
Input Content
|
Payload of the HTTP call. Required only in case of POST.
|
Figure 3-4 Access HTTP Properties Window—Input Parameters, Componentized URL, Advanced Tab
1
|
Configuration Group
|
Configuration group, set here to Componentized URL
|
2
|
Authentication
|
Basic HTTP is the only authentication scheme supported today.
|
3
|
Scheme
|
Basic HTTP.
|
4
|
User
|
User ID.
|
5
|
Password
|
Password.
|
6
|
Timeout/Retires
|
Timeout and retries to establish a connection.
|
7
|
Connection Timeout (seconds)
|
The maximum amount of time in seconds, for which AccessHttp waits to open a connection. Default is 60 seconds.
|
8
|
Socket Read Timeout (seconds)
|
The maximum amount of time in seconds for which AccessHttp waits to read from the socket after a connection is established. Default is 30 seconds.
|
9
|
Number of Retries
|
The number of times a connection is attempted. Default is 3.
|
Figure 3-5 Access HTTP Properties Window—Input Parameters, Normal URL, Required Tab
1
|
Configuration Group
|
Configuration group, set here to Normal URL.
|
2
|
Method
|
Method. Choices: POST or Get.
|
3
|
URL
|
Complete URL.
|
Figure 3-6 Access HTTP Properties Window—Input Parameters, Normal URL, Optional Tab
1
|
Configuration group
|
Configuration group, set here to Normal URL.
|
2
|
Content Type
|
MIME type of the content.
|
3
|
Headers
|
Header name and corresponding value.
|
4
|
Input Content
|
Payload of the HTTP call. Required only in case of Post.
|
Figure 3-7 Access HTTP Properties Window—Input Parameters, Normal URL, Advanced Tab
1
|
Configuration Group
|
Configuration group, set here to Normal URL.
|
2
|
Authentication
|
Authentication scheme. Basic is the only scheme supported today.
|
3
|
Scheme
|
Basic HTTP.
|
4
|
User
|
User ID.
|
5
|
Password
|
Password.
|
6
|
Timeout/Retires
|
Timeout and retries to establish a connection.
|
7
|
Connection Timeout (seconds)
|
The maximum amount of time in seconds, for which AccessHttp waits to open a connection. Default is 60 seconds.
|
8
|
Socket Read Timeout (seconds)
|
The maximum amount of time in seconds for which AccessHttp waits to read from the socket after a connection is established. Default is 30 seconds.
|
9
|
Number of Retries
|
The number of times a connection is attempted. Default is 3.
|
Figure 3-8 Access HTTP Properties Window—Export Parameters
1
|
Response
|
Response from the HTTP call (string type).
|
2
|
Result
|
Response from the HTTP call (AON content type).
|
3
|
Status
|
Status HTTP call (integer type m).
|
Outcome
None.
Exceptions
•Malformed URL: Connection cannot be established to the HTTP server host.
•Host Inaccessible: The URL (composed URL in case componentized URL is specified) is not correct.
Access DB
Summary
Use this Bladelet to make a SQL call out to a database.
Prerequisites, Dependencies, and Restrictions
Access DB does not work with binary objects; it only works with basic types, for example string, int, and so on.
Details
Figure 3-9 Access DB Properties Window—Data Source
1
|
Database Name
|
Property set. After opening a project in AMC the path is Properties > Application > Global > Databases.
|
2
|
Query Timeout in Seconds
|
Desired waiting time set for a query to get executed.
|
Figure 3-10 Access DB Properties Window—SQL
1
|
Configuration Group
|
Configuration group, set here to Insert. Choices: Insert, Update, Delete, and Query.
|
2
|
SQL Statement
|
The SQL statement in the Java SQL prepared statement syntax. Use ? for place holders. Do not put ? in quotes in case of string-type parameters.
|
3
|
Values
|
One or more values (string types). Each string corresponds to the placeholder in the SQL statement. There should be as many entries in this list as there are placeholders in the SQL statement.
|
Figure 3-11 Access DB Properties Window—Export Parameters
1
|
Number of Records Updated
|
Number of records updated in case of non-query type of SQL statements.
|
2
|
Result
|
Result set in case type of SQL statements is Query. There are as many maps in the list as there are records retrieved. Each map has name-value pairs, where name is the column name and value is the column value in the record.
|
Outcome
None.
Exceptions
•Database Failure: Database cannot be connected to.
•SQL Failure: The input SQL statement could not be executed properly.
Note The SQL interface does not support stored procedures.
General Category
In the General Category, there are three Bladelets:
• Log
• Retrieve Cache
• Cache Data
Log
Summary
The Log Bladelet allows you to log message contents, PEP variables and other important data related to the message, message class, source, destination, time stamps, and PEP name.
Prerequisites and Dependencies
None.
Details
Figure 3-12 Log Properties Window—Input Parameters
1
|
Synchronization Mode
|
Mode of operation:
•Asynchronous—Bladelet executes (in the foreground) while the database writes (in the background).
•Synchronous—Bladelet waits while the database writes. Use to ensure that data is entered into the database properly before the PEP goes to the next step.
|
2
|
Database
|
Property set names for Message Log Policy. After opening a project in AMC the full path is Properties > Application > Node > Message Log Domain.
|
3
|
Message
|
Auto complete message field.
|
4
|
Level
|
Level of logging. Allowed values for the ENUM are the following:
•Basic—Only metadata about the message is logged: entry time, message type, PEP name, and so on.
•Header—Basic plus SOAP header. For non-SOAP messages, it is the same as Basic.
•Body—Basic plus SOAP body. For non-SOAP messages, it is the whole message.
•Whole-Message—Entire message without attachment. For non-SOAP message, it is the same as Body.
•Specify by XPath Expressions—Contents to be logged are specified by a list of XPath expressions. (See descriptions for the Expressions parameter.)
|
5
|
Expressions
|
Optional. One or more XPaths specifying what needs to be logged. Applies only if level is set to Specify by XPath Expressions. Each XPath contains two values:
•Name—String that provides a unique identifier for the contents specified by the expression
•Expression—Valid XPath expression specifying the contents that need to be extracted and logged
|
6
|
Custom Identifier
|
Optional. String to identify this message log entry.
|
Figure 3-13 Log Properties Window—Variables
1
|
Variables
|
List of variables to be logged. Each list element contains two values:
•Name—Unique identifier for the contents of the variable
•Variable—Top-level variable or valid variable expression (select from the drop-down list or use the variable picker)
|
Outcome
None.
Exceptions
•Log Write Failure: A failure occurred during the database write. These are failures that are typically not recoverable. For example, data does not conform to the log schema, or the log policy is disabled for the database.
Timeout: Timeout occurred. This applies only to synchronous mode. For example, this can happen when the database is not available or is extremely slow.
Retrieve Cache
Summary
This Bladelet retrieves data from two named caches configured on an AON node. The named caches are response and variable. The response cache caches arbitrary messages and server responses. The variable cache caches PEP variables. The response cache is distributed and the variable cache is node local. Populate these named caches by using the CacheData Bladelet.
Prerequisites and Dependencies
•Ensure that the cache on the AON node on which the PEP executes has bootstrapped without errors.
Details
Figure 3-14 Retrieve Cache Properties Window—Input Parameters
1
|
Key Type
|
Hint to the Bladelet to determine the Key to be used for retrieving the object from the cache.
•Request—Bladelet computes the cache key from the payload of the current request message.
•HTTP-Request-URI—Bladelet inspects the HTTP request and uses the request uniform resource identifier (URI) as the cache key. Use only if the request message is HTTP.
•Variable—Bladelet uses a PEP variable as the cache key.
|
2
|
Key
|
Key. Required if the key type is VARIABLE. Bind to this input parameter. Can be one of the following data types: string, FindResult, or any numeric type.
For Request and HTTP-Request-URI, the key is ignored.
|
3
|
Object Type
|
Where the Bladelet should go to fetch the data:
•Response—Response cache
•Variable—Variable cache
•Message—Message cache
|
Figure 3-15 Retrieve Cache Properties Window—Export Parameters
1
|
Object
|
Exported parameter object. Bind the object retrieved from the cache to this object.
|
2
|
Key
|
Exported parameter key. Required if the key type is Variable. Bind the PEP variable to be used as the key to this input parameter. The variable can be one of the following data types: string, FindResult, or any numeric type.
|
3
|
Result
|
Expected result of export parameter. Bind the result of the cache lookup to this variable.
|
Outcome
•A cache hit or "Success" path indicates that the requested data was found in the cache.
•A cache miss or "Fail" path indicates that the requested data was not found in the cache.
The Bladelet exports the cache key that was used for the lookup operation, the result of the operation (0 indicates a miss; 1 indicates a hit) as follows:
•On success, it also exports the cached object, which can be bound to a PEP variable of the appropriate data type. For response type object retrieved from the "response" named cache, the Bladelet also binds the object to the "RESPONSE_MESSAGE" PEP variable.
•On miss, the exported cache key can be used by a CacheData Bladelet further in the PEP execution to cache data to the cache.
Exceptions
None.
Cache Data
Summary
This Bladelet should be used to set data into the named caches configured on an AON node. The named caches are "response" and "variable". The "response" cache caches arbitrary messages and server responses. The "variable" cache caches PEP variables. The response cache is distributed and the variable cache is node local. You can retrieve data from the named caches by using the RetrieveCache Bladelet. You can also set and retrieve data from the named and "variable" caches by using the Caching Service API exposed to Custom Bladelets.
Note Objects are put into the response cache asynchronously and the variable cache synchronously with PEP execution.
Prerequisites and Dependencies
•Ensure that the cache on the AON node on which the PEP executes has bootstrapped without errors.
Details
When it is given a cache key and optionally a PEP variable, this Bladelet caches the variable or the server response message.
Figure 3-16 Cache Data Properties Window—Input Parameters
1
|
Key Type
|
Hint to the Bladelet to determine the key to be used for setting the object to the cache.
•Request—Bladelet computes the cache key from the payload of the current request message.
•HTTP-Request-URI—Bladelet inspects the HTTP request and uses the request URI as the cache key. Use only if the request message is HTTP.
•Variable—Bladelet uses a PEP variable as the cache key.
|
2
|
Key
|
PEP variable. Required if the key type is VARIABLE. Bind the PEP variable to be used as the key to this input parameter. Can be one of the following data types: string, FindResult or any numeric type.
For Request and HTTP-Request-URI the key is ignored.
|
3
|
Object Type
|
Whether or not the data to be cached should be the server response elicited by the request or a PEP variable.
•Response—Caches the current response message in the response cache.
•Variable—Caches the PEP variable specified in the Object parameter.
•Message—Caches the message specified in the Object parameter in the response cache.
|
4
|
Object
|
Value of the PEP input variable. If the object type is VARIABLE, bind the PEP variable to be cached to this object.
|
5
|
Expiration Type
|
How to determine the time to live or object expiration.
•Relative—Expiration time is specified as a relative integer value denoting the number of seconds for which the object should be cached.
•Absolute—An absolute time for which the object should be cached.
•HTTP—Use the HTTP directives and headers to compute the time to live.
•Default—Use the default TTL specified in the caching policy on the AMC server. For the response cache, use the response-cache default TTL. For the variable cache, use the variable-cache default TTL.
|
6
|
Expiration
|
Actual time for which the object should be cached. Required only for relative and absolute expiration types.
•For relative, specify an integer. -1 indicates that the object should be cached forever.
•For absolute, specify a date in the following format: EEE, dd MMM yyyy HH:mm:ss GMT'
Example: Sun, 16 Nov 2003 22:00:00 GMT
Optionally, specify by binding to a PEP variable that contains the expiration value.
Expiration is ignored for HTTP and Default expiration dates.
|
Figure 3-17 Cache Data Properties Window—Export Parameters
1
|
Key
|
Exported key parameter. Required if the key type is Variable. Bind the PEP variable to be used as the key to this input parameter. The variable can be one of the following data types: string, FindResult, or any numeric type.
|
Outcome
•On success, the server response elicited by the request of the PEP variable to be cached is set in the "response" and "variable" cache.
Exceptions
None.
Logic Category
In the Logic Category, there are two Bladelets:
• Loop
• Scope
• Find
• Branch
Loop
Summary
The Loop Bladelet allows you to construct a PEP and apply repeated business logic processing based on the number of items in the data types—Counter, Iterator, or Map—over which the loop is performed. This construct is identical to a loop which is found in the Java or C programming languages. The Loop Bladelet is represented as a block in which other bladelets are placed.
Figure 3-18 Loop Bladelet
Prerequisites and Dependencies
None.
Details
A PEP can be viewed as a program expressed in the PEP Description Language (PDL). PDL is a programming language and defines the variable types used in a PEP as the fundamental data types. The PDL exposes a number of data types—List, Map, and Iterator. At runtime, these data types represent a collection of other data types (List and Map) or a cursor into this collection (Iterator). When handling these data types, it is almost always required to do some kind of repeated processing (loop) for each entry in the collection.
Note A Break marker is only allowed in a Loop Bladelet and cannot be used elsewhere.
The Loop Bladelet has three different data types—Counter, Iterator, and Map.
Counter
The Counter Loop is used when a given operation (for example, another bladelet needs to be executed) needs to be performed specific number of times. It is similar to a "for" loop with counter variable being initialized to a user specified value and incriminated by a user specified amount. The loop terminates at a user specified end value. See Figure 3-19 for the details of the Counter Loop parameters.
Iterator
The Iterator Loop must be used to loop through a list. The current object and index is available at each loop iteration and can be used by bladelets within the loop. See Figure 3-20 for the details of the Iterator Loop parameters.
Map
The Map Loop is used to iterate over a map. It exposes both the current key and current value at each loop iteration, both of which can be used by bladelets within the loop. See Figure 3-21 for the details of the Map Loop parameters.
Figure 3-19 Loop Properties Window—Counter
1
|
Configuration Group
|
Configuration Group, set here to Counter.
|
2
|
Input Parameters—Start
|
Initializes the loop with the number where we start counting; the index starts here.
|
3
|
Input Parameters—Condition
|
This condition must be satisfied at every iteration of the loop. Check if the current index is "less than," "less than or equal to," "greater than," "greater than or equal to" than the End value, in order to determine whether to continue with the next iteration.
|
4
|
Input Parameters—End
|
Determines when the loop will terminate.
|
5
|
Input Parameters—Update
|
Number of updates of the index after each loop iteration.
|
5
|
Output Parameters—Initial Counter
|
The start index. It is always same as the start index of the input parameter.
|
7
|
Output Parameters—Index
|
Index at which loop iteration ends.
|
Figure 3-20 Loop Properties Window—Iterator
1
|
Input Parameter—Iterator
|
A pointer to the start of a list of elements. At every iteration of the loop, the subsequent element in the list will be traversed using this iterator.
Note This is an auto complete field and provides a list of variables.
|
2
|
Output Parameter—Current Iterator Value
|
The element that is pointed to by the iterator at this iteration of the loop.
|
3
|
Output Parameter—Current Iterator Index
|
The index of the element that is pointed to by the iterator at this iteration of the loop.
|
Figure 3-21 Loop Properties Window—Map
1
|
Input Parameter—Map
|
A collection of elements. Each element is comprised of a key and a value. At every iteration of the loop, the subsequent element in the map will be traversed and the associated key and value will be exposed.
|
2
|
Output Parameter—Current Key
|
The key of the element that is being traversed at this iteration of the loop.
|
3
|
Output Parameter—Current Value
|
The value of the element that is being traversed at this iteration of the loop.
|
Outcome
Loops can be nested to arbitrary levels and there is no pre-defined limit to the number of loops that can be used in a PEP. For each type of data that the loop executes over, a different set of PEP variables are exported.
Exceptions
None.
Scope
Summary
The Scope Bladelet is used to define a physical block within a PEP that allow localized definition of variables and business logic.
Prerequisites and Dependencies
None.
Details
There are no properties to set for this Bladelet.
The scope construct in the PEP Description Language (PDL) allows you to define physical blocks within the PEP that allow localized definition of variables and business logic. This is similar to the {} operator in the Java or C++ programming languages where a block of execution bounded by the braces serves as a container for variables that are not visible outside the execution block.
A single scope block can only have one immediate parent scope (the scope block within which it is nested) and the global scope (always present) is the top level scope and is the root node in the tree representation of all the scopes in a PEP. There are some semantics that apply when using a scope block. In general a scope block is most useful when it is used to restrict the scope of a PEP variable ensuring that a variable defined in one part of the PEP is not available for use in other parts of the PEP. The restrictions on the variables in a Scope are dependent on the visibility of the variable in that block. A scope block can recognize those variables that are defined in its parent scope.
In Figure 3-22 the root node of the tree represents the default Global scope that is always present in a PEP. You can add additional scopes by dragging the scope construct from the palette to the canvas and including it at any point in the flow. Figure 3-22 shows a sample PEP containing two explicit scope blocks and the global scope (represented by the white background region on the canvas).
Figure 3-22 Sample Scopes within a PEP
In the first scope the Authenticate Bladelet can only use the variables defined with global and Scope. In the second scope, Scope 1, the Authorize Bladelet can only use variables defined with global or Scope 1. The Log Bladelet can only use variables defined with Global or Scope 1.
Outcome
Scopes can be nested within each other with no pre-defined limit on the number of scopes that can be included in a PEP.
Exceptions
None.
Find
Summary
The Find Bladelet queries an XML message and extracts all nodes identified by regular (for regular expressions, the message type does not need to be in XML format) and XPath expressions from the message currently being processed by the PEP. After regular and common XPath expressions are evaluated by this Bladelet, they are available for use by other Bladelets. Either XPath or Regex expressions can be evaluated; if both need to be evaluated, you must incorporate multiple instances of the Find Bladelet.
The Regex evaluation engine used by the Find bladelet uses Java Regex API from Sun Microsystems, Inc. There are several APIs to chose from, so we recommend that you use the API that matches the whole input string rather than finding only a match. You need to use the API that matches the whole input string because Find Bladelet needs to save the result of Regex evaluation.
For details of Java Regex API from Sun Microsystems, Inc., see http://java.sun.com/docs/books/tutorial/extra/regex/.
Note You can use the Find Bladelet to get the FindResultMapListIterator and refer to the results in the Rules Wizard in Branch Bladelet.
Or
You can also use the Rules Wizard to perform Regex evaluation.
Prerequisites and Dependencies
None.
Details
The Find Bladelet finds multiple items from within the message using XPath expressions (for XML messages) or Regular Expressions for Non-XML messages. It works on both MIME as well as NON-MIME data. The output of the find Bladelet is placed inside a PEP variable of type FindResultMapListIterator. This data type is a complex data type that encapsulates results that are found from all parts (> 0 if MIME) of the message that is being searched. The structure of the data type is as follows:
FindResultMapListIterator:
List of parts of the message on which the Find Bladelet operates (List of size 1 containing the results if it is Non-MIME; List of size > 1 if more than 1 MIME part is in the message)
Map of all the different expressions that were searched (recall that you enter a value on the left-hand list box in the Find Bladelet and for each of these you specify a list of expressions on the right-hand table. The map contains key-value pairs with the key being the entries on the left-hand box and the value being a list (size of this list = number of expressions entered for each key). The elements in this list are the actual search results.
Note IMPORTANT: Today it is not possible to use the PEP variable-picker dialog to select values from the tree view. You must enter a specific value to extract the returned results.
Key (Left hand side list box) XPath Expression list
Assume a regular input message (NON-MIME). The way to extract the results are (assume that
the output of Find is bound to a PEP variable called findResults) in the Specify Value
text box of the PEP Variable Picker dialog type:
findResults.elementAt(0).elementAt(k1).elementAt(0).value()
This expression returns the value of the search result using expression e1 on the message
while
findResults.elementAt(0).elementAt(k1).elementAt(1).value()
gives the value of the search results for e2.
The value() function is used if you know your xpath result is of type boolean, string,
integer; or if you want only the string value of the first node in the XPath Result (which
is a nodeSet)
If the XPath result of e3 is known to be a nodeset, then to get e3 result's 2nd node's
string value:
findResults.elementAt(0).elementAt(k2).elementAt(2).nodeValue(1).
The input parameters for this Bladelet (configuration group is set to XPath) are shown in Figure 3-23. Input parameters for a Bladelet whose configuration group is set to Regex are shown in Figure 3-24.
Figure 3-23 Find Properties Window—Input Parameters, XPath
1
|
Configuration Group
|
Configuration group, set here to XPath. Valid values are XPath and Regex.
|
2
|
Input
|
Input, such as DVar.
|
3
|
Content Modified
|
Whether or not message content has been modified—for example, by a preceding encryption Bladelet or transformation Bladelet.
If this is the first Find Bladelet in the PEP, then this parameter is always true because, to this Bladelet, every message is a new message.
|
4
|
Xpath Expressions
|
XPath expressions under which the condition is evaluated. Add one or more records and at least one row for each record added with an expression list in string format.
|
Figure 3-24 Find Properties Window—Input Parameters, Regex
1
|
Configuration Group
|
Configuration group, set here to Regex. Valid values are XPath and Regex.
|
2
|
Input
|
Content input parameter such as DVar.
|
3
|
Regular Expressions
|
Any number of regular expressions, such as a sample. Add records with one or more rows of expression lists to be evaluated.
|
Figure 3-25 Find Properties Window—Export Parameters
Outcome
•If all expressions in the Find Bladelet are evaluated to null, the output path is set to Fail.
•If any expression is evaluated to other than null, the output path is set to success. On success, a PEP variable of type FindResultMapListIterator is exported for use by other Bladelets in the PEP.
Exceptions
Invalid Content Type: The content type is invalid for evaluation. This happens when expression type is XPath while the message is NOT XML documents.
Branch
Summary
This Bladelet establishes conditions for message route branching based on rules and message labels. There are two main sections in the Branch Properties window.
Prerequisites and Dependencies
None.
Details
Figure 3-26 Branch Properties Window—Input Parameters
1
|
Conditions
|
Rules and labels. Each rule is evaluated in the order it is specified; evaluation stops at the first rule that evaluates to true. The label corresponding to that particular rule is set as the output path of this Bladelet. If none of the rules evaluates to true, the default output port is activated.
|
Figure 3-27 Branch Properties Window—Export Parameters
1
|
Label
|
Label that is chosen as the output path.
|
Outcome
•On success, the output port activated is the same as the one corresponding to the rule that evaluates to true.
•If none of the rules evaluate to true, the default output port is activated.
Exceptions
None.
Message Handling Category
In the Message Handling Category, there are nine Bladelets:
• Validate
• Build Composite Content
• Discard
• Create Message
• Update Message
• Create Content
• Extract Composite Content
• Create Response
• Application QoS
Validate
Summary
The purpose of this Bladelet is to validate XML messages based on a schema (XSD) or DTD. The schema referred by the XML message must already be loaded into AON in an appropriate Schema Extension package using the AMC server.
Prerequisites and Dependencies
•Load all schemas including XSD and DTD files that can be referred to by incoming XML messages into AON using the AMC server's Extension-Uploading and Deployment mechanism.
•Configure any Schema Validation policies, if required, and deploy them from the AMC server.
Details
The Validate Bladelet has two main parts in its properties window: input parameters and advanced input parameters.
Figure 3-28 Validate Properties Window—Input Parameters, Validate
1
|
Input Content
|
Source-content input. XML message content to be validated by the Bladelet.
|
2
|
Part of Message to Validate
|
Full Message—Whole XML message needs to be validated.
|
3
|
Type of validation
|
Grammar Check—Whether or not to validate XSD in addition to DTD.
Validate the input XML message against XSD, if the box is checked and DTD, if the box is checked. Check the box if you expect incoming messages to contain XSD references that need to be validated. If unchecked, XML messages that refer to XSD references are not validated.
|
Figure 3-29 Validate Properties Window— Input Parameters, Check Well-Formedness Only
1
|
Input Content
|
Source-content input. XML message content to be validated by the Bladelet.
|
2
|
Part of Message to Validate
|
Partial Message—Only part of the input XML message is validated. This is determined by the XPath value entered in the XPath input field.
|
3
|
XPath String
|
XPath value.
|
4
|
Type of Validation
|
Check Well-Formedness Only—Whether or not to ensure the input XML message is formed according to XML standards.
|
Figure 3-30 Validate Properties Window—Advanced Input Parameters 1
1
|
Limit Number of Node Occurrence
|
Disable—No limit is set on the number of content model nodes in the XML message.
|
2
|
Limit Number of Entity Expansions
|
Disable—No limit is set on the number of entity expansions and parser can permit any number of entity expansions in the XML document.
|
3
|
Action For Messages With No Grammar Available
|
When the input XML message does not refer to any Schema or DTD to validate against.
Disallow Message—Fail the validation and set the failure path in the PEP execution.
|
4
|
Full Schema Constraint Checking
|
(Optional) Determine if the schemas must be checked for well-formedness.
|
Figure 3-31 Validate Properties Window—Advanced Input Parameters 2
1
|
Limit Number of Node Occurrence
|
Enable—Set the limit on the number of content model nodes in the XML message. The limit is configured in the "Maximum Number of Node Occurrences" input field.
|
2
|
Maximum Number of Node Occurrences
|
The limit of the maximum number of node occurrences.
|
3
|
Limit Number of Entity Expansions
|
Enable—Set the limit on number of entity expansions that the parser should permit in a XML document. The limit is configured in the "Maximum Number of Entity Expansions" input field.
|
4
|
Maximum Number of Entity Expanses
|
The limit of the maximum number of entity expansions.
|
5
|
Action For Messages With No Grammar Available
|
When the input XML message doesn't refer to any Schema or DTD to validate against.
Validate with Default Schema—Validate the input XML message with the default schema defined by the Schema Reference (Policy) input field.
|
6
|
Schema Reference Policy
|
Schema reference policy. Must already be set on the AMC server.
|
7
|
Full Schema Constraint Checking
|
(Optional) Determine if the schemas must be checked for well-formedness.
|
Outcome
•The Success output path is taken when the XML message is found to be valid—that is, it conforms to the XSD or DTD used to validate the message.
•The Failure output path is taken in the following cases:
–The XML message is found to be invalid—that is, it does not conform to the XSD or DTD used to validate the message.
–The input message is not a well-formed XML message and therefore could not be validated using any schema.
–The schema referred by the XML message does not exist in AON.
Exceptions
None.
Build Composite Content
Summary
Creates multipart content from the given input message and the parts that need to be added/deleted/overwritten.
Prerequisites and Dependencies
None.
Details
The Build Composite Content Bladelet's properties are, as with some other Bladelets, dependent on the type of configuration group that is used. If the index in the configuration group Attach is null, the Bladelet attaches the parts to the end of the input content. If the index specified is blank in the configuration group Overwrite, it overwrites the Input Content based on the Content-Id of the parts. In configuration group Delete, index and parts are mutually exclusive. Both cannot be specified. If the index is blank, the parts are deleted based on the Content-Id.
Figure 3-32 Build Composite Content Properties Window—Input Parameters, Attach
1
|
Configuration Group
|
Configuration group, set here to Attach.
|
2
|
Input
|
Base-content input message. Base content to which parts are attached and it has to be a multipart.
|
3
|
Index
|
Optional. Index to attach. If blank, attaches to the end.
|
4
|
Parts
|
List of contents to attach.
|
Figure 3-33 Build Composite Content Properties Window—Input Parameters, Overwrite
1
|
Configuration Group
|
Configuration group, set here to Overwrite.
|
2
|
Input
|
Base-content input message. Base content to which parts are overwritten. Must be a multipart content.
|
3
|
Index
|
Optional. Index to overwrite.
|
4
|
Parts
|
List of contents to Overwrite. Use to overwrite existing contents at the index specified. If blank, it overwrites the input content based on the Content-Id of the parts.
|
Figure 3-34 Build Composite Content Properties Window—Input Parameters, Delete
1
|
Configuration Group
|
Configuration group, set here to Delete.
|
2
|
Input
|
Base-content input message. Base content to which parts are overwritten. Must be a multipart content.
|
3
|
Index
|
Optional. Index to overwrite.
|
4
|
Count
|
Number of parts that need to be deleted from the index specified.
|
5
|
Parts
|
List of contents to delete. Select from the drop-down list or bind to a specific value. Use to delete existing contents from the Input Content. Mutually exclusive with Index.
|
Figure 3-35 Build Composite Content Properties Window—Input Parameters, Advanced, Attach
1
|
Configuration Group
|
Configuration group, set here to Attach.
|
2
|
Type
|
Output-message type. Default is None, which is the same as a regular MIME message. RosettaNet outputs the message in RosettaNet format.
|
3
|
Subtype
|
Header for subtypes when the input content is null. Can be set only when Configuration Group is set to Attach.
|
Figure 3-36 Build Composite Content Properties Window - Input Parameters, Advanced, Overwrite/Delete
1
|
Configuration Group
|
Configuration group, set here to Overwrite. Window looks the same if the value is set to Delete.
|
2
|
Type
|
Output-message type. Default is None, which is the same as a regular MIME message. If set to RosettaNet, outputs the message in RosettaNet format.
|
Figure 3-37 Build Composite Content Properties Window—Export Parameters
1
|
Result
|
Type of exported parameter such as ZVar.
|
Outcome
•On Success, the BuildCompositeContentBladelet exports a Content that is built from the inputs and other parameters specified.
Exceptions
ParsingException: Exception thrown when input data is not MIME or when the data could not be parsed.
Discard
Summary
The Discard Bladelet discards a message based on whether it meets certain policies or message requirements established in the PEP and has no user-configurable input parameters.
Prerequisites and Dependencies
None.
Details
There are no properties to set for this Bladelet.
Outcome
•On success, PEP processing stops and connection to the client is lost. In case of Queue based messages (JMS/MQ), the adapter transfers the message to dead letter queue, if one is configured.
Exceptions
None.
Send Reply
Summary
The Send Reply Bladelet sends a reply from the PEP before the end of the flow is reached.
Prerequisites and Dependencies
There should be a Send or a Create Response preceding this bladelet so that a response message is available to be sent out.
Details
The Bladelet takes the message to be sent as reply as input. The exception SendReplyFailed is generated if sending the reply out fails. If the Bladelet is used in a one-way PEP, a generic bladelet exception is given. If two Send reply bladelets are used in the same path of a two-way PEP, the second bladelet is ignored and a notice-level log message is printed.
In the normal usage scenario, the bladelet would cause the response message to be sent back to the client. Once the response is sent out, the PEP starts executing again starting with the bladelet after the send reply bladelet. If no Send Reply bladelet is added to the PEP path, then the response is sent back to the client at the end of the PEP (default behavior).
Figure 3-38 Send Reply Properties Window
1
|
Input send message
|
The message to be sent as a reply from the PEP.
|
