Web-IDE: User Guide

ZOAPIIO Overview

is a one-of-a-kind on-line build-and-host development environment.

's unique Web based Development Environment (Web-IDE) takes the task of building server Web-APIs out of traditional boundaries and puts it in the hands of everyday users. If you have a good understanding of your business requirements, and a basic exposure to XML, JSON and concepts of programming logic, you can build, deploy and use Web-services (or APIs) in . Introductory and refresher public resources on programming concepts and XML/JSON are freely available on the Internet.

has several use cases and can be used in different configurations depending upon the requirements.

Unboxing - First look

If you are just getting started and have not already seen this video, we suggest you view it now.

Web-IDE is targeted to non-experts, and this guide is presented with that in mind. If you have prior programming experience, you may skim over some sections.

Introduction to Web-APIs

Hello, World!

A great way to get familiar with a new environment is to learn by example. That is why every introduction to a programming environment starts with a "Hello, World!" example. While we do not have an exact equivalent here, Web-IDE provides built-in sample applications that help you ramp up quickly. We recommend that you use the information presented here with the sample applications and learn by example.

You can sign-up for a free on-line instance on ZOAPIIO.COM and get started right away.

What is Web-API

API stands for "Application Program Interface" and its basic purpose is to allow two modules within an application to interact with each other - like a telephone call does for two individuals. One application initiates the call to another through the API, and data is exchanged. The data exchange could be one-way or two-way. To illustrate using an example, the payroll module of your ERP may need information on the number of days an employee attended office, information that is available with the HR module. A simple API between the two would enable the payroll application to compute each month's payroll without any human intervention.

A Web-API (also known as Web-service) is similar, except that it allows two entirely different applications, possibly owned by two completely different parties, to interact using the Internet as the medium. The data is exchanged both ways and format used to package the exchanged data is usually XML or JSON. As you are probably already guessing right now, security plays an important role in Web-APIs because the medium is a public medium.

Web-APIs have an advantage over conventional APIs in that the communicating applications need not be based on a common technology, environment, or programming language. If each supports the HTTP protocol, they can communicate. This advantage has led to its fast acceptance - architects now prefer to use Web-APIs even to communicate within an application, even though they share the same technology. This keeps the integration open and future-proof. It is also for this reason that the Web-APIs and Web-Services are now simply referred to as the APIs.

For request and response messages, the format and content (fields and structure) is fixed and each party knows what to expect and what each field means. XML and JSON formats allow the request/response messages to be human readable and hence easy to understand. If you are a provider of an API, you are free to decide the structure of the message and then share it with the API clients. If you are consuming services provided by others, then you need to know the structure published by them so that you can prepare and interpret the messages accordingly.

HTTP Transport

Web-APIs work using the HTTP transport - this means that the same HTTP protocol that you use to browse the web is also used to send and receive information in a Web-API. In fact, some Web-APIs (though not all) can be accessed from the browser itself. A Web-API is a resource on the web, like a webpage. It has an endpoint (or entry point) which is identified by a URL - quite like the URL that you type in your browser to reach a webpage.

Web-APIs will typically be invoked from another application or program - but for the purpose of testing, you will need a mechanism to invoke them from a test environment. Some Web-APIs can be directly called by typing their URL in your favorite browser. For others, you will require a desktop tool which allows greater control on how the APIs are called. A popular tool that lets you do this is 'Postman' - it is recommended that you install this on your desktop because you will need it to test your Web-APIs. Another similar tool is SoapUI, which also supports SOAP - if you plan to build SOAP services, then you should install SoapUI.

HTTP requests most commonly use a GET or a POST method (although other methods are also there) for communication. A GET request can carry information forward only as a part of the URL, which is difficult to read and has size limitations - it is useful when the outgoing message is small and simple. The POST request can carry arbitrary sized data which is sent separately from the URL and is preferred when the outgoing data is large or complex. Both GET and POST can receive data of any size and in any format - typically, HTML, XML or JSON.

MQ Transport

A lesser used but still useful way to communicate over the web is the Message Queue transport. HTTP communication is synchronous - means that the data is exchanged within the same unit of transaction. A message sent using the Message Queue, on the other hand, is not processed immediately but queued for later processing. The Client does not receive the response of the message handling. MQ transport is useful when the communication is mostly one-way, and the traffic is high - implying that the requirement of an immediate response will create a high-load situation on the servers. A class of applications that make heavy use of MQ transport is in the field of IOT. Typically, the number of devices is quite large in the network and each device is mostly engaged in one-way communication of reporting its status to the application.

SOAP Protocol

SOAP is another protocol for using Web-APIs that is also based on HTTP but has some differences in the way it works. You can look-up the details of the SOAP protocol on the Web if you are interested, but SOAP is losing popularity, and we advise you to use HTTP services for your application. However, it is possible that you may still need to deal with SOAP because a service that you need to consume from another provider uses SOAP protocol.

Web-Socket

Web-Socket is a special purpose communication protocol used in high-traffic situations. A conventional Socket in programming represents a permanent two-way channel between two communication parties. The communication is not transactional, but data is continuously transmitted in both directions. Since the connection is permanent (for the life of the socket), no time is wasted in establishing the connection with every message.

A Web-Socket is an adaptation of Socket functionality over HTTP and provides similar capability that Sockets do. Web-Sockets generally do not figure in business applications and the chances of you requiring them are low. However, allows you to build Web-Socket services.

GraphQL

GraphQL is another convenience construct used in client-server communication over the web. It also uses the HTTP GET/POST as underlying transport mechanism, but the messages have a certain structure that carries operational instructions to the server along with the data. The most common GraphQL feature is the ability to specify the fields that should be returned in the response.

GraphQL is gaining popularity but developing GraphQL server is much more complex than classical HTTP REST APIs. Fortunately, allows you to write GraphQL services with utmost simplicity. It is still an advanced subject, and most projects are based on HTTP/REST services. Should you require GraphQL for your project, ZOAPIIO has full support.

ZOAPIIO Programming Model

Your Programs (server) are-

1. Composed of Web Services - almost all API types are supported (See the Introduction above).
2. Written using a high-level abstraction language allowing you to write the business logic without concerning with underlying Java programming constructs.
3. Parts of your application can be written in Java programming language. This is useful, at times essential, in managing complex computational tasks.
4. The data schema declares the structures of communication messages, database storage, and transient storage.
5. The programs are saved in a proprietary format (XML format).
6. Basic version control is applied to your project file.

The schematic below provides an overview of the components in a ecosystem. The Application container is fully managed and is hosted on the cloud.

Abstraction

