Download Developer`s Guide v1.0

Virtual Node Developer’s
Guide
05/07/2013
This document contains technical information on how to develop new services in Virtual Node using
templates, XSLT transformations and workflow foundations.
Virtual Node Administrator’s Guide
Revision History
Change Record
Version
Number
1.0.00
Description of Change
Initial Draft
ii
Change
Effective Date
Change
Entered By
May 7, 2013
Dr. Yunhao
Zhang
Virtual Node Administrator’s Guide
Page 3 of 25
Table of Contents
1
Introduction .................................................................................................. 4
1.1
What is a Virtual Node?........................................................................ 4
2
Data Publishing Services ............................................................................ 4
2.1
Sample Database .................................................................................. 4
2.2
Generic Data Set ................................................................................... 5
2.3
SQL Statements and Parameters ........................................................ 7
2.4
Data Services Using Templates .......................................................... 7
2.5
Master-Slave Template Mapping ......................................................... 9
2.6
Common Template Tokens ................................................................ 10
2.6.1
GenerateID .................................................................................... 10
2.6.2
CurrentTime .................................................................................. 10
2.6.3
FieldName ..................................................................................... 10
2.6.4
FieldValue ..................................................................................... 11
2.6.5
FieldEncode .................................................................................. 11
2.6.6
ForEach ......................................................................................... 11
2.7
Using Template in Services ............................................................... 12
2.8
Data Services Using XSLT Transformation ...................................... 13
3
Data Submission Services ........................................................................ 15
3.1
Workflow Foundation ......................................................................... 15
3.2
Virtual Node Workflow Tool Box ....................................................... 16
3.3
Developing Custom Workflows ......................................................... 17
3.3.1
Workflow Input Parameters and Properties ................................... 18
3.3.2
Output Parameters and Expected Behaviors ................................ 19
3.3.3
Service Properties for Workflow .................................................... 20
4
Executable Services .................................................................................. 22
4.1
Scheduled Tasks ................................................................................ 22
5
Transfer Files to Virtual Node ................................................................... 23
6
Appendix .................................................................................................... 24
6.1
Generic Data Set Schema .................................................................. 24
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 4 of 25
1 Introduction
1.1
What is a Virtual Node?
Virtual node is a state of art Network Node implementation for the cloud
environment, offered as a service (SaaS, Software as a Service). While the
owner controls its security and functionalities, operations and maintenance will
be supported by the hosting party.
In Virtual Node, data publishing services under the Query and Solicit methods
are drastically simplified. The task is reduced to creating an SQL statement and
authoring a template file or XML style-sheet. As for supporting incoming data
submissions, the task is as simple as selecting the correct workflow process from
an existing workflow library. This document discusses technical details on how to
implement node services under common application scenarios.
2 Data Publishing Services
Data publishing services are services to provide information from your internal
relational databases to external users or application. They are typically outgoing
flow of information from a network node. In the Exchange Network Node
Functional Specifications, such services are implemented under the Query and
Solicit method.
2.1
Sample Database
Throughout the document, we will use a sample database consists of three
tables, Customer, Order and Product as shown below:
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 5 of 25
Customer
CustID
Company
Address
City
Region
PostalCode
Country
Phone
Orders
OrderID
Product
ProdID
ProdName
UnitPrice
CustID
ProdID
OrderDate
Quantity
Descript
ShipWt
The relational database has two tiers of one-to-many relationships: A customer
could have multiple orders, and each order may contain multiple products.
2.2
Generic Data Set
One of the key components in the data publishing process is XML schemas,
which determines the format and structure of published contents. The Generic
Data Set Schema is a schema for modeling arbitrary result set from a database
query. A result set from a query statement may have multiple rows and each row
could have any number of fields. Such a structure is essentially a tabular format
regardless the data contents.
So, a Data Set is an array of records in the form of XML schema as shown
below:
<complexType name="DataSetType">
<sequence>
<element name="record" type="typens:DataRecordType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
The minimum occurrence of records is 0 due to the fact that a query might
generate empty result. The DataRecordType is a little hard to specify because
the select fields are unknown. Here is what it looks like:
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 6 of 25
<complexType name="DataRecordType">
<sequence>
<any minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="id" type="int" use="optional"/>
</complexType>
So, according to this schema definition, a DataRecordType is a series of XML
element with an optional id field. The id field is an integer that represents the row
ID in the result set. It is an important piece of information when paging is
supported by the service provider.
Although field in the record is defined as any, it should be just a simple string
type element without child. The following is an example instance document:
<DataSet xmlns="http://www.exchangenetwork.net/schema/dataset/2">
<record id="0">
<CustID>VILLF</CustID>
<Company>Village Food Boutique</Company>
<Address>2782 - 92nd Ave.</Address>
<City>Los Angeles</City>
<Region>CA</Region>
<PostalCode>90071</PostalCode>
<Country>USA</Country>
<Phone>(213) 555-6902</Phone>
</record>
<record id="1">
<CustID>VINEA</CustID>
<Company>Vine and Barrel, Inc.</Company>
<Address>12405 Aurora Ave. N.</Address>
<City>Seattle</City>
<Region>WA</Region>
<PostalCode>98117</PostalCode>
<Country>USA</Country>
<Phone>(206) 555-3378</Phone>
</record>
</DataSet>
The complete Generic Data Set Schema is available in the Appendix of the
document.
There are two important characteristics of the schema:
1. The schema is applied to all Query and Solicit services when no XML
schema is supplied and there is no custom template or XSLT file
available. In other words, you don’t need XML schemas in order to provide
data services.
2. There is no information lose in the Generic Data Set comparing with
record set. Instance documents of Generic Data Set can be transformed
into any other formats of a different schema, or even to plaint text file or
JSON.
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
2.3
Page 7 of 25
SQL Statements and Parameters
In order to publish database information, an SQL statement is required. The
virtual node use ODBC as its data access layer, so the SQL statement must use
ODBC standard SQL grammar.
In most of the situations, a data service could have parameters, and such
parameters must be formatted using:
{$ParameterName}
Or
{$ParameterName, DefaultValue}
Where ParameterName is the name of the parameter, and DefaultValue is
applied if there is no parameter value supplied by users at runtime. An SQL for
retrieving customer information by customer ID is shown below:
select * from customers where CUSTID = ‘{$CustomerID}’ and
Region=’CA’
The SQL statement will retrieve a specific customer record if a Customer ID is
supplied. However, if the CustomerID parameter is not supplied, the SQL
statement is reduced to:
select * from customers where Region=’CA’
All customers in the state of California will be returned. The default behavior
allows the service to continue to function even though some of the parameters
are not supplied by users.
2.4
Data Services Using Templates
The virtual node allows developer to construct any type of XML documents using
templates. A template is a text file that contains structural information of a
document plus tokens that will be substituted at runtime based on results from
database query or session related information. Using the customer query as
example, a template to construct an XML document could be:
<Customers>
{$foreach record}
<Customer>
<CustomerId>{$FieldValue(0,CUSTID)}</CustomerId>
<Company>{$FieldValue(0,Company)}</Company>
<Address>{$FieldValue(0,Address)}</Address>
<City>{$FieldValue(0,City)}</City>
<Region>{$FieldValue(0,Region)}</Region>
<PostalCode>{$FieldValue(0,PostalCode)}</PostalCode>
<Country>{$FieldValue(0,Country)}</Country>
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 8 of 25
<Phone>{$FieldValue(0,Phone)}</Phone>
</Customer>
{$endforeach}
</Customers>
A token in a template starts with ‘{$’ and ends with ‘}’. There are a couple of
tokens used in the file:


{$foreach record} and {$endforeach}: These are the control tokens that
loop through all records in the current result set selected by the Query
statement.
{$FieldValue(0, fieldname)}: The token is substituted with the value of a
field in the current record.
The result XML document will look like the following:
<Customers xmlns="http://www.exchangenetwork.net/schema/node/2">
<Customer>
<CustomerId>VILLF</CustomerId>
<Company>Village Food Boutique</Company>
<Address>2782 - 92nd Ave.</Address>
<City>Los Angeles</City>
<Region>CA</Region>
<PostalCode>90071</PostalCode>
<Country>USA</Country>
<Phone>(213) 555-6902</Phone>
</Customer>
<Customer>
<CustomerId>VINEA</CustomerId>
<Company>Vine and Barrel, Inc.</Company>
<Address>12405 Aurora Ave. N.</Address>
<City>Seattle</City>
<Region>WA</Region>
<PostalCode>98117</PostalCode>
<Country>USA</Country>
<Phone>(206) 555-3378</Phone>
</Customer>
</Customers>
There are a couple of interesting features in the template approach:
1. Mapping: Mapping is really easy with the token. CustID is mapped to
CustomerId in the sample. It is possible to do many to one mapping in the
template (mapping multiple field values into one XML element).
2. Flexibility: When schema changes, all you need to do is modifying the
template file. There will be no code changes and complicate deployment.
3. Powerful: You can use the template to model any kind of XML schemas,
or even render non-XML formats such as JSON. The virtual node support
REST service using the same template technology.
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
2.5
Page 9 of 25
Master-Slave Template Mapping
In relational databases, entities are often related to each other and stored in
different tables. For example, a customer may have multiple orders and each
order may contain multiple products. This is reflected to XML structure as parentchild-grandchild elements.
The drill down from customer to orders and then to productions can be
accomplished using template tokens with additional SQL statement as shown in
the following example:
<Customers>
{$foreach record}
<Customer>
<CustomerId>{$FieldValue(0,CUSTID)}</CustomerId>
<Company>{$FieldValue(0,Company)}</Company>
<Address>{$FieldValue(0,Address)}</Address>
<City>{$FieldValue(0,City)}</City>
<Region>{$FieldValue(0,Region)}</Region>
<PostalCode>{$FieldValue(0,PostalCode)}</PostalCode>
<Country>{$FieldValue(0,Country)}</Country>
<Phone>{$FieldValue(0,Phone)}</Phone>
<Orders>
{$foreach record "select * from orders where
CustId='{$FieldValue(0, CUSTID}'" }
<Order>
<OrderId>{$FieldValue(0,OrderId)}</OrderId>
<ProductId>{$FieldValue(0,ProdId)}</ProductId>
<Quantity>{$FieldValue(0,Quantity)}</Quantity>
<OrderDate>{$FieldValue(0,OrderDate)}</OrderDate>
<Products>
{$foreach record "select * from Product where
ProdId='{$FieldValue(0, ProdId}'" }
<Product>
<ProductId>{$FieldValue(0,ProdId)}</ProductId>
<ProductName>{$FieldValue(0,ProdName)}</ProductName>
<UnitPrice>{$FieldValue(0,UnitPrice)}</UnitPrice>
<Description>{$FieldValue(0,Description)}</Description>
<ShipWt>{$FieldValue(0,ShipWt)}</ShipWt>
</Product>
{$endforeach}
</Products>
</Order>
{$endforeach}
</Orders>
</Customer>
{$endforeach}
</Customers>
For each customer, a new SQL statement:
"select * from orders where CustId='{$FieldValue(0, CUSTID}'"
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 10 of 25
is used to retrieve all orders by the customer and then construct order related
elements. For each order, another SQL statement
"select * from Product where ProdId='{$FieldValue(0, ProdId}'"
is used to fetch all purchased products and build product related XML elements.
The nested drilldown process allows a developer to dynamically retrieve
information from different data sources and create complex XML structure in a
straightforward manner.
Another advantage of the template over XML transformation is its efficiency and
performance. The template technique yields much better performance comparing
with the fetch-all-and-transform process, due to the fact that the template
leverages database searches and it fetches only the information necessary for
constructing the current node.
2.6
Common Template Tokens
Virtual Node has a library of template tokens that can be used in a template file.
This section describes commonly used ones for data publishing purposes.
Please contact us if custom tokens are needed in your services, and we can
quickly support special requirements as necessary.
All tokens in the template library are case insensitive.
2.6.1 GenerateID
 Syntax: {$GenerateId}
 Description: The token generates a Universal Unique Identifier (UUID),
with a ‘_’ prefix. The generated Identifier is suitable value for the ID type in
XML.
 Example: _b08b9a2d-1eac-406c-b0b9-119e750024c1
2.6.2 CurrentTime
 Syntax: {$CurrentTime}
 Description: The token insert the current date and time in XML format
(formatted using %Y-%m-%dT%H:%M:%SZ).
 Example: 2013-09-10T10:34:05.233
2.6.3 FieldName
 Syntax: {$FieldName(n)}
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide


Page 11 of 25
Description: The token will be substituted by the name of a field in the
current result set. The parameter n is a zero-based integer of the field
index.
Example: {$FieldName(2)} – get the name of the third column.
2.6.4 FieldValue
 Syntax: {$FieldValue(n, m)}
 Description: The token retrieves a value from the current result set. n is
the index of a record and m is the index of a field. m can also be the name
of a field. Inside a foreach loop, n should always be 0.
 Example:
{$FieldValue(1, 9)} – Get the tenth field value in the second record of the
current result set.
{$FieldValue(0, Address)} – Get the Address value of the first record in the
result set.
2.6.5 FieldEncode
 Syntax: {$FieldEncode(n, m, encodeType)}
 Description: The token is similar to FieldValue except the value will be
encoded. FieldEncode should be used when a data value contains
reserved XML characters or is in binary format. The encodeType can be
base64, utf8 or html. The default encodeType is html which is sufficient for
handling XML special characters.
 Example:
{$FieldEncode(1, 9)} – Get the tenth field value in the second record of
the current result set, and encode the contents as needed.
2.6.6 ForEach
 Syntax: {$ForEach record SQLStatement}
 Description: The token is a control command that loops through all
records in the current result set. If a SQL statement is not supplied, the
system uses an SQL statement from the current service definition. The
ForEach token must be used in-pair with the EndForEach token.
 Example:
{$foreach record "select * from orders where CustId='{$CustomerId}'" }
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
2.7
Page 12 of 25
Using Template in Services
It is very easy to configure a Query or Solicit service using template. The
screenshot below shows a service using GetCustomerList.xml as a template.
The example service shown above retrieves customer information given the
CustmerId as a parameter. The result XML is constructed using a template file
named GetCustomerList.xml in the TEMPLATE directory.
Custom templates can be uploaded to the server using the Transfer File utility in
the VNAP (Virtual Node Administrative Platform).
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
2.8
Page 13 of 25
Data Services Using XSLT Transformation
Another approach of mapping database information into XML document is to use
XSLT transformation. The process of data publishing is outlined below:
1. A complete SQL statement is supplied to fetch all columns needed for
constructing an XML instance document based on the schema. In order to
simply XSLT transformation, the SQL statement use alias to map the
column names to XML element names whenever possible (i.e., SELECT
ColumnName as XMLElementName).
2. Virtual Node executes the Query statement at runtime and fetches all
records selected.
3. Virtual Node constructs an XML document using the standard dataset
schema.
4. The dataset XML document is transformed using the XSLT style-sheet
into XML document that is conformant to a set of XML schemas.
The process is depicted in the figure below:
Node Service
Reuqests
SELECT NODEID as NodeID, URL
as NodeAddress FROM Node
Query
Processor
Data Access
Component
SQL SELECT
WITH
MAPPING
SQL Builder
Data Set XML
Flat
XML
Transformati
on
Target XML
Instance
Document
XSLT Stylesheets
Database
XSLT
Generator
Tool
XML Schemas
Using the previous example, the SQL statement would be something like:
SELECT Customer.CustID AS CustomerId, Customer.Company,
Customer.Address, Customer.City, Customer.Region, Customer.PostalCode,
Customer.Country, Orders.OrderID, Orders.ProdID, Orders.OrderDate,
Product.ProdID AS ProductId, Product.ProdName, Product.UnitPrice,
Product.Descript, Product.ShipWt FROM Customer LEFT JOIN Orders ON
Customer.CustID = Orders.CustID LEFT JOIN Product ON Orders.ProdID =
Product.ProdID WHERE Customer.CustID = '{$CustID}'
It is a little complex due to the fact that there are two joins among three database
tables. The SQL statement selects all columns from three tables and uses alias
to map some field names to XML element names inside the SQL statement.
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 14 of 25
The style-sheet to transform the raw DataSet document into a target schema
would be:
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:v1="http://www.exchangenetwork.net/schema/dataset/2" exclude-resultprefixes="v1">
<xsl:output method="xml" indent="yes" omit-xml-declaration="yes"/>
<xsl:template match="/">
<Customers >
<xsl:for-each
select="v1:DataSet/v1:record[not(self::v1:record/v1:CustomerId=followingsibling::v1:record/v1:CustomerId)]">
<xsl:variable name="customerId" select="v1:CustomerId"/>
<Customer>
<CustomerId>
<xsl:value-of select="v1:CustomerId" />
</CustomerId>
<Company>
<xsl:value-of select="v1:Company" />
</Company>
<Address>
<xsl:value-of select="v1:Address" />
</Address>
<City>
<xsl:value-of select="v1:City" />
</City>
<Region>
<xsl:value-of select="v1:Region" />
</Region>
<PostalCode>
<xsl:value-of select="v1:PostalCode" />
</PostalCode>
<Country>
<xsl:value-of select="v1:Country" />
</Country>
<Phone>
<xsl:value-of select="v1:Phone" />
</Phone>
<xsl:for-each
select="v1:DataSet/v1:record[v1:CustomerId=$customerId][not(self::v1:record/v1:Ord
erID=following-sibling::v1:record/v1:OrderID)]">
<xsl:variable name="orderId" select="v1:OrderID"/>
<Order>
<OrderId>
<xsl:value-of select="v1:OrderId" />
</OrderId>
<ProductId>
<xsl:value-of select="v1:ProductId" />
</ProductId>
<Quantity>
<xsl:value-of select="v1:Quantity" />
</Quantity>
<OrderDate>
<xsl:value-of select="v1:OrderDate" />
</OrderDate>
<Products>
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 15 of 25
<xsl:for-each
select="v1:DataSet/v1:record[v1:CustomerId=$customerId][v1:OrderID=$orderId][not(s
elf::v1:record/v1:ProdId=following-sibling::v1:record/v1:ProdId)]">
<Product>
<ProductId>
<xsl:value-of select="v1:ProductId" />
</ProductId>
<ProductName>
<xsl:value-of select="v1:ProdName" />
</ProductName>
<UnitPrice>
<xsl:value-of select="v1:UnitPrice" />
</UnitPrice>
<Description>
<xsl:value-of select="v1:Description" />
</Description>
<ShipWt>
<xsl:value-of select="v1:ShipWt" />
</ShipWt>
</Product>
</xsl:for-each>
</Products>
</Order>
</xsl:for-each>
</Customer>
</xsl:for-each>
</Customers>
</xsl:template>
</xsl:stylesheet>
There are three levels of XML nodes, namely Customer, Order and Product,
which are enclosed by three XSL for-each loops. The tricky part of the for-each
loop is to prevent redundant record from being constructed (many-to-many
relationship). This is done by checking the following sibling ID so that it is not the
same as the current element. The filter below is an example:
[not(self::v1:record/v1:CustomerId=following-sibling::v1:record/v1:CustomerId)]
Although looking intimidatingly long, the XSTL file has a clear pattern in the
structure and it could be constructed systematically.
3 Data Submission Services
3.1
Workflow Foundation
Virtual node uses Windows Workflow Foundation extensively for all major
business process units. Unlike traditional programming model where
programmers write code line by line, a business process is composed using
blocks of shared components in workflow design and development. The result of
workflow development is a declarative XML document that contains all the
business logic. Workflow files, in XAML (Extensible Application Markup
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 16 of 25
Language), are compiled to assembly models at runtime by virtual node to
improve performance.
Virtual Node support two versions of Workflow Foundations: v3.5 and v4.0.
Developers should use the latest workflow foundation framework whenever
possible. All major network node methods, such as Submit, Query, Solicit, Notify
and Execute, may be handled by a workflow process.
3.2
Virtual Node Workflow Tool Box
The basic building blocks for creating workflow are called activities. They are
provided as widgets in the workflow designer where you can drag and drop into
the designer surface. In addition to Microsoft supplied activities, virtual node has
a set of custom activities to further simplify network node operations and web
service accesses. The custom activities can be installed in the virtual studio tool
box as shown below:
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 17 of 25
Please contact the node helpdesk for these toolbox items before building your
own workflows.
3.3
Developing Custom Workflows
A windows workflow is in the standard XAML (Extensible Application Markup
Language) format. It can be authored using any text editor, but the best
authoring/designing tool is Microsoft Visual Studio. The following screenshot
shows an example workflow in Visual Studio XAML designer. It is a working
version of our GenericSolicit workflow that turns any Query service
(synchronous) into a Solicit service (asynchronous).
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 18 of 25
3.3.1 Workflow Input Parameters and Properties
A workflow can be viewed from outside as a black box with inputs and outputs.
Input parameters are provided by the virtual node environment. When executing
a workflow, virtual node provides all necessary information to the workflow as
dictionary entries (name-value pairs).
Property Name
UserId
NodeId
DataflowName
TransactionID
Description
Requester’s NAAS ID
The node identifier
The name of a dataflow
A unique identifier assigned to the
transaction. This is usually used as the
workflow ID as well.
Service Parameter
ServerAddress
NodeDSN
Description
The virtual node address
The Node ODBC Data Source Name
(DSN)
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Stylesheet
service.SerivceName
service.SerivceType
service.Status
service.SQLStatement
service.Template
service.Workflow
Transaction Parameter
TransactionId
NodeId
Dataflow
Method
Request
UserName
NotificationURI
Recipients
Status
StatusDetail
PostTime
Page 19 of 25
The XLST style-sheet for the service.
The name of the service invoked.
The type of service - usually is Submit,
Query, Solicit and Execute.
The service status
The SQL statement defined for the
service. This is usually for Query and
Solicit.
The path of a template file.
The name of the workflow file.
Description
A unique identifier for the transaction
The virtual node identifier
The name of the dataflow
The method name (Submit, Query
etc.).
The name of a service request
The user’s NAAS ID.
The URI for user or node notification. It
is only available for the Submit method.
A list of recipients for the transaction.
This is passed from the Submit
method.
The current transaction status
The detailed description of the status.
The date and time when the
transaction was received.
Note that workflow properties are handled differently than parameters in workflow
engines prior to Workflow Framework 4.0.
3.3.2 Output Parameters and Expected Behaviors
In the synchronous mode, the virtual node will wait for response from a workflow.
It then uses the GetNextOutputParameter defined in the workflow engine
interface to retrieve all output variables. Output variables are typically stored in a
dictionary and can have arbitrary names. However, for Query method, a workflow
must return a variable named _dataset. It is a string that contains constructed
XML document.
In case a workflow failed during execution, a synchronous workflow should
provide transaction status and error information by setting the Status and
ErrorMessage variables in the output dictionary.
Output Parameter
Doc Ref # & Location
Description
7/14/2017
Virtual Node Administrator’s Guide
_dataset
Status
ErrorMessage
Page 20 of 25
XML instance document returned from
a Query workflow.
The transaction status.
The detailed error message when
failed.
In asynchronous mode, the call to execute workflow process will return
immediately. It is the workflow’s responsibility to update transaction status in the
transaction table.
3.3.3 Service Properties for Workflow
In addition to properties and parameters defined above, any service properties
associated with the service definition are also fed into workflow. In a scenario
where a node needs to retrieve information from local DBMS and then submit to
CDX, the submission target address, dataflow name and service name must be
supplied. The following screenshot shows a service with additional properties for
a workflow process:
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 21 of 25
A workflow designer and administrator can choose any properties for a service
and workflow, but for better consistency and interoperability, the following
standard service property names are defined:
Name
TargetEndpoint
TargetDataflow
TargetService
Doc Ref # & Location
Description
The endpoint of a remote network
node.
The dataflow identifier to be used when
invoking the remote node.
The service identifier in the remove
service call. The value should be the
flowOperation for Submit or request for
Query (See Node Functional
Specification 2.1 for additional
7/14/2017
Virtual Node Administrator’s Guide
Compress
HeaderTemplate
EmailTemplate
NotifyUsers
Page 22 of 25
information.
This is a Boolean flag (true or false)
indicating whether data should be
compressed or not before delivery.
This determines whether a Document
Header should be used or not. There
are two header templates,
Header_v10.xml and Headerv_20.xml
(version 2.0 header).
This is an optional template file for
sending status notifications. Virtual
node uses a default template if not
provided.
A listed email addresses, separated by
comma, for email notifications.
4 Executable Services
Executable services are services not directly related to data publishing (Query) or
incoming document processing (Submit). They are typically invoked using the
Execute method. Executable services provide extension mechanisms in a
network node. In virtual node, executable services are the basic units for all
scheduled tasks.
Another scenario where Executable Service plays important role is when it acts
as a Node Client, i.e., submitting data, downloading file or retrieving information
from a remote network node.
4.1
Scheduled Tasks
A scheduled task is a work unit to be performed at a specific time or interval
automatically. In Virtual Node, scheduled tasks are tightly integrated with
Windows Task Scheduler.
A scheduled task has three key components:


A Workflow Definition: The workflow defines what to be done. The virtual
node supplies a list of predefined workflows for submitting data to CDX,
soliciting/downloading information, and so on. You are encouraged to
develop custom business processes using Microsoft Workflow
Foundation.
An Execute Service Definition: The service definition makes the
operations visible. You must associate the workflow to the service
definition.
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide

Page 23 of 25
A Task Definition: A task definition specifies when a service should be
executed automatically as well as trigger frequency.
A task definition has the following elements:








Task Name: The name of a task. It should contain alphanumeric
characters without any white spaces.
Task Description: A short description of the task.
Dataflow: The name of a dataflow.
Service: The name of a service to be executed when triggered. The
service must be of type Execute (Executable Service).
Task Schedule Type: This is frequency a task is triggered. It can be
Minutely, Hourly, Daily, Weekly, Monthly and Yearly.
Start Time: This defines when the starting boundary of the task.
Trigger Time: This is the time when the task will be executed.
Status: The status of a task. It should be either Enabled or Disabled.
The example task above uses a service named CollectTransactions, which
retrieves a list of transactions and submits it to a CDX node.
5 Transfer Files to Virtual Node
In situations where custom workflows, templates, or XSLT style-sheets are
created, the files must be transferred to the virtual node. This is accomplished
using the File Transfer utility in VNAP as shown below.
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 24 of 25
An administrator can upload and download files to/from a virtual node. Uploaded
files are stored at a virtual directory with the same name as the node ID. For
example, if you upload a file “MyTemplate.tmpl” to a node named MyNode, the
file should be referenced using:
/MyNode/MyTemplate.tmpl
in service definitions.
6 Appendix
6.1
Generic Data Set Schema
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:typens="http://www.exchangenetwork.net/schema/dataset/1"
targetNamespace="http://www.exchangenetwork.net/schema/dataset/1"
elementFormDefault="qualified">
<annotation>
<documentation>
Schema Name : dataset_v1.0.xsd
Current Version Available At :
http://www.exchangenetwork.net/scheam/dataset/1
Description : Generic Data Set Schema.
Technical Contact : Dr. Yunhao Zhang ([email protected]).
</documentation>
</annotation>
<complexType name="DataFieldType">
<simpleContent>
<extension base="string">
<attribute name="name" type="string" use="required"/>
Doc Ref # & Location
7/14/2017
Virtual Node Administrator’s Guide
Page 25 of 25
</extension>
</simpleContent>
</complexType>
<complexType name="DataRecordType">
<sequence>
<any minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="id" type="int" use="optional"/>
</complexType>
<complexType name="DataRowType">
<sequence>
<element name="field" type="typens:DataFieldType" minOccurs="1"
maxOccurs="unbounded"/>
</sequence>
<attribute name="rowName" type="string" use="optional"/>
</complexType>
<complexType name="AnyDataRowType">
<sequence>
<any namespace="##any" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="objectName" type="string" use="optional"/>
</complexType>
<complexType name="DataSetType">
<sequence>
<element name="record" type="typens:DataRecordType" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="dataSet" type="typens:DataSetType"/>
</schema>
Doc Ref # & Location
7/14/2017