Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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