The proprietary abstraction language (4GL) is very compact and powerful. leverages the power of XML (hierarchical structures) and abstracts all entities in your development environment as XML nodes. This means that you access all elements of your programming environment as if they were a part of one large XML document. For instance, a database table appears as a node in your project Schema - takes the responsibility of mapping the node to the underlying entity, the database table in this case. Same is true of all entities in the system. You, as API developer, do not have to be concerned with technical internals like where the database is located and how the data is retrieved and updated.

The abstraction principle used by , greatly simplifies your programming experience and sharply reduces the learning curve. It is also responsible for a large part of the productivity gains.

Logic Builder

1. To add a command, or a data element (expressions, constants and Data paths) select from the menu on the left and then drop it on the program block.
2. An item (commands, data elements) can be attached to an appropriate point in the program block using its connector.
3. The Web-IDE will not allow you to connect a selected item where it does not belong.
4. To remove an item from the program block, simply drag it into the recycle bin (at the bottom right corner).
5. You can move items in the program block by dragging them out or their present position to a new position.
6. You can drag an item from the data schema window and attach it at a point that expects a Data path.
7. You can edit the values inside items, or choose from the provided drop-down, where appropriate.
8. As you type the Data paths and expressions in the program block, Web-IDE will validate them and flag errors if any.
9. The right-click on an item in the program block will show you the context menu, from where you can access utility functions like enable/disable, duplicate, etc.

Schema

Recall your first programming course, where you learnt that a computer program is data+logic - don't worry if you never went to a programming school, you've learnt it now. In most environments, the data elements that your program would use are declared beforehand and a datatype is attributed to it so that computational operations on it can be validated and appropriately handled.

In your data elements are hierarchical structures in direct correspondence with the structure of the Web-API messages which are also hierarchical. The data elements are declared in the Schema - the left panel in your Web-IDE window. As you should expect, much of your schema will be composed of the messages that you exchange with clients and other services. Additionally, you will have some working data structures that are used to store intermediate results and temporary data.

Reusable Structure Declarations

Many messages in a Web-API have the same structure, and it is only natural that they are declared only once and then used multiple times. Otherwise, your schema can become very complex and large - not to mention, a nightmare to maintain. provides the TYPES node in the schema for this purpose. The contents under the TYPES node have the same declarative format, but do not have any storage associated with them. They must be referenced in the Data Schema before they can be used.

Data Schema

You will declare data element structures to be used by your Web-APIs directly under the Schema, or you can organize them as sub-nodes under a root level group. This helps keep large projects manageable and easy to read. In , you will declare your working data elements under the VARIABLES node - they can be hierarchical structures just like everything else. Using VARIABLES node to declare your working data is not strictly a requirement most of the time, and you can declare them anywhere. Except when writing the logic for your Web-APIs, some index references are required to be under the VARIABLES node. For clarity, it is recommended to keep your working data separate under VARIABLES.

Your session variables (again, can be hierarchical) are declared under the SESSION node. See Application Session

The Schema will also contain all abstracted entities in the system, which, as explained above, appear as XML nodes. Some of the entities abstracted in are-

Programming

The data in your project needs to be processed - you provide Web-APIs for this purpose and write the processing logic (or the program) against these. In line with 's abstraction approach, the processing details are also captured as a part of the project Schema. The "Business Flows" node in the schema is used for the purpose of declaring, among other things, the Web-APIs that you provide.

The building of programs, or programming, has traditionally been a complex task meant for experts. To make matters worse, this complexity has grown over time with the introduction of frameworks, such as Spring, as it dramatically raises the entry level skill requirements for your programmers.

The algorithm

An algorithm is like a recipe that contains step-by-step instructions on how to start from raw input (ingredients) and arrive at the output (the finished dish). Think of branching and iterations like you would find in a recipe. E.g., "if gas oven, pre-heat for 10 mins, else if electric oven, pre-heat for 20 mins" (condition), or "stir gently until light brown" (iteration).

For your programs, under the "Business Flows" node in schema, you declare the following-

Data Paths

In Web-IDE, you will refer to data elements using the Data Paths. Data Path is a powerful abstraction that hides the complex processing details, which a programmer must deal with in a conventional development environment. Depending upon the underlying entity that a schema node is abstracting, will deal with it accordingly. It should be pointed out here for advanced users that the Data Path is syntactically not same as the XPATH, although it is similar.

It is important to note that the schema in the Web-IDE is only a declaration, and not everything in it will contain actual data. When your Web-API executes, the data schema is populated as the processing continues. At the start, the contents of the REQUEST (or the alternative that you have declared with your Web-API definition) is populated from the incoming request. In the case of SOAP service, the input is populated from the SOAP request. The contents of the SESSION are also fetched.

Other parts of the schema will be populated inside your processing logic. You can freely read or change the contents of the data at runtime. Before your Web-API finishes execution, you should - at the very least - put values in the part of the data tree that comprises of the response (defined with the Web-API declaration). takes care of returning the data to the caller in the appropriate format using the right protocol.

Data Paths look like the file pathnames in your Windows (or Linux) OS. In XML the forward slash (/) is used as the path separator and it separates the name of the elements in your schema, quite like your folder path. Starting from the root node (like the root folder in your file system) you can traverse to any node in the XML data tree, by naming the next element name and separating it with the slash.

Similarity with the file pathnames continues as the Data Paths also have an absolute pathname and a relative pathname. Like you have a default (or the current folder) in your file explorer, inside your program there is the concept of a context path. If there is a context path, then you can use a relative Data Path (I.e., not starting with a slash) and start traversal from the context path.

Indexes and Keys

It is permissible and quite common to have multiple instances of an element in the data tree. An example case would be if you are passing a list of, say, Employees all having the same data structure. In schema you will declare such elements with the attribute "Duplicates" checked.

You need a mechanism to individually access such items - offers two methods to address each individual item in the list - Indexes and Keys. The index appears in square brackets [] and immediately follows the element name. E.g., Employee[10] would refer to the 10th Employee node in the tree. Note that the indexes start from 1 (unlike most programming languages, where indexes start at 0) and if no index is provided, it defaults to the first.

