IIT

On one page we talk about building and deploying using IIT, ANT, Maven & Docker

Introduction

An iWay Application consists of both an application (IIA) and deployment template (ITA) file. The IIA is the artifact created when building an IIT Application Project. An ITA is created when building a deployment template created within an IIT Application Project. More information about iWay Application Projects can be found here.  In this document we will explore up to four ways on how to deploy an iWay Application. Lets get started. 

iWay API Builder Overview

The iWay API Builder is a powerful user interface for developing REST based API's using a RAML or OpenAPI based API definition. The API builder can provide scaffolding to easily describe any endpoint defined within an API definition. This makes implementing API's quite an easy task. Lets test drive the API builder to see how just how easy it is to use.
 

The Test Drive

To get started we are going to need an Application Project. To learn more about Application Projects click here. We are going to assume we have an Application  Project  named "myproject" available. Select the API folder and right mouse click to launch the API builders creation dialog.

Creating a REST API

API Creation

 


Clicking on the New API menu item launches the dialog as shown below. We will name our api ,"myAPI" and load an API definition file. By clicking on the button to the right as shown below we are given a choice to either load from a workspace, file system or from a URI.
 

API Creation2


We will keeps things simple and load a definition from the file system.
 

raml load


Click "Finish" which will begin the process of creating the API scaffolding.


API Scaffolding

Once completed, IIT should look similar as shown below. Notice a new entry has been added to the API's folder with the name of the API we specified earlier. Also notice that the API definition file, "api.raml" has been imported to the application project. We can now see the API endpoints as defined in "api.raml".

importedapiraml


At this point we are going to look at an endpoint. Click on the "/companies" GET endpoint as shown below: 
 

endpoint selected


We can see that the API defines several query parameters for the GET method on the "/companies/ "endpoint.  These parameters make up the query string which can be used when making a call using HTTP.


An API Endpoint

To look at the endpoints implementation we click on the "Edit" link as shown above. Clicking on this link yields:

apifloweditor


As we can see above.. the endpoints implementation drops us into the iWay Flow Editor where we can orchestrate business logic accordingly.
 

apidefaultpayload


We can also observe that there is a Payload object defined in the endpoint implementation. This was added within the scaffolding process, when it was detected that there was an example defined in the API definition file for an HTTP response of 200 which is considered to be the default response.

 

URL & Query Parameters

Both URL and Query parameters can be retrieved using the iWay Functional Language, often referred to as IFL. Specifically we will be using the _sreg() function which takes in the name of a variable and returns its value during runtime execution. IFL expressions can be used to satisfy almost any value found within a deployment template, flow and/or channel definition.

In the "/companies/" endpoint there are six query parameters defined. Their values can be retrieved by using the following IFL expression:

_sreg(queryparm.[parameter name]) 
 

In the "/companies/{companyid}" end point the value of the companyid can be retrieved using the following IFL expression:

_sreg(url_parameter.companyid)

 

Refreshing the API

Often your API may change shape and or form. The Refresh button will re-parse the API definition document located under Definition folder of your API file and update the API file as needed. It will add all the endpoints, and methods, as well as query parameters and headers that have been added to the definition since the API was first loaded or last refreshed.

 

refresh api


Testing the Endpoint

A REST endpoint can easily tested by issuing a "Test Run" as shown below:

test run


This will launch an Eclipse run configuration specifically designed to test iWay API's. For more information about testing flows see iWay Flow Testing section of this documentation. For API's however this user interface has been enhanced to include both query and url parameters as shown below:
 

testrunapiparms

Users can set these parameters and have them available at run-time. Once again refer to iWay Flow Testing for further techniques on debugging flows.

 

Advanced Configuration

The REST API is implemented using a non blocking HTTP listener. That listener has several configuration options such as the listening port, pooling options, denial of service, security, authentication and a whole lot more. Click on the Settings tab as shown below of the API to explore the rich set of options.  
 

advancedapi


Deploying the API

There are several options available for deploying an API. API's have no special needs as far as it comes to deploying an iWay Application. Please refer to Deploying Application Projects for guidance on deploying an application.

 

Testing a Deployed API

Once deployed an API can be tested using any tool which can issue a HTTP request. Programs such as Fiddler or Postman are great tools for testing API's. In iWay 8.x, iWay's Explorer was enhanced to explore iWay runtimes with API components. See iWay Explorer for further details.

 

iWay Configurations Editor Overview

Integration often comes with a daunting task of managing configuration. The iWay Configurations Editor was created to promote reusability and reduce efforts in managing countless configuration properties throughout an application. So.. how do we do this? Simply put we wrap a set of commonly used properties into to what iWay calls an iWay Generic. Each created generic can then be referenced by one or more components. Changing a property in a generic means that all components who reference it will inherit that change after compilation occurs. Lets see how this works in action. 


The Test Drive

To get started we are going to need an Application Project. To learn more about Application Projects click here. We are going to assume we have an Application  Project  named "myproject" available. Open the Configurations folder and double click on the default "iway" configuration. This will launch the Configurations Editor as shown below.

Configuration Overview

The list of iWay Generics are grouped based on the iWay Flow Editor palette.

Opening the Connectors folder yields the following:

openconfigconnectors


Creating a Generic

Lets create our first generic. We are going to create a Blockchain generic.

Select Blockchain and right mouse click as shown below:

newblockchaingerneric

Select the "Add Blockchain Generic" menu item.

Since the Blockchain connector supports multiple types of generics a dialog box appears prompting for its type.

newblockchaingenericchoice


Select the Ethereum Configuration and click "OK". A Blockchain Ethereum generic is created as shown below.
 

dddd

Notice that there is a red box next to the newly created generic along with two errors reported in the problems view. If we review the errors we can observe that there are two missing required fields found within the Wallet grouping. Adding values for these fields and saving the configuration will make these errors disappear.


Generic Usage

Generics are used from within the iWay Flow Editor. Lets create a flow which utilizes the Blockchain generic we just created. Create a new flow and drag & drop the Blockchain connector from the palette to the canvas. Select the "Ethereum - call function" action from the Action drop down as shown below.

blockchainflow

You will notice that a "Configuration" selection is required for this action. Pulling the drop down next to the "Configuration" label reveals the generic we previously created. Selecting this generic will satisfy the connectors configuration requirement. 

blockchain select action

If it is preferred to create a new generic, users can click on the "+" button to the right of the drop down. That will launch a dialog as shown below to create a new generic.

newgenericfromflow


Clicking on "Finish" will create the new generic. When we inspect the drop down once again we see that "blockchain.2" has been added to the list of available generics.


2 generics


If we would go back to the configurations editor we can see that "blockchain.2" has been added under the Blockchain Connector.
 

2 blockchain generics

 

iWay Flow Designer Overview

The iWay Flow Designer is a tool for conveniently designing orchestrations, visual representations of your business and application processes which run within the iWay highly scalable runtime. Many of the most complex integration patterns can be easily solved using a wide variety of components including iWay Adapters and iWay Connectors

Application Project Overview

When a user starts iWay Integration Tools (IIT) they are actually launching an Eclipse IDE, pre-loaded with a set of iWay Eclipse based plugins. iWay Integration Tools (IIT) is a set of tools for the Eclipse Platform that enables users to develop highly scalable integration solutions using a no-code or low-code development platform.

To get started, a user creates whats known in iWay 8.0 as an Application Project.

Process Flow Editor

Within the Application Explorer view, right mouse click and select "Application Project" as shown below.
 

Application Project


A wizard will appear which prompts for a project name. Enter "myproject" as shown below. Projects to be built and managed using Maven should select the radio box below. For now.. just leave it unchecked. 
 

Application Project Wizard


Once completed, click "Finish".  Congratulations !!  you now have created your first application project.
 

Application Project Finished

 

Application Project Anatomy

Looking at our project we can see it is made up of several folders and a package looking item named "bundle". The bundle is the heart of our application project. The name itself can be renamed but its meaning remains the same. The contents of the bundle is self managed by the application project. Its contents can be viewed and changed through the application editor. To open the application editor, double click on the bundle item within the application project. The editor should display as shown below.
 

Application Editor


 

Application Editor (the Bundle)

As you work with the application project... the contents of the bundle change accordingly. Most likely, items listed in the "Components" section will change when project artifacts, such as api's, flows and channels are either added or removed from the project. By default any artifact added to the project is added to the bundle. Thus the bundle represents all artifacts making up an application. The application editor is organized as follows:

 

 

The components  tab lets users see what is contained within the bundle. As mentioned above any artifact added to the project automatically gets added to the bundle. However, using the components tab users can control what goes in and out of the bundle.
 

Components

 

When creating XML based SOAP RESTful services using the iWay Explorer (Adapters) those services need to be injected into the runtime. This tab manages which SOAP based REST services will be available to call in the run-time.
 

Process Business Services

 

 

Often applications will be required to add one or more run-time dependencies on the classpath. Any file listed in this tab will be available on the classpath  during run-time execution.


library

 

The bundle contains a resources section where applications can store any file based artifact. Often applications require sample files, configuration or even images. By default the bundle includes the "resources" folder of the application project. Any file or directory added to this folder will be included in the bundle. Users have full control of whats included in the bundle by adding or removing artifacts as shown below.
 

Resources

 

Application Bindings allow developers the ability to inject variables into the run-time. It is assumed those variables will be used either by a flow or channel in a run-time.
 

Bindings

 

Application Project (the Layout)

The Application project is organized into several folders. A description of each folders use can be found below.

 

 

The API folder is the default folder for storing REST based API's. These API's are created using the iWay API builder.

 

The Channels folder is the default folder for storing event based channels. Channels are created using the iWay Channel Editor.

 

The Configurations folder is the default folder for managing configurations which store iWay Generics bindings. Users can create more than one configurations using the iWay Configurations Editor. An application project can have only one active configuration file. Users can select a configuration within the properties of the application project.

 

The Flows folder is the default folder for storing Flows. Flows are orchestrated using  the iWay Flow Editor, a drag drop interface for creating simple to complex point to point integrating solutions.

 

The Resource folder is the default folder for storing integration dependent artifacts. By default any file based artifact will be included within the application bundle. These artifacts will be found within the resources directory of the deployed run-time.

 

The Templates folder is the default folder for storing iWay deployment templates. Deployment templates allow users to create a component which inject configuration into runtime creation. Often these templates contain variables whose values are specific for either development, test and or production environments. Templates can be created using the iWay Template Builder.

 

The Transform folder is the default folder for storing iWay Transforms. Transformation is one of the most important foundations of an integration platform. The iWay Transformation Builder allows users to create simple to complex transformations using a graphical drag-drop interface. A wide variety of formats are supported such as JSON, XML, CSV and many more.