node cli.js call [//cloud/] queryObject.key1 value1 ...

node cli.js method taskrunner ...

`

Of all the methods, the chain is the most powerful, because it will allow you to any chain command (remote, local, etc.) while composing an arbitrary JSON queryObject

`

will show

{ success: 'true', testKey: 'testValue' }

`

of course you could use it for remote connections, i.e.

`

chain.queryObject.email xxx@yourizywaredomain.com

If your subscription enables access to Automation Projects studio, you can recreate these launch configurations in the UI and use the console for interactive exploration of your app functionality. Logging, monitoring and automation will also be supported. You must select the authentication strategy that best suits your use case (Open, hoAuth, SAML, etc.) even in the minimal service configuration option. For example:

port: { http: 17800 },

name: 'apigateway',

cli: 'oAuth2'

});

Passing Around Configuration Objects

let cmdline = { 'queryObject.param.key1' : 'val', test: 'json:["domain_manager"]' };

expandStringEncodedConfigValues(flatToJSON(cmdline));

{ success: true, data: { queryObject: { param: { key1: 'val' } }, test: ['domain_manager'] } }

the serialized syntax for expandStringEncodedConfigValues is consistent with data URIs which was defined in Request for Comments (RFC) 2397.

Plugins

Creating a plugin

Create a plugin by cloning the default subfolder under the plugin directory. You must also register the plugin in the config file.

To automatically test the plug-ins below, send a GET request and expect 200 status code.

The plug-ins may use the sessionObjects to share states and parsed information across the canHandle and handle stages. This will allow for writing high performance plug-ins.

apigateway

To test this plug-in, try:

`

`

default

`

`

Logging

There is an optional plug-in called logging. If you would like to remotely view the internal server logs (or view the entries from your your dashboard), you must enable it in the config:

`

name: 'logging',

ipwhitelist: ['1.2.3.4']

`

Due to security requirements, you must whitelist the IP address in order to access the logging feature.

Integrated Monitoring

• Granular management and verbose flag
• Filtering and querying by service, component, ...
• Aggregate metric calculations (Datarate, Sampling Frequency, ...)

While its possible to do ['chain.importProcessor', 'lib/monitoring', {}] inside each handler, it is recommended that to define the monitoring and logging strategy per service instance. Notice that the following component lifecycles:

• runpkg chainprocessor handler: per process, shared across services. The handler is a singleton which will share the lifetime of the application.
• chains available for method calls: notice that unless a chain is instantiated using newChain action, it will share its context across method calls so newChain can be utilized to contextualize the chains per service.

Using the strategy above, the service entrypoints, should be launched using a newChain, and the methodCallContextObjectsProvidedByChain and monitoringConfig need to be specified.

This will guarantee that the proper objects are instantiated and made available within the context of each method call during the service lifetime. The service instantiation cli uses this technique to setup the property logging per service end-point. See service code samples sections for examples.

Creating TCP/UDP services using the socket plug-in

`

plugins: [

name: 'socket',

items: [

]

}]

`

See the testing instructions above (under Testing) for howto test the service handler directly from the command line. The following verbose flags (and the default values) are available

`

writes: false,

connect: false,

error: true,

end: false,

detectStandardOK: false,

mock: false

Data Streaming and QOS

As the first step, setting the enableQOSMetrics flag to true for the streamproto1 object, will trigger a call to the qosWriter method everytime an audio packet is recieved. A QOSMetrics object will be generated and passed on to the the qosWriter method. The object will have the following properties:

• head: the header that was immediately preceding the audio packet
• qosTimestamp: unix timestamp

A typical implementation may be found in service/audiooutput:

(xcast) audio source => IzySocketWriterNode => metadata packet(getMetaDataStrFunction) + audio packet => (peer) => IzySocketReaderNode => audio sink

• peer: qosWriter method serialize the QOSMetrics, and write it back to the xcast
• xcast: the connection.client.QOSMetrics property will be populated by JSON.parsing the incoming data from the socket, and will be aggregated based on user.id into the QOSSocketWriterData storeLib variable.

Eventually, service/mixeradmin will push the QOSSocketWriterData back to the admin using socketWriterNode.getMetaDataStrFunction:

• xcast: socketWriterNode.getMetaDataStrFunction will pick up the QOSSocketWriterData alongside other xcast state objects and serialize them.
• peer: socketReaderNode.readMetadataPacket will set storeLib.set('readMetadataPacket') value which is then consumed by dashboard/userinput/qos/api to populate the QOS dashboard.

Handling Domain Based Requests

Platform Features

Uniform Local And Cloud Module Access

If you wish to access izy modules from the file system, you may customize the module path resolution rulesets defined in:

`