Inside the program you can also use a variable for the index. If you have an element declared under VARIABLES (or _LOCALS - See Declare statement) node of type NUMBER, then you can use that as a variable index. When using a variable index its name should be prefixed with a "#". E.g., Employee[#I] refers to the "I"th Employee where I is the value stored in the node /_LOCALS/I or /VARIABLES/I - searched in that order.

The index value zero (0) is used for a specific purpose. It always points to a new element at the end of the existing list of nodes. Be careful, when using the zero index in a path - every time the path is evaluated, a new element would be created.

To use Keys, the element that is a list should be a group Element and at least one of the elements inside it should be declared as a key ('Is Key' attribute should be checked). The key of each Element in the list is formed by taking each key field in it and concatenating them by the bang (!) character. To access an Element by key, you will enclose it in curly braces {} and put it immediately after the Element name. E.g. Employee{M100}, would select the Employee node whose key is the string "M100". You can use variables in Keys, just like you use them in indexes, except the variable need not be a number. E.g., If Employee Id is the key for the Employee Element, Employee{#EID} would select the Employee with Employee Id 'EID', where EID is an Element under /_LOCALS or /VARIABLES - searched in that order.

Attributes are a construct used in the XML representation of data but has no equivalent in JSON. Attributes are used to specify additional information about the XML node. E.g., in XML <Employee Type="Full-Time"> Type is an attribute. It is possible to have "Type" as a sub-node of the Employee node, but attributes improve readability. E.g., the same can be achieved using <Employee><Type>Full-Time ...

In you will declare ATTRIBUTES under the TAG nodes, but if you are using JSON formats for your messages, it is better to avoid them. In the Datapath, the attributes are referenced by putting the attribute name in the end separating it from the rest of the path with an "@". E.g Employee@Type.

abstracts a Web Scraping data source like everything else. The elements appearing on the web page are referenced using data paths. There are some differences, however, in the treatment of Web Scraper elements.

1. The structure of the HTML content in a scraper is not declared in advance - it is not possible to know up front the contents of the web source.
2. In data paths for web elements, the separator (/) is interpreted differently. Normally, the sub-path must be present directly under the parent. But in case of web elements, the sub-path can appear anywhere under the tree below the parent node.
3. The index for a web element can use attribute selection (See below).
4. The web elements can have a second index, which acts as the index described above.

The attribute selection in Web element data paths serves to identify nodes in the HTML page by their attributes. The syntax of the index is-

• The index is delimited within square brackets - [].
• The attribute name is prefixed with '@'.
• Colon (:) acts as the separator.
• Attribute Value is specified, must exactly match the web element.
• Alternatively a double colon (::) is used to indicate loose match - the given value must appear anywhere in the web element attribute.
• Special attribute 'text' refers to the HTML text in the element.

Expressions

In , Expressions are used for manipulating the values in the data tree. This means that for almost everything that you need to do in the program, you will be needing an expression. Thankfully, expressions are simple, and you already know them. E.g., "4 + 4" is a simple expression to say that the two given numbers need to be added. The expressions are made up of operands (values participating in the computation) and operators.

In programming, you use variables to hold values - so if you have two variables I and J, then expression "I + J" would mean the values of variables I and J need to be added. The two can, of course, be mixed as in "J + 4".

Data Types of the operands participating in an expression play an important role in how the expression is evaluated. For instance, the addition operation (+) is treated as a concatenation for string operands, and as numeric addition for numeric operands.

All programming languages need to know the data type of the operands - some expect to be explicitly declared, while others infer it implicitly. expects the Data types to be declared. When defining the TAG elements in your data schema, you specify a Data type.

The expressions are made up of operands (values participating in the computation) and operators (the operation). All programming languages support almost the same common set of operators, as does - and some additional ones.

The expressions that you will typically write will be more complex than the simple expressions discussed so far. Even the most basic computation like addition will have two operators - one for computation and the other for assignment. More complex expressions will have even more. E.g., an expression like "A = B + C - 5". It has three operators in it. That is why you need to understand operator precedence.

Precedence decides in which order the operators are evaluated. Expression "A = B + 5" does not end up assigning B to A and then adding 5 to the result. This is because the assignment (=) has a lower precedence than the addition (+). The higher precedence operator is evaluated first, and that is why the result of adding B and 5 is assigned to A in this case. Within operators of same precedence, the evaluation is performed from left to right. As another example, expression "A = B + C * 5" will evaluate "C*5" first then add "B" to it and assign the result to A.

The operator groups in order or precedence from highest to lowest are-

1. * / %
2. + - ~ ~~
3. == < > <= >= <>
4. &&
5. ||
6. = += -=
7. ,

If you have an expression that requires an order of evaluation different from the natural order, you can use parentheses to force an evaluation order. The content inside the parentheses is evaluated first, irrespective of the precedence of the operators. For instance by putting parentheses around "B + C" in the example above- "A = ( B + C ) * 5", the evaluation order is changed to evaluate "B + C" first. Parenthesized sub-expressions can be nested to create more complex expressions.

adds certain attributes and data elements in the runtime Data tree in line with its abstraction approach. These pseudo attributes and elements are mainly used for easier access to some functions and to communicate information back to your programs. For example, when you execute a database operation, how do you know if the operation encountered an error. reports the status of the database operation through a Pseudo element (_STATUS) under the Table node. E.g., /Employee/_STATUS would contain the status of the last database operation on the table "Employee".

The names of all pseudo attributes and elements begin with an underscore (_), so it is advised that you do not use names in your schema that start with an underscore. The following is the complete list-

The following pseudo elements can be used to dynamically override values in your project config.

Statements

The statements (or commands) are what you use in your program to do things. They are the basic building blocks of your program, and you put them in the right order to convert your business algorithm into a working program. In Web-IDE, you do not need to remember any command names as the drag-drop intuitive UI does it all for you.

Iterating over Nodes/Rows

One the things you will find yourself doing very frequently in your programs is iterating over a set of nodes. Typically, when your program receives an input message containing a list, you must process all items in the list. Another similar requirement is when you read a database and you must process all rows that are in the result set.

In abstraction world, both these situations are treated as the same. That a Database is a different entity from a Data tree node, is hidden from you and you view each case as a single case of iterating over a set. The "ForEach" statement is used for iterating over a set. You specify a Data path to represent the set - this is best understood through the examples-

1. /REQUEST/Employee would represent all "Employee" elements under "/REQUEST". The ForEach loop will start at the first Employee node and then proceed sequentially through the list.
2. The Data path /REQUEST/Employee[3], would start at the 3rd Employee node and will continue up to the end.
3. If "Employee" is a DB table in your project, then the Data path /Employee, would represent all rows in the currently open result set on the table. When the loop completes, the system automatically advances to the next row in the result set. The result set is opened using "Database open" or "DbQuery open" statements.

The ForEach statement allows an optional "Where" condition, which causes the loop to skip over nodes where the given expression evaluates to false. This also works with Database Tables and MongoDB collections. When an expression is used when looping over Database or Mongo nodes, the Database/Collection open and close operations are automatically performed using the expression provided - no explicit open/close is required.

With the "ForEach" statement you can specify a Loop Variable - the name of a Data element declared under /_LOCALS or /VARIABLES with Data type "NUMBER". If a loop variable has been specified, it will be updated with every iteration to indicate the sequence number of the current loop, starting at 1.

Web-API Security

The Internet is a public medium, and unless the information your Web-API deals with is free and public, it needs to be protected from unauthorized use. For starters, it is recommended that you use the secure HTTP (or HTTPS) for endpoints of your Web-API. This ensures that the data being exchanged cannot be read by a third-party and only the sender and receiver can see its contents.

A basic security mechanism can be used that requires every request to be accompanied by a username and a password. The username and password are sent with the request as HTTP headers and before the service is invoked the credentials are verified against stored usernames and passwords.

Currently, the most popular authentication mechanism is the one using OAuth. This requires the username and the password to be sent only once to an authentication service. The authentication service returns a token which can be used as an authentication substitute in subsequent calls.

User Session

User Session represents the information about a client (or user) that is using your application (or services). The session works through HTTP cookies - same Cookies that the websites you visit store on your computer to remember you. You will need to pick a name for the Cookie that will serve this purpose and publish it to the users of your Web-APIs. The clients need to receive this Cookie from the Web-API responses and return with every request to maintain the session. The Web browsers already do that - they remember and return all cookies; your clients need to replicate the same behavior.

An alternative to Cookies based Session Id, is the JWT. JWT is a more modern approach, and it uses OAuth2. Most customer facing applications, including ZOAPIIO Web and mobile apps, use this approach.

While the Cookie transmission is handled by the browser, the JWT needs to be explicitly added to the HTTP request by the application. Everything else remains the same. You can configure the ZOAPIIO Session to use either of the two mechanisms.

Relational Databases

If you are developing business modules or Web-APIs, chances are you will need to store and retrieve tabular data. Relational databases (RDBMS) are a popular way to store application data in an efficient way. To build database access into your Web-APIs, you do not need to know any technical details about database programming. However, acquiring a high-level overview of SQL is advised. If you have not used databases or SQL before, you should be able to find introductory tutorials on the Internet.

Database table access is done using the Database statement.

1. You create the table in the database first. The table creation is automatically handled if you are using the Application Wizard. If you are not using wizard, you will use the DB Assistant to create your table.
2. Declare the DATABASE-TABLE node in the schema and import its definition from the server.
3. To Fetch a record using the key, simply assign the value of the Key and do Database fetch. Process the data. E.g.

   /Employee/Id = 100
   Database fetch Employee
   /Response/Name = /Employee/Name
   ...
   			

   It is advisable to check /_STATUS for failure.
4. To open a cursor and process all records, use either

   /Employee/_WHERE = "Name = 'John'"
   Database open Employee
   ForEach /Employee
   ...
   End ForEach
   Database close Employee
   			

   or

   ForEach /Employee Where Name == "John"
   ...
   End ForEach
   			

For most common situations of database access, you should never need to use Database Queries. This is an advanced subject and requires the knowledge of SQL syntax - if you do need to use Queries and do not know SQL, you should take the help of a programmer in your team. SQL is quite simple in syntax; you should also be able to write simple SQL statements with some help from Google. You should use Database Queries, when-

1. You need to use group functions like Sum(), Count(), etc. with or without the Group By SQL clause.
2. You need to fetch rows from the database by joining two or more tables.
3. You need to fetch or update the database using SQL statements that have substitution parameters.
4. Other advanced database access needs like dynamic SQL.

SQL query processing engine allows a query to be executed which has placeholders in it for values to be provided separately. The parameters are positional parameters meaning they are referenced by position and not by name. The Query string will have &1, &2 etc. as positional placeholders and will be substituted with values from the parameter list.

lets you have access to this feature of SQL engine, and takes it a step further. You can have the placeholders in your SQL query which will be passed to the SQL engine. In addition, it allows you to flag some parameters for "Inline Replacement". This means that these parameters are substituted into the query string by runtime, even before passing it to the SQL processing engine. This method of substitution allows you to even replace keywords within the query - something that SQL parameter substitution does not allow.

If your application requires the use of dynamic SQL, you can handle it by-

1. Defining a Database Query with one "inline Substitution" parameter containing the entire Query, or.
2. Assigning a value to _SQL attribute of the DATABASE-QUERY node with the dynamic SQL. If you have defined any Query Parameters, then the SQL you assign here must have the same number/type of Parameter placeholders - represented by a ? (SQL syntax).

Mongo Databases

MongoDB from Google is a no-SQL database. It has been optimized for specific types of use-cases that deal with JSON documents. There are other no-SQL databases in technology scape, but MongoDB has gained a large following and is by far the most popular.

If your application requires the use of MongoDB, ZOAPIIO has an abstraction for it.

For details, refer to the Reference Guide.

Background Jobs

Background Jobs are needed to perform daemon functionality. allows you to create any number of background jobs in your application.

1. Create an ENTRY-POINT service that runs in an infinite loop. I.e. it runs perpetually in a loop performing a certain task and then waiting for a while. The wait is essential otherwise the service can overload your application and affect performance.
2. Launch the service from the Application initialization section of the DECLARATIONS area in your project. Add the following line inside the onInitialize() function.

public void onInitialize(Node node) {
	spawn("/wc/... (Service URL)", "<REQUEST></REQUEST> (The Request XML for the service)");
}
   	

Scraping Web data sources

supports web scraping using a Selenium driver interface. Your default instance (free tier) does not have a scraping pool configured. You can upgrade to a paid instance and request for a scraping pool to be configured according to your needs. See the Reference Guide at the end of this document for full description of scraping commands.

1. You script the scraping session starting with an 'open' command and ending with the 'close' command.
2. You script the scraping session by interacting with the page and controlling it in the script.
3. The elements on the page are referenced using Data Path syntax.
4. To get contents from the page or to type values into input fields, you use the 'Compute' statement.
5. To otherwise interact with the page like clicking on elements, you use the scraper commands.
6. To Execute a JavaScript inside the page, put the JavaScript in a string and then assign it to the {Scraper}/_EXECUTEJS pseudo node.

Edge node architecture

The default configuration of the Selenium session is to invoke a real browser program (Firefox, or Chrome etc.) that runs in a virtual X environment. This means that the browser is not visible as a window. Since the scraper script is executing on the server, which does not have a console, this becomes a necessity. Please note that the 'screenshot' scraper command works for the virtual environment as well. So, it would produce a real image of the contents of the browser window.

supports another architecture for scraper configuration which allows the scraping agents to be opened on computers other than the server running the scraping script. There is a standalone 'dumb' edge scraping agent, which runs the browser under the control of the server.

1. Any number of edge nodes can be provisioned in the scraper pool.
2. The edge nodes can be on desktop or laptop computers running on home or office networks.
3. The browsers running on edge produce visible windows and can even be manually interacted while the server is controlling it.
4. The requirement is that the edge node and the server must be able to connect with each other using an IP address.
5. In home or NATted office networks, this is not possible. To deal with such situations a VPN or a port forwarding mechanism can be set up that will enable this. Please consult a networking specialist for details.

Application Properties

Application Properties are system wide fixed settings (or constants), which are used at multiple places in your application. Your project simply references these settings by name. These settings are kept at a common place (file, a database table or even on the Internet). If these values change, only the common store needs to be updated without impacting your application.

allows you to configure and use application properties using a database table. Files cannot be used because you do not have direct access to your container, but Web-IDE has the DB assistant tool to let you access your databases. Your instance comes pre-configured with a database table for this purpose and is mapped to a property set, that is available for access in your programs. The table should be named "Z_Properties" and should be mapped to a property set "MainProps".

Using Java

The scripting is very high-level, powerful, and compact. It is designed to help ease the development of Web-APIs. However, it cannot replace a conventional programming language on the grounds of flexibility. An example is formatting values. A language like Java offers string processing tools that can let you reformat data in the way you desire. Should your project have a need for such processing, you can use Java Methods in your project.

When writing the Java code, you can access the Schema contents using built-in functions (methods), as described below. The Java functions also allow you to access other features in the system, which have not been abstracted through the business rules.

If the processing you want to perform using Java is simple and can be expressed in a few lines of Java code, you can use the "Java" business rule and write the code in-line embedded within your rules. For more complex processing use the METHOD node, described below.

Please note that the knowledge of Core Java and Java DOM API is required. If necessary, take help of an experienced Java programmer in your team.

Security related Restriction

There are certain restrictions on how you write the Java modules, for the reasons of security.

1. You cannot use the following global objects/classes/keywords of Java - System, management, Class, and package.
2. ZOAPIIO has a built-in method runCommand which executes shell commands and is reserved for internal use. It cannot be used in your programs.
3. You cannot use the getClass and forName methods of Java.
4. When using the 'new' keyword of Java you must provide the full Class name of the object being instantiated. You can only create objects from the following Java packages - java.lang, java.util, java.text, java.time, org.json and java.io (Some java.io Classes may not be allowed).
5. If you want to declare a local class in your program, the name must start with an underscore (_), and you can use the 'new' keyword to instantiate it.

Built-in Functions

The following functions (methods inherited from base implementation) can be directly called from your Java code.

jQuery Java Adaptation

aims to make data processing flexible, easy and compact. A very popular product - jQuery - also has the same goals with respect to processing data in JavaScript (front-end programming). If you are a jQuery programmer, you have another option to process the data in your Project schema.

provides an adaptation of jQuery core functions in Java, allowing you to query and update the data using jQuery like syntax. Let us start with an example-

final float accum[]=new float[1];
accum[0]=(float)0.0;
$(in).select("AirInfo > AdditionalDetails > PassengerInfo PaymentReceived")
	.each(new $Operator() {
		public void operate(int seqno, Node n) {
			accum[0]+=parseFloat(get(n));
		}
	});
	

OCR and PDF Parsing

server comes with Google's tesseract OCR engine included. The access to OCR features is provided through built-in Java Methods listed above. Tesseract uses an internal XML format to return recognized data from a page. ZOAPIIO uses the same format to work with the OCR API. Additionally, ZOAPIIO provides an API to recognize text from a text PDF file as well. For consistency, the same hypertext format is used for the PDF recognition API as well.

Introduction to HTEXT Format

The HTEXT format contains the details of the text recognized along with the location on the page and the font attributes. A sample is given below-

<div class='ocr_page' id='page_1' title='image ""; bbox 0 0 319 33; ppageno 0'>
   <div class='ocr_carea' id='block_1_1' title="bbox 0 0 319 33">
      <p class='ocr_par' dir='ltr' id='par_1_1' title="bbox 10 13 276 25">
         <span class='ocr_line' id='line_1_1' title="bbox 10 13 276 25; baseline 0 0">
            <span class='ocrx_word' id='word_1_1' title='bbox 10 14 41 25; x_wconf 75' lang='eng' dir='ltr'>
               <strong>the</strong>
            </span>
            <span class='ocrx_word' id='word_1_2' title='bbox 53 13 97 25; x_wconf 84' lang='eng' dir='ltr'>
               <strong>book</strong>
            </span>
            <span class='ocrx_word' id='word_1_3' title='bbox 111 13 129 25; x_wconf 79' lang='eng' dir='ltr'>
               <strong>is</strong>
            </span>
            <span class='ocrx_word' id='word_1_4' title='bbox 143 17 164 25; x_wconf 83' lang='eng' dir='ltr'>
               on
            </span>
            <span class='ocrx_word' id='word_1_5' title='bbox 178 14 209 25; x_wconf 75' lang='eng' dir='ltr'>
               <strong>the</strong>
            </span>
            <span class='ocrx_word' id='word_1_6' title='bbox 223 14 276 25; x_wconf 76' lang='eng' dir='ltr'>
               <strong>table</strong>
            </span> 
         </span>
      </p>
   </div>
</div>
	

Notes on the HTEXT format

1. The format looks like HTML.
2. The result is hierarchically broken down into page, para, lines and words.
3. The title attribute contains the bbox, representing the bounding box of the text location on the input image.
4. The w_xconf value represents the recognition confidence (0-99).
5. The dir='ltr' means the text direction is left to right.
6. The lang attribute is the input text language, 'eng' or English in the example above.

Guided Page Parsing

takes the text recognition from images and PDF documents a step further. Once the HTEXT representation of a page is obtained, an application will typically scan the page and extract relevant parts. This step requires looking at the topology of the page and then breaking the contents into extractions meaningful to the application.

Page Template

The page parsing is done using a page template. In this template you provide a guide to what you are trying to extract from the page. The template is a collection of template items, and each item has the following settings.

The Page template is a JSON representation of the list of template items. An example is shown below.

[
	{
		"FieldName": "VoucherCode",
		"LeftFrom": "33",
		"LeftTo": "100",
		"TopFrom": "0",
		"TopTo": "0",
		"Pattern": "[A-Z][A-Z0-9]{9}",
		"ColLabel": "",
		"RowLabel": ""
	},
	{
	}
	...
]
	

Page Parsing Result

The page parsing returns two structures, both as JSON formatted arrays - one for all words on the page along with their location on the page and the second with matched words as "Name-Value" pairs.

For both the results strings (JSON), you provide a template each. The template should describe each element of the JS array that you want returned. The template contains placeholders for the substitution values enclosed within two % characters. The following is the list of placeholders.

Result JSON 1

1. PageH: Page height,
2. PageW: Page width,
3. BboxX1: Bounding box coordinate X1,
4. BboxY1: Bounding box coordinate Y1,
5. BboxX2: Bounding box coordinate X2,
6. BboxY2: Bounding box coordinate Y2,
7. Text: The matched text.

Example Result Template 1

{
	"Text":"%Text%",
	"PageW":%PageW%,
	"PageH":%PageH%,
	"BboxX1":%BboxX1%,
	"BboxY1":%BboxY1%,
	"BboxX2":%BboxX2%,
	"BboxY2":%BboxY2%
}
	

Result JSON 2

1. Name: The name of the field as in the input template,
2. Value: The value of the text that was recognized.

Example Result Template 2

{
	"FieldName":"%Name%",
	"FieldValue":"%Value%"
}
	

ZOAPIIO Application Wizard

With the Application Wizard, you can build your fully functional business application in a matter of hours. Refer to the Wizard User Guide for details.

ZOAPIIO Web/Mobile Apps

Building Web/Mobile apps is easy and convenient with . The development is much faster and can be done will minimal programmer skill. The following types of apps are supported-

1. Classical Web application - ZOAPIIO apps uses HTML5, jQUery and Bulma CSS framework.
2. PWA - It is based on the classical Web Application with additional feature that it can be installed on a mobile device like an app.
3. Mobile App - ZOAPIIO mobile apps are built using the cross-platform tool - Flutter, which means the resultant app can run on all mobile platforms including Android and iOS.

Refer to the Front-end Development Guide for details.

Reference Guide

Summary

ATTRIBUTE

"ATTRIBUTE"s apply to a TAG and represents an XML attribute of the TAG. It is useful only when dealing with XML messages - they have no equivalent in JSON, so if your messages are in JSON format, you should avoid these.

ATTRIBUTE-GROUP

"ATTRIBUTE-GROUP"s apply to a TAG and is a mechanism to have reusable ATTRIBUTE groups. You can create an ATTRIBUTE-GROUP and put attributes under it or simply refer to a TAG under TYPES whose attributes are being referred.

COOKIES

"COOKIES" is a TAG for definition of HTTP cookies. TAGs defined under this node are treated as cookies. You can access the value of a cooking through the cookie TAG for read as well as update.

DATABASE-QUERY

"DATABASE-QUERY"s offers a means of executing SQL queries on the Database. If the standard read, update operations available on the Database tables do not meet your requirements, you can write direct SQL queries and execute them. See Using Queries.

DATABASE-TABLE

"DATABASE-TABLE"s offers a means of accessing your database tables for read and update.

DECLARATIONS

, internally, wraps your project in a Java class and compiles it before deploying it in your application container (Instance). "DECLARATIONS" Tag contains the class declaration, and in most cases, you should leave it alone. The reason it is exposed to the Web-API builder is that in advanced situations, you may need more control on how the class is compiled. If you are using Java Methods in your project -

1. You may want to import Java libraries in your class. Using import in Java is optional and your Java code can use fully qualified class names, so more importantly-
2. You may want to declare common Java functions that you can access across the project. You will add those functions in the DECLARATIONS section.
3. Important note: You should not declare any instance variables in the class. Your container creates only one object for the Web-API class and all service instances run inside the same object. Any instance variables will be shared by all the services and will create conflicts in their operation.
4. Your services will require local storage - you should create Tags under /VARIABLES and use those for local storage.

ENTRY-POINT

"ENTRY-POINT" node in your schema declares a REST Web-API that your project is providing. To declare Web-APIs that your project is consuming, see WEB-SERVICE. The entry point is attached to a URL. The public URL of the Web-API is constructed by prefixing your dedicated container URL to the URL you specify here. (The URL of your container is- "https://my.zoapiio.com/{your instance code}". You can get your instance code from the account panel, where you signed up. It is also visible in the URL of the Web-IDE page.)

HTTP protocol allows data (parameters) to be passed with a request as a query string in the URL or as a part of the POST body. When the Web-API starts executing, will extract the input data coming with the request and present it to your program in the Data tree.

1. The input parameters that your API is expecting should be declared in your schema. Any input coming in that is not declared is thrown away.
2. Conventional query string parameters are received as single field values.
3. Two special query parameters are recognized "_XML" and "_JSON". Any data coming in these query parameters is treated as complex structure (In XML and JSON format respectively) and the contents are unfolded.
4. The REST API's typically do not use query parameters and send the input data in XML or JSON format in the POST body. If your input in coming as POST body, you must declare it in ENTRY-POINT properties, so it can be handled.
5. Please note that any client sending complex structures as POST data should also send the appropriate HTTP header value for "Content-Type" - such as "application/xml" or "application/json".

In REST API's it is a common practice to pass additional parameters within the URL path itself. E.g. to get the details of an Employee with a known id, the conventional URL would look something like https://.../wc/getEmployee?Id=M100, but using Path parameters, the same URL becomes https://..../wc/getEmployee/M100.

To handle this in , you will declare the ENTRY-POINT with URL /wc/getEmployee. will map all requests which have '/wc/getEmployee/' as prefix to the same entry point. The path components following the base URL can be accessed in your program using Data path /REQUEST@_PATH1, /REQUEST@_PATH2 etc.

ENTRY-POINT-EMAIL

"ENTRY-POINT-EMAIL" node in your schema declares a processor for the EMAIL Message. The entry point does not have a URL because it is never explicitly called. It is attached to an Email account (configured on the server) and is automatically invoked when an Email arrives on that account.

The Email message is passed to the handler as an object of class javax.mail.internet.MimeMessage, and you will be required to write a Java method in your project to extract the parts of the message. Inside the method, you should use MimeMessage mm=(MimeMessage)getEmailMessage("/"); to gain access to the message. From the entry point code, you should call your Java Method, extract required information and store it in your schema tree. The remaining part of the processing, such as updating the database, can continue from the entry point code.

ENTRY-POINT-GRAPHQL

"ENTRY-POINT-GRAPHQL" node in your schema declares a processor for the GraphQL Query. GraphQL Queries, which run on the same URL should be declared under this node (See GRAPHQL-QUERY below). Both Query and Mutation types are supported.

ENTRY-POINT-JMS

"ENTRY-POINT-JMS" node in your schema declares a processor for the JMS Message Queue (MQ). Like the REST Entry point is attached to a URL, the JMS entry point is attached to a Queue. Your instance comes with two pre-configured JMS endpoints (one topic and one queue).

ENTRY-POINT-SOAP

"ENTRY-POINT-SOAP" node in your schema declares a SOAP Web-API that your project is providing. To declare Web-APIs that your project is consuming, see WEB-SERVICE. The entry point is attached to an URL. The public URL of the Web-API is constructed by prefixing your dedicated container URL to the URL you specify here. (The URL of your container is- "https://my.zoapiio.com/{your instance code}". You can get your instance code from the account panel, where you signed up. It is also visible in the URL of the Web-IDE page.)

SOAP services allow for multiple SOAP actions within the same service. So the same URL can service multiple related functions. The actual service is declared within the SOAP-ACTION node.

ENTRY-POINT-WEBSOCKET

"ENTRY-POINT-WEBSOCKET" node in your schema represents a processor for the Web-Socket. The entry point is attached to a URL.

GRAPHQL-QUERY

"GRAPHQL-QUERY" node in your schema represents a Query under the ENTRY-POINT-GRAPHQL. Multiple Queries can be serviced on the same URL. You can add any number of Query or Mutation type Queries under the entry point.

HTTP-HEADER

"HTTP-HEADER" node represents an HTTP header with a Web Service that you are consuming. If you need to send a specific HTTP header to that service, you should declare it here and then assign it a value before calling the web service.

METHOD

"METHOD" node represents a callable routine in Java programming language. You can write any processing you need to do in Java as METHODs. For details, see Java method. If you have declared common Java functions under DECLARATIONS section, they can be directly called from your Java METHODs. The METHOD prototype declaration is fixed - it receives two Node objects (passed at the time of calling) - in and out. Despite the suggestion the variable names make, both behave identically, and you can read as well as update both.

Also important to note that the Node objects should not be manipulated using Java DOM methods, the inherited functions, get() and set() should be used instead.

MQ-DESTINATION

"MQ-DESTINATION" node represents a JMS Message Queue or Topic to which your project needs to send messages.

PROPERTY-SET

"PROPERTY-SET" node represents a way of accessing your Application Properties. Add a PROPERTY-SET Tag in your Schema to gain access to the property set.

QUERY-PARAMETER

"QUERY-PARAMETER" Tag is used in DATABASE-QUERY to pass values to parameters used in the Query. Parameters should be declared in the same order as they appear in the query string. See Using Queries.

REQUEST

"REQUEST" is a TAG that represents (abstracts) the HTTP Request associated with REST Web-APIs.

ROUTINE

Good programming practice requires that you imagine your overall business functionality as smaller independent sub-processes, which can be implemented without too much complexity - the programmer's "Divide and Rule" principle. While it helps contain complexity, its main purpose is to allow the sub-routines to be called multiple times using parameters. For example, the functionality to lookup an Employee's salary from its Id would be implemented as a routine, which receives Employee Id as parameter. Then this sub-routine can be used from multiple places from your project, wherever this lookup is required.

"ROUTINE" TAG lets you do this, and it declares a callable sub-routine. Each ROUTINE has two parameters (passed at the time of calling) both of which are nodes from the Data tree. These parameters are called Input, and Output - although there is no restriction on updating or reading any of these inside the routine. Inside the routine two special Data paths - /_IN, and /_OUT are used to access the nodes respectively.

SESSION

Sessions are used by Application programs to remember the identity of the users. In a web-based application, this is done through HTTP cookies. takes ownership of managing the session for your application. The "SESSION" Tag represents the User session - you can freely add or change information to the Data tree under the SESSION and will preserve its contents across calls.

Typically, you will populate the user details in the session when the user logs on and then every Web-API in the same session (same Cookie) can access that information.

SOAP-ACTION

Your SOAP entry points will have SOAP actions. SOAP-ACTION is an action that can be invoked on the same URL but with a SOAP action option passed to it. runtime matches the Root name in the incoming SOAP (XML) message and selects the right SOAP action to execute.

SOAP-HEADER

SOAP headers are like HTTP headers, except they apply to only SOAP messages and carry specific SOAP control information. The "SOAP-HEADER" Tag is used to pass SOAP headers to web-services being consumed in your program.

TAG

"TAG" Tags form the bulk of your schema because they represent the data elements in your Data tree. The attributes of the TAG change depending upon where it is declared. E.g., the properties of TAG appearing in the DB Table definition would be different from the ones appearing in the rest of the Data tree.

TRANSFORMATIONS (Business Flows)

A Node in your schema, where you put all your processing related Tags.

TYPES

"TYPES" is the Node in your schema, where you put all your reusable structure definitions. The data structures declared here do not become a part of the schema, but they are only declarations. TAGs must be separately declared in the schema and refer to the data types here. See Data Types.

VARIABLES

Programs require temporary storage - In , "VARIABLES" Tag is where you will declare your global storage for your project. Please note that the contents of the entire Data tree, including VARIABLES, is accessible across your project. Each service invocation, however, has its own separate Data tree.

WEB-SERVICE

"WEB-SERVICE" Tag declares a Web-API (or Web service) that your project will consume. The service can be a service within your project or an external service on the Web.

WEB-SCRAPER

"WEB-SCRAPER" Tag declares a Website that your project will scrape.

XML-STUB

"XML-STUB" Tag declares an inline XML document, which can be used to initialize parts of outgoing messages without needing to initialize it element by element.

XSLT

"XSLT" Tag declares an inline XSLT script (program), which can be used to apply transformations within the Data tree. This is for advanced use and requires the knowledge of XSLT programming.

Statements

Statements in your program follow a common structure. Each statement has a name and up to four parameters - not all parameters are mandatory. The parameters appear in a fixed sequence. Your Web-IDE Logic Builder, manages the parameters for you -

1. Where possible a drop-down is presented for selection
2. Data paths can be dragged from the Schema window into a position that expects a Data path.
3. Free input text like Data paths and expressions are validated, where possible.
4. The Logic builder will ensure the integrity of the program structure allowing only syntactically valid connections.
5. Some statements appear as blocks in the Logic builder because they represent compound statements - like conditions and iterations.

// (Comment)

Comments are used to improve the readability of your program. You should insert comments to describe what you are doing - it is not always obvious from reading the program alone.

Abort

The "Abort" statement causes the presently executing service to return immediately. It does not imply that the service has failed - it is to be viewed as a return from the service. The response message is rendered normally - the caller does not see any error. An optional condition can be specified, if the "Abort" action is conditional.

Break

The "Break" statement is same as the break statement in most programming languages. It can be used only inside an iteration block. It causes the iteration to be exited immediately and the control resumes at the statement following the iteration block. If there are multiple nested iteration blocks, this will exit from the innermost block only. An optional condition can be specified, if the "Break" action is conditional.

Compute

The "Compute" statement evaluates an expression. It is the most used statement, and its most common use is to copy values around the Data tree (using the assignment operator).

There are other more compact ways of copying values in and if you find yourself using too much of "Compute" for copying values, see if "NodeInit" or "NodeCopy" can work for you.

Call

The "Call" statement is used to call a Java method. Up to two parameters - both nodes - can be passed to the call. By nomenclature, they are referred to as in and out, although there is no restriction on their use and treatment.

Continue

The "Continue" statement is same as the continue statement in most programming languages. It can be used only inside an iteration block. It causes the execution to skip the remainder of processing in the current block and proceed with the next iteration. If there are multiple nested iteration blocks, this will apply to the innermost block only. An optional condition can be specified, if the "Continue" action is conditional.

Database

The "Database" statement is used to invoke various operations on a Database Table.

All DB operations communicate the success status through the Pseudo element /_STATUS under the table name. If you want to check if the operation succeeded, a non-zero value indicates a failure. E.g., /Employee/_STATUS will contain the success status of operations on the table Employee.

Declare

Declare is used to define a local variable. The declaration feature is only available inside a ROUTINE. Local variables are accessed using the path /_LOCALS/{Name}. It has a scope local to the current execution frame in the execution stack.

supports recursion - a ROUTINE can call itself with a new set of parameters. Each execution frame gets its own reference to /_IN, /_OUT and /_LOCALS nodes. When the ROUTINE returns the previous frame is restored.

DbQuery

The "DbQuery" statement is used to invoke various operations on a Database Query (DATABASE-QUERY).

All Query operations communicate the success status through the Pseudo element /_STATUS under the query name. If you want to check if the operation succeeded, a non-zero value indicates a failure. E.g., /EmployeeQ/_STATUS will contain the success status of operations on the query EmployeeQ.

Execute

The "Execute" statement is used to call a Routine.

Execute2

The "Execute2" statement is used to call a REST Entry point (ENTRY-POINT) logic as if it was a routine. The Entry point must be declared within the same project. Note that the REST service is not called using HTTP - to call a service use the WsCall statement.

ExportXml

The "ExportXml" statement is used to serialize the contents of the Data tree under a node into an XML string. While the @_XML pesudo attribute allows you to do the same, this Statement lets you specify an XML Namespace for serialization.

ForEach

The "ForEach" statement iterates over all instances of an element or all rows in a result set. (Database or MongoDB collection) See Iterating over Nodes/Rows for details.

if

The "if" statement is same as the if statement in most programming languages. It is used for conditional execution - it takes a condition and a program block, which is executed once if the condition is true. The "if" statement can have additional "else if" statements attached to it - each with its own condition and a program block. In the sequence the block corresponding to the first condition that evaluates to true is executed. Typically, the last "else if" is without a condition, which means that the last block will be executed if none of the conditions were true.

In Logic Builder, you can add additional "else if" blocks using the special command button provided on the "if" block.

Java

The "Java" command is used to write Java code in-line. If you have a small Java code to execute, it is more convenient to write it in-line without having to create a METHOD. This simplifies your code and does not interrupt the flow of logic.

JmsSend

The "JmsSend" command is used to send a message to a JMS Destination (MQ). Your instance comes pre-configured with two JMS Destinations (one queue, and one topic) - you must first declare the destination you want in your schema.

Mongo

The "Mongo" command is used to access the MongobDB collection.

All MongoDB operations communicate the success status through the Pseudo element /_STATUS under the Collection name. If you want to check if the operation succeeded, a non-zero value indicates a failure.

After a document read operation (fetch, open or next) the document can be accessed using the pseudo node /_document or its inside contents can also be accessed as if the JSON document hierarchy was present under the Collection node.

E.g., referring {Collection}/Name would cause the document to be extracted under the collection node and then 'Name' JS property would be accessed.

Node

The "Node" statement is used to invoke various operations on a Data tree node.

Please note that there is no operation for exporting xml - this functionality is available in ExportXml command.

NodeCopy

The "NodeCopy" statement is used to copy a node and its entire sub-tree to another node. Please note that the structure declarations of the source and target should match. It copies the elements by name, and if a name is not present in the target declaration, the element is skipped. You can use NodeCopy where some of the names are common to source and target declaration - it will copy the matching ones.

NodeInit

The "NodeInit" statement is used to initialize a node in the Data tree from a static XML. Note that you can achieve the same result by assigning a string value to the @_XML pseudo attribute. However, this statement is useful when dealing with large static XMLs. The XML text should be declared in your Schema as XML-STUB.

Return

The "Return" statement is same as the return statement in most programming languages. It causes the currently executing routine to return immediately and resume processing from the line following the "Execute" statement, from where it was called. If not used inside a Routine body, it acts like Abort and the causes the service to end. An optional condition can be specified, if the "Return" action is conditional.

The Routines in , like in most programming languages, have a return value. When used in a Routine, an optional return value can be specified.

Sleep

The Sleep command is used to create a delay - the execution is suspended for the given time and thereafter resumes normally.

Parameter	Seq	Description
Time (ms)	1	The number of milli-seconds for which to sleep. An integer number should be provided. Alternatively, an '@' followed by a data path can be provided to indicate that the value stored in the mentioned node be used for the sleep time value.
The Sleep statement.

WebScrape

The WebScrape command is used to initiate and interact with a Web Scraping Session. ZOAPIIO uses a real browser under the control of Selenium automation toolkit for scraping.

WebSocketGet

The WebSocketGet command is applicable only inside an ENTRY-POINT-WEBSOCKET. Web Socket is a persistent connection with two way communication. This means that once the service is invoked, the client can also send data to the server.

This is a non-blocking call, if data is available it is returned otherwise it does not block. Your service, as it is streaming data to the client, can periodically read the data coming from the clients and take action like changing its behavior or streaming content.

WebSocketSend

The WebSocketGet command is applicable only inside an ENTRY-POINT-WEBSOCKET. Web Socket is generally used to stream data to the client. The WebSocketSend is used to push data to the client. This should be executed in a loop to continuously send data.

While

The "While" statement in is same as the while statement present in most programming languages. It takes as input, a condition, and a program block - the block is repeatedly executed until the condition becomes false. The condition is checked before entering the block.

With

The "With" command works like ForEach, except that only one Node is processed.

WsCall

The "WsCall" statement calls a Web service (Web-API). The service to be called should be declared as WEB-SERVICE in the project schema. At the time of calling, you must provide a Data path representing the input to the service and a Data path to receive the output from the service.

The Web service is called asynchronously - implying that only the request is dispatched without waiting for the response to arrive. The execution continues with the next statement. The reason for asynchronous call is that the Web-service can take a significant amount of time and your program may want to perform some other tasks in the meantime. Another use for this that your program can issue multiple Web-Service calls simultaneously so they all work in parallel.

With the Web service, you specify a program block which is executed when the service completes, and the data is received. Typically, you can leave this block empty. You should use the "WsControl" command to control (wait for or stop) a previously started Web Service.

WsControl

The "WsControl" statement controls a Web Service started previously in the program using the WsCall statement.

WsSyncCall

The "WsSyncCall" statement is equivalent to a 'WsCall' with an empty program block, followed by a 'WsControl wait'. It results in synchronous calling of the service.

Xslt

XSLT is an XML based scripting language that allows XML documents to be transformed. It operates by reading an input XML, applying the transformation, and then writing to an output XML. This used to be a popular mechanism to deal with XML processing, although it is losing popularity now. If you have an XSL script or have a transformation that can be achieved easily using XSL, you may want to use it. It is an advanced subject, and unless you have XSL programming knowledge, you are better off without it.

allows you to incorporate XSLT scripts in your programs, through the "Xslt" statement. You need the XSLT script, separately developed, and tested, and then declared as "XSLT" in your project schema.