`

Please refer to the comments in the file to understand how to reference external modules.

Chain Processing

Your application units of functionality may be componentized either as a chain action (CA) or as a JSONIO end-point. The former would enforce execution of your application code in context while sharing the objects passed in and out while the latter would serialize the objects and would execute your application code in an isolated environment. The following considerations are important when making a decision about the component type:

• Security: JSONIO
• Performance: CA
• Clustering and Scalability: JSONIO
• Parallel Processing: JSONIO
• RCP: JSONIO

Note that when setting up a new chain special attention must be paid to chainAttachedModule and context object. context object gets accessed when doing $chain.get, $chain.set. In some settings (for example FE components) it may make sense to set both the context and chainAttachedModule to the same object (i.e. modui) while in some other contexts it does not make sense to do so.

CAs are implemented via a chain handler module (CHM) while JSONIO end-point are implemented as a JSONIO module (JM). JMs always proffer the doChain method with its context object set to the JM. On the other hand, CHMs do not have the standard doChain processor as JSONIO modules do because they can share context and be called from other chains. In order to process a chain inside a CHM, the $chain parameter proffers the following functions:

• newChainForModule: Allows running a new chain by running it in the context of a module.

['//service/endpoint', { data }]

• newChainForProcessor: Allows running a new chain by running it in the same context of the processor it is being called from.

$chain.newChainForProcessor(processorModule, next, {}, [

]);

To run chain actions, several options are available:

• By default, modtask.doChain is enabled inside the current context module: this is the most common usecase for UI components. The advantage of using this option is that any non-success outcome will be captured by the modtask which can be routed to the UI error div. This will allow implementation of error handling at component level (not application level) without writing extra code. It is available inside async functions as well, but its usage is discouraged. If your service monitoring config has warnAsyncDoChainUsage enabled you will recieve a warning for using it.
• If non-success outcome needs to be captured, the ['newChain', ... CA can be used with modtask.doChain.
• For new environments (i.e. nodeJS > 7.6) with async capabilities, you can try the following options:

* const run = require('izy-proxy/asyncio')(modtask|module).run: This option will only run a single CA (no chain arrays). The non-success outcome will be thrown (not captured by modtask). when using module, the relative paths for CA references will not work.

Standard Built-In Chain Commands reference

['net.httprequest', {

logRequest: true,

logEvents: true

url: '',

headers: {},

/ when set to false, it will allow https connections to self-signed certificates /

/ when an error would have triggered an unsuccessful outcome, setting this would return a success outcome with outcome.status set to myNumbericalValue and responseText set to outcome.reason /

/ optional /

/ optional: if you already have a tcp or web socket that you would like to use for multiplexing use requestOverExistingConnection by providing the connectionId /

}]

Package Runner (runpkg) and using invokeString over the JSONIO APIs

• No need to manage the HTTP metadata and headers
• JSONIO api security context can be 'transported' and simulated by the IDE, thus making implementation very very easy.
• The end-points can be directly consumed from chains anywhere in the cloud.

Notice that when settings up the runpkg chain processor, one of the configuration parameters is sessionMod which will be used to carry the authorization info when packages are run:

* When calls use the inline signature, the { ownerId, ownerType } is 'trusted' and used from the sessionMod

The difference between the context object for non JSONIO calls (i.e. plugin/http/handle newChain method) and the context object for JSONIO calls that gets setup inside the chain gets constructed for //inline/ or //cloud/ calls could sometimes get confused. It is worth remembering that non JSONIO calls (i.e. http handler) do not have built in authentication schemas and the implemtation is up to the user.

We will review the legacy and current implementations and call signatures below

Version 5

The following schema is supported

///pkg:module?method&forcepackagereload=1&methodnotfoundstatus=statuscode

• forcepackagereload: will force a cloud import for the pkg:module, overriding file system or any other cached copies. This will have a performance hit but will ensure freshest and latests code.
• methodnotfoundstatus: normally if module does not implement module (see rules for V3 below) the outcome will not be success. with this feature, the outcome will be successful and status meta key will be set to statuscode.

Version 3

//service/pkg:path?method

to maintaine backward compatibility with V2, the following procedure is followed:

• if method is defined, it will try to find it on modtask. and modtask.actions and if found, will launch with the following signature

function(queryObject, cb, context)

• if method is not defined, it will probe for modtask.processQuery and if that is found it will launch. Otherwise, it will try to run the entire module as a chain, with the following context object preset:

context: {

context: context

V1 and V2

`

modtask.apiInterfaceType = 'jsonio';

modtask.doChain([

['frame_getnode', modtask],

['frame_importpkgs', ['ui/node']],

function(_push) {

}

This can be consumed from anywhere in the cloud via chaining, i.e:

`

function(_push) {

}

Case Study: Bridging and consuming resources across different networks

Benefits Of Using the API Gateway

Recommended Configuration

• A running instance of izy-proxy INSIDE the intranet with access to the resources.
• A DNS entry that would resolve to the INTRANET IP ADDRESS of izy-proxy resource. e.g.

localhost.izyware.com 127.0.0.1

....

• SSL certificates corresponding to the DNS resources above: In most cases is not needed for the public facing izy-server instances where the HTTPS connections are handled by a load balancer. But in this scenarios, the izy-proxy instance should handle the HTTPS connection directly (see server.js):

../configs/izy-proxy/certificates/privatekey.pem

• domain config: you can pass in specific domain level config to the module. for example:

{ handlerMod: 'apps/bridge/...', domain: 'mydomain', config: {

verbose: {

}

}

Packaging

• A boilerplate app can be created (by cloning an existing one) which would immediately provide dashboard, toolbar, etc. features that can be accessed in the UI
• The app can be immediately used and integrated inside existing business workflows either via the api access points or via the frames/slides UI automation framework.

To make cloning and reusability easier, it is further recommended that the bridge functionality be implemented as a subpackage using the following scheme:

app_name/bridge/api

For example, the http bridge app included with izy-proxy uses:

apps/bridge/api.js

This would result in the route:

https://dnsentry.com/apigateway/%3Aapps/bridge%3Aapi

Which can then be further used to perform configuration tasks from the CLI, Dashboard Interface or more generally a JSON API call:

npm run apps/brige/api?setconfig queryObject.agent socks5://ip:port

Extending existing node apps

izy-proxy supports both a CLI (command line interface) and a referencable library. There are a few typical usecases for using those.

1. Launching JSONIO components using the CLI

You launch your components by:

`

`

if you would rather, use npm run, add this to the scripts section of package.json file:

`

`

this way, you can just call the action by doing:

`

`

If you need to make these available from the terminal from anywhere, place the call clause inside a seperate js file and link it to the package.json bin property. You can use the link command (or install -g), which will symlink the scripts in under the bin section to the prefix directory

npm prefix -g

Create a file as the global entry point to your package:

!/usr/bin/env node

chmod +x bin/izy.js

And finally reference it in the bin section of package.json. It can be used by npm install or by linking it:

npm link

If npm link does not work, you can manually link

ln -s npm prefix -g/bin/izy.xxx pwd`/bin/izy.js

cd myApp;npm run theAction ...

You could do this from anywere

izy.myApp theAction ....

See the samples folder for more information.

Quick Object Loading

Use the loadById for the source data schema:

const proxyLib = require('izy-proxy').basePath;

// json

// yaml

// xml

Output Formatting

• tsv (tab seperated values): useful for cut/pasting results into spreadsheets, etc.
• ssv (space seperated values): Useful for viewing in a terminal, but may not work well for cut/pasting into other apps.
• json: pretty json

You can consume these in chains by calling the format modules direcly:

const proxyLib = require('izy-proxy').basePath;

data,

}]);

Adding Search Path

`

cp ./node_modules/izy-proxy/modtask/config/kernel/extstores/file.js modtask/config/kernel/extstores/

You should then edit the modtask/config/kernel/extstores/file.js and add the hard coded and relative paths for the location of your repositories.

You can also use the following chain command for adding module search paths:

`

modtask.doChain([

chain => console.log(chain.get('outcome'))

`

2. Launching JSONIO components from legacy code in your app

In this case, call the newChain method:

`

chainItems: [

config: {}

['//inline/module?fn', {}]

callerContextModule: module

);

/ or more compact /

require('izy-proxy')(module).series([

], failoutcome => {});

`

To provide easier interoperability with newer versions of Python that support Asynchronous I/O you can use the async version. See python-asyncio for details:

`

let { status } = await run('net.httprequest', {

resolveErrorAsStatusCode: -1

console.log(status);

3. Build server functionality for RPC access

`

verbose: {

INFO: true,

},

port: {

},

plugins: [{

domains: [

],

import: {

}

}

});

Integration with Popular Frameworks

ExpressJS

const moduleSeachPaths = null; / optional, defaults to [${dirname}/]; /

app.all('/path/to/module', izyhandle);

HapiJS

const moduleSeachPaths = null; / optional, defaults to [${dirname}/]; /

server.route({

path: '/',

});

AWS

• package your project into a lambda and upload it into aws lambda. e.g. when using a zip package:

• enter the following string in AWS > Lambda > Runtime Settings > Handler

node_modules/izy-proxy/frameworks/aws/lambda.handler

• (optional) pass on the CLI arguments to your JSONIO component in AWS > Lambda > Configuration > Environment variables as AWSLAMBDACLI_STRING. For example if you are using the following to launch your component from the CLI:

npm run lib/mytest?mytask queryObject.p1 hello

then, create the following environment variable

AWSLAMBDACLI_STRING=lib/mytest?mytask queryObject.p1 hello

NOTE

for more details, visit izyware

Known Issues

Testing

• customers have requested that service test runner integration into the izy-proxy library.

Misc

• pkg/run consolidate extraInfoInLogs into the monitoring infrastructure and verbose flags
• importPackageIfNotPresent does not currently take advantage of strict mode optimizations

* an optional improvement would be to use /tmp folder cache to generate the function to skip the first raw evaluation

• provide a new JSON/IO compatible package loader

* this will enable distributing the pkg server across a cluster.

• default path resolution call/callpretty needs to allow '..' for izy-proxy children

node node_modules/izy-proxy/cli.js callpretty test/test

/ fails -- needs to work. works when called from izy-proxy root /

['chain.importProcessor', 'test/assert:chain'],

• runpkg needs to gracefully handle a '?fn' call in a chain without a chainAttachedModule set

* this scenario can happen for example when it calls directly from a node module

require('izy-proxy').newChain({

['//inline/?MyFN'],

}

• remove the kernel folder from root and include in izymodtask?
• runWithMethod is duplicated across apigateway/cli and g_cli. consolidation of configuration options is needed.
• allow relative paths in package names. this will help using the currenct context version for determining package names. so

['chain.importProcessor', 'izywaretoolbar/5/extension/api:chainprocessor']

will become

['chain.importProcessor', 'rel:../extension/api:chainprocessor']

• treat leading './' and '../' to imply 'rel:'.

Service Consumption

• the node service (features/v2/node/generic) still depends on legacy /apps/izyware/index

* some of the sql access, session management for legacy systems gets routed

Feature Requests

• networking

* net.http needs to allow for passing a transport agent

* for browser context require toolbar.

• context

* domains need to become part of the context

* perhaps after we have added domain to context add a config option to the api-plugin

* pass the IP address and headers metadata to the { sessionObjs } already present in HTTP handler as well as the RAW APIS

* note that in the node environment, req.connection.remoteAddress return 127.0.0.1 if you are behind a proxy

* Is this a valid point? may be not: this information will NOT be avilable in JSON/IO apis. The point of JSON/IO apis is transport independence and doing this will introduce the trainsport specific concept into it.

Chains

• (bug) single action chain items with top level module fail:

/ only happens when called from frameworks /

chainItems: [

],

moduleSearchPaths

}, outcome => {

delete outcome.callstackStr;

});

• (bug) raw APIs (non JSONIO) do not have the correct context for modtask.doChain module

• (feature) chainify socket and jsonio: its is essentially sending session (user) and what to call (action). this will be consistent with the service //service/mixeradminclient?getDeviceId

'socket://{connectionId}/rel:peer?handshake'

• (feature) support compact syntax in the framework. Currently apps/accountmanager/5/sessionfeature:chainprocessor implements locally

['chain.importProcessor', 'apps/accountmanager/5/sessionfeature:chainprocessor']

• runpkg, forces a path resolution dependency on moduleSearchPaths as currentdir + '/node_modules/izymodtask/'

* turns out the failure is coming from modtask.ldmod('kernel\\selectors').objectExist line in runpkg

Changelog

V7.3

• 73000014: update samples using async blocks
• 73000013: use streaming for transfering body payload for better performance
• 73000012: implement request origin F2B rule as the default behavior
• 73000011: implement response location B2F rule as the default behavior
• 73000010: use nano-service framework for monitoring http proxy

* use datastreamMonitor for monitoring

• 73000009: reset samplerate monitoring window every 10seconds

V7.2

• 7200004: catch error when callerContextModule is not specified
• 7200003: update README. fix typos
• 7200002: implement logEvents for http request
• 7200001: implement support for custom module systems via jsModuleSystem for chains

V7.1

• 7100005: monitoring - improve async code to suppress warnAsyncDoChainUsage feature and add more logging
• 7100004: add warnAsyncDoChainUsage feature
• 7100003: cli - allow customization of moduleSearchPaths
• 7100002: cli - implement generic piping for JSONIO scripts globally
• 7100001: cli - provide library for running JSONIO scripts globally

V7.0

• 7000014: monitoring - extend to other nano services inside the module
• 7000013: apps - portforwarding

• 7000012: add support for nano services inside application space

* similar to OS level support for services changeServiceConfig(windows), reload (unix)

* This will start the service, if not started on first interaction

* support for observables to the service context

• 7000011: monitoring - have the chain logger default to service context
• 7000010: monitoring - implement createForStreamMonitoring, improve log signature flexibility, implement fieldsSchema for logs.
• 7000009: chains - add spawnChildService mode for newChain context
• 7000008: chains - bugfix for newChain not capturing the full outcome properties in the parent chain outcome property
• 7000007: monitoring - implement outcomeMonitoring and syntax highlighting
• 7000006: monitoring - implement ability to filter by invokeString
• 7000005: async - convert non outcome return values to success outcome object
• 7000004: monitoring - implement ability to filter by service
• 7000003: monitoring - implement ability to have syntax highlighting in logs via useANSIColors
• 7000002: implement detectModuleReuseAcrossChains and canBeInstantiatedAcrossChainContexts
• 7000001: implement newChain object sharing and scoping via methodCallContextObjectsProvidedByChain. add support for monitoringConfig.monitoringIngestionService

V6.9

• 6900002: implement newChainAsync. improve async error handling
• 6900001: bridge/http - pass on request metadata to prerequest modules interceptors

V6.8

• 6800004: add lib/monitoring library from streaming server

* customers have requested that logging tools for streams be provided at the base server level

• 6800003: add proper error handling for json parser
• 6800002: runpkg new feature - support specifying the full network url.

* service reference schema now supporting [https:]//localhost[:port]/${path}/${action}

• 6800001: improve support for net.httprequest service

V6.3

• 6300025: implement support for requestOverExistingConnection and add json responseType for net.httprequest

* returns null when malformed json is present

V6.2

• 6200002: implement responseType for net.httprequest

* customer feedback needed to support modern XMLHttpRequest options

• 6200001: implement rejectUnauthorized for net.httprequest

* allows making https requests to end-points with self-signed certificates

V5.6

• 56000001: implement 'newChain' command for basic chain processing.

* this will enable handling errors gracefully for event driven apps without throwing the main chain.

V5.5

• 55000008: fix assertion library bug by treating null values as special objects
• 55000007: improve error handling for moduleSearchPathAdd
• 55000006: chain.importProcessor needs to support 'rel:xxx'

* This will be more consistent with the package launcher // schema.

/ ambigious -- chain could be found in a lot of different places /

/ would be like modtask.ldmod('kernel/path').rel('chain') /

• 55000005: prioritize usermodule.getModuleSearchPaths over default Kernel search paths

* customers had reporting module path resolution conflict for rel:build with internal build components.

• 55000004: remove izymodtask packge dependency
• 55000003: update aws framework libraries
• 55000002: implement net.httpproxy
• 55000001: implement runpkg.intercept

V5.4

• 54000026: fix import config processor bug
• 54000025: improve node module simulation for chainAttachedModule and leverage Kernel postLoadModule functions.

• 54000024: make moduleSearchPaths optional for framework libraries
• 54000023: implement runpkg/import/izynodechainProcessorConfig for dynamic setting of the processors
• 54000022: implement forceRequireOnLoadFromFile
• 54000021: runpkg support ?fnName syntax and default to inline

* this will support a more compact syntax

• 54000020: add chain.moduleSearchPathAdd
• 54000019: add new tools to the assertion lib
• 54000018: provide package name when importing fails
• 54000017: enforce application/json content type
• 54000016: (security) allow POST requests for hapi and express frameworks templates
• 54000015: implement Flaviu Cristian clock sync algorithm
• 54000014: (security) cleans the pkgloader url
• 54000013: support custompackageloader for 3rd party modules and package publishers
• 54000012: allow url customization for cloud pkgloader
• 54000011: provide callstack when outer exception is thrown for newChain
• 54000010: security - reallocate node and import proccessors on each load

* concurrent threads might be able to get access to execution contexts when common module address space is used

• 54000009: enforce source code tracking for samples
• 54000008: getRootModule should always return new object
• 54000007: add forcemodulereload feature

* enables object construction delegation to the module load phase

• 54000006: reorganize and clean up tests
• 54000005: add reference to Kernel and module store per module
• 54000004: support self loading izymodtask

* this will allow module consumption via require and ldmod

• 54000003: add support for direct assertions on string and numbers
• 54000002: enforce source code tracking using izy-loadobject tag
• 54000001: implement strict mode

* better performance

V5.3

• 53000482: replicate runWithMethod in the apigateway
• 53000481: Increase test coverage for izymodtask
• 53000480: Serialize frameworkresponse for backward compatibility
• 53000479: improve expandStringEncodedConfigValues
• 53000478: provide replacement for izymodtask/encodedecode/uri with izymodtask/uri
• 53000477: fix formatting issue for integers
• 53000476: add support for YAML format.
• 53000406: add flexible config loader for JSONIO components:

* when id is an object it will parse and verify

• 53000405: add output format options for cli.
• 53000404: add flexible npm launch options for better console management.
• 53000403: expose basePath from index.js

• 53000402: Support minimal config design service

* consume moduleSearchPaths to locate mod?fn relative to app.js (see below)

curl --header "Content-Type: application/json" -X POST "http://localhost:17800/apigateway/mod?fn" -d '{}'

require('izy-proxy/server').run({

plugins: [{

moduleSearchPaths: [dirname + '/']

});

• 53000401: fix getRootModule data corruption bug
• 53000400: move bootstrap into izy-proxy
• 80001333: add logging to net.httprequest
• 80001332: show user feedback when proper url string is not provided.

V5.2

• assert.value: verbose option for testeeObj
• process taskrunner inside izy-proxy. use API configurable task iterator and recorder

* Decouples the hosting environment from the apps/tasks/_ packages

• move memtest suit to test directory
• send masterMetrics to slaves for monitoring
• support for clustering and autoscaling

V5

• add support for resolveErrorAsStatusCode to net.httprequest
• make body string mandatory for POST/PUT net.httprequest
• add support for ip:port scheme to net.httprequest
• remove dependencies to components/net/http:chain

* add http chain net.httprequest

• set JSON/IO content-type to application/json
• do not send back outcome.callstackStr in JSON RPC

• assert.value should accept hierarchy of operators

• add default moduleSearchPaths to CLI to allow out of the box functionality without external path resolver
• for pkgrunner implement methodnotfoundstatus

* now supporting ///pkg:module?method&forcepackagereload=1&methodnotfoundstatus=statuscode

• add support for chainProcessorConfig.moduleSearchPaths

• set outcome to the loaded module on chain.ldmod/ldpath

• allow local definition for modToPkgMap in the runpkg.chainProcessorConfig

* the package names are used extensively for access control and customization. therefore we cannot assign arbitrary names to the packages

• leverage izy-loadobject nodejs-require feature and replace relRequire calls.
• add dontUseDefaultRelConfigFile per customer feedback

• implement runpkg.setSession

• runpkg: strip out method call params when determining invokeString from rel package name
• izynode: add support for non node environments
• add sessionMan documentation
• add explicit depencies in building the bootstrapers or statically linked components
• pkgloader/izycloud: remove dependency to Kernel http module and use proxy universal http
• allow chain context to be function or object

V3

• remove nodejs dependency to izy-circus
• http plugin: pass in the full object to the http handler
• add test for delay/replay combo
• explicitly disallow /// launch strings
• add interactive configuration for tcpserver through meta.action in the cli
• pass in { sessionObjs } as context to the http handler

* this scheme is consistent with call signature for jsonio calls

• pass in chainProcessorConfig.runpkg to http and socket handlers to allow debugging issues
• add parameter checking to importPkgs
• add the ability to encode json objects at the commandline, i.e.

node cli.js method chain chain.action '//../...' chain.queryObject.provisioningConfig.type json:[\"domain_manager\"] chain.queryObject.provisioningConfig.userids json:[\"@userlastinsertid\"]

• open the universal HTTP library (in runpkg)

* standard signature for handling errors, non 200s, etc.

• Explicitly send in the utf-8 character set in the HTTP headers
• Added the new IzyNode type "izy-proxy" that uses hex encoding

* This will work in environments that use older encodings on some areas of the stack (i.e. the HTTP server or Scripting)

• When the query has the non latin unicode and encryption is turn on it happens

• fix bug in izyNode config is not correctly transffered to getNode
• add more tests coverage for parity across //network/ and //local/

* added tests to ensure that parameter types are being serialized and deserlized correctly across context boundaries

• improve error reporting and diagnostics
• make sure pkgloader is configured correctly for socket handler loader
• add chain.relConfigFile option to chain cli
• improve socket.pipe to copy cached data

• fix JSON encoding bug where outcome.callstack would call circular referencing error
• retire decodeBase64Content
• allow ldPkgMan to work even when no pkgloadermodname is provided (features/v2/chain/processors/import.js)

* used to fail before even trying to check if modules were present locally

• add handlerWhenChainReturnCBThrows to newChain

* needed in settings where making doChain available for pkgruns (example rawhttp APIs, etc.)

• add test/all.js
• add test/runpkg, testing for runpkg across //inline/ and //network/
• add test/api making sure that API system still supports JSONIO agnostic with mod.handle for generic purposes
• fix the customer reported issue where for JSON/IO luanches, //inline/ should be 100% consistent with //network/ for all combinations.

* This will make it harder for customer to create cloud components that can be deployed reliably to different cloud environment.

* moved the rawhttp, mod.handle interface with chain enabled into its own module within the api plug-in

• clean app the server module.

* made the certificate paths optional

• add ability to define http domains as inline parameters.

* this will allo non connected apps to work local

• fix bug with cloud import auth

* when auth is not defined, the cloud import will not hit the izycloud

• deprecated noReimportIfAlreadyLoaded since the forcepackagereload=1 for pkgrun
• new features chain.deportPkgs and forcepackagereload=1

* this will force a chain.deportPkgs before importpkgs

* it will work well with importpkgs and caching layer there

* the importCache is scoped per import processor

• socket plugin and processor was upgraded to allow for an easier and more intuitive interface

* using socketIds to communicate between the processor and clients. this should allow for embedded socket applications

• updated most chain processors to

* ditch doChain in favor of newChainForProcessor

• the following cotext and callback pattern specific utility wrappers around newChain have been introduced

* newChainForProcessor: while handling an item in a $chain will run a new chain in a new context, and on failure will exit the $chain. when success it will do next (move on to the next item in the $chain). The new running context will be tied to the processor module and the resulting callstack in case of a failure will trace to the processor.

• deprecated $chain.doChain

* this would 'share' the running context (callbacks and context) across $chain and the new chain which will lead to maintaince issues

• updated //inline/ to support '//inline/pkg:module?processQueries' call pattern with optional package and module paths

* useful for calling internal methods in a module from a chain without writing code

* '//inline/?actionName' will run modtask.actions.actionName(...)

• updated //inline/ to support pure chain interfaces in addition to processQueries

* the 'queryObject' and 'context' will be passed as chain keys

* all other subsystem, including the APIs should be using this

• deprecated //chain/ launch method in favor of //inline/

* //chain/ was sharing context across chains which can lead to problems

• modified the outcome reporting and error handling model for the chain finalCallback to immediately terminate and report as opposed to shoving the outcome in chain.

* if the system level is successful, $chain.get('outcome') will be reported

• deprecated the the explicit
• added the ability to attach running contexts to modules

* this will provide valuable information when reporting failures and construcing stack traces

• runpkg: deep clone the inline launch parameters

* this will ensure that the execution contexts are seperate and the data will not be leaked or corrupted

• added tracing and callstack for chains

Error Handling:

* error reporting should give back modules, and where in the modules, and the path (stack trace) that got things there

* syntax error inside a dynamic function

* source code errors when loading

• fixing command line bug and adding meta.action checkconfig for allowing quick configuration testing on deployments and testing
• bugfix: make sure importPackage tests the existence of pkgName/package.js

V2

• cloudservice: allow handling of wildcard for subdomains
• implement universalHTTP transport layer to allow reusing izy-proxy components in the browser and other environments.
• add support for relative paths in the pkgrunner luanch string

['//izyware.com/rel:modname', {}, mod]

• add dontDefaultToHttpWhenServiceNameUnrecognized flag to pkgrunner
• Pass in authorization token as part of the session object to the pkgrunner

* The token might be used for making HTTP based (not inline) calls

• Pass in the current session when making inline requests.
• New impementation of Authorization header security

* Updated the OPTIONS response to indicate that authorization headers are accepted when making cross domain calls.

• added test/cloudwatch/base for running service tests on a live version

* this will enable an automated task for doing tests on the live service from the IzyCloud enterprise dashboard

* APIs

* circus

• added assertion library to enable simple smoke tests

* consolidated from toolbar and other libraries

• added options for cacheImportedPackagesInMemory and noReimportIfAlreadyLoaded to the runpkg, and import chains to allow dynamic remote updating of the modules in the task runner.

* If this is not turned on, the module updates will only be picked up on taskrestarts which is not desirable.

• restructured the taskrunner component and added sample config file for standalone deployment of the taskrunner.

* added apiExecutionContext to taskrunnerProcessor config for remote and local configurations and deployments.

• added the ability to configure chain processors
• added the ability to 'replay' a chain and thus looping through easy

* this is important for processing data sets:

['newChain', {

chainItems: [

if (offset >= maxOffset) {

['log', 'ran ' + maxOffset + ' sets of queries'],

data: queryResults,

}],

]);

chain([

]);

['ROF'],

]

• the seperation of contexts, ability to import and doChain/newChain will enable the apps/tasks/api feature

* process seqs.onNewTask and capture the outcome if error without CONTAMINATING itself

pre import relevant processors (task.)

• improved doChain so that it will create the context (dataspace, callbacks) on the fly so that the chain processors can also have doChain internally and the 'finally' part can be optionally localized (similar to how the try/catch works. The layer that has the catch will work).

* This will allow us to have nested chains, and subchains, etc.

• pass the $chain to the chain handler that would allow access to chain context as well as doing doChain, newChain, etc.

* being able to doChain internally is important because the chain handlers may need to utilized other commands inside the current context.

* virtually, doChain/newChain will allow differentiation on the following:

* will it have an outcome handler or will it go to parent?

• improved chain management so that we can 'importProcessor' processors, since chain 'actions' will be 'processed' by processors.

* this will open up implementation by chain.

External Resources

• git
• npmjs

automation-desktop: https://github.com/izyware/automation-desktop

npmjs: https://www.npmjs.com/package/izy-proxy

izyware: https://izyware.com