Remote SDK stream

Note

These feeds are old and destined to disappear, so it is preferable to use the new API (see the RestFull API page).

Warning

Since Process17.0.0, the user-agent header must be filled in.

The distant request systems

Process provides a system of distant services enabling data exchange with external applications.

The SDK integrates a system of remote services allowing external applications to communicate. It can be read elements of the instance or even create, modify.

All this takes place in a secure context for which the directory remains the guarantor (security in place on the instance).

Technologies

The web services perform data exchange based on a simple HTTP layer. You can use either XML or JSON format.

The syntax used in these flows will have to meet a standard defined by Process.

Principle of exchanges

Schema Flux SDK Schema Flux SDK

Securing data flows

Securing data flows is possible at two levels:

  • By the authentication flow and the principle of “token” that follow different data flows.
  • By restricting the access by setting up an allowed IP range. The configuration key is:com.axemble.security.ExternalAuthenticationAction.allowedAddresses.
Note

This key is assigned to 127.0.0.1 by default on the instances, which means that only local access is possible. A simple setting in the CustomResources.properties file will allow you to customize that configuration.

Une simple surcharge dans le fichier CustomResources.properties vous permettra de personnaliser cette configuration.

API Cliente (Objets)

Distant request is a first step for us in the inter-connectivity between Process and outside. The second step is to provide APIs client in the most used languages. Obviously, this APIs will call flows and convert them into objects.

This project is still ongoing. Here’s the progress:

Language Applications Mobile application Progress state
Objective-C iMac iPhone or iPad Available in version 12
Java Java Android or BlackBerry Available in version 12
.Net .Net Windows Mobile

Technical overview of flows

Classification of flows by modules

The flows are classified by “modules”, it is simply a thematic gathering of flows.

For instance, flows linked to process’s will be in the Workflow module.

Flow call principle

We will always call the same Controller to execute our flows (the servlet principle) and it will be possible to specify options.

Details of options:

Option Description
module Specifies the module that owns our flows.
cmd Specifies the flow that will be used.
killsession Kills SDK sessions created by the user (default: false if omitted).
flowmode Format to be used: [xml, json, jsonformatted] (default: XML if omitted)
_AuthenticationKey Specifies the token that has been issued to us (Process secured session)

Here’s an example of URL call: http://myvdocserver/vdoc/navigation/flow?module=workflow&cmd=create&_AuthenticationKey=...

Info

Since flowmode isn’t specified, the XML format will be used.

XML/JSON envelopes

In the above example, the URL will send (in “POST”) a flow characterizing our request, to which Process will respond with another flow in response to the request.

Prerequisites for the use of these remote flows

The only requirement to be able to handle authentication is to activate the “Login Module” com.axemble.security.loginmodules.ExternalAuthenticationLoginModule. This login module is already set in the default JAAS config but commented. (see the “Login modules” page).

Note

In order not to saturate the memory of your machine, you must retrieve the session cookie in the headers of the response to the first call and send it back to the following calls.

Flow modules

In the context of this flows presentation, the examples will be in XML because it is much easier for human to read. However, the logic of JSON syntax is quite identical.

For information about how streams can be adapted to JSON format, see the page “Flux XML/JSON”.

Information

The flows are led to manipulate different types of data. The page “Types de donnĂ©es” detail the syntax of these different types.

General module : Portal

Flow command Description
authenticate This flow will be the first flow to be tested and used in your developments. It will allow you to authenticate with a login and password and return a token key that will be used for all subsequent flows.

Upload and Download module : IO

A global module

It should be understood that the “io” module is very versatile.

It allows us to manipulate the files of all other modules: workflow, data universe, library, …

GUID principle

GUID is an acronym for ‘Globally Unique Identifier’, it’s a unique reference number used as an identifier in computer software.

Here’s the principe:

  • When you want to download a file, you first prepare the file by booking a GUID that will be returned by the flow. From there, the GUID allows you to download the file at any time, it has been reserved for you.
  • When you want to upload a file, we store it in a “temporary” state and we return you a GUID. You can use this GUID to attach your file to a Process document (a “FileCenter” document for example).
Flow command Description
download This flow will allow you to download a file present in the instance.
upload This flow will allow you to upload a file to the instance.

Workflow module : Workflow

Flow command Description
view This flow allows to browse the Workflow objects. The objects could be both definition objects (administrative objects) and dynamic objects (documents).
get This flow retrieves detailed informations on a particular object.
create This flow creates a new Workflow document.
update This flow updates a Workflow document.
delete This flow deletes a Workflow document.
cmd This flow allows to execute specific commands that are available in the old remote SDK flows : ASSIGNED_TASKS, DELAYED_TASKS, CATALOGS, WORKFLOW_CONTAINERS, WORKFLOWS. These flows are not yet deprecated but they will disappear because they do not fall within the new organizational logic of flows.

Data universe module : workflow

Info

We also use the workflow module here. We keep the same logic as in the pure development: given the similarities between the processes and data stockroom, the same module is used.

Flow command Description
view This flow allows to browse the data stockroom objects. The objects could be both definition objects (administrative objects) and dynamic objects (documents).
get This flow retrieves detailed informations on a particular object
create This flow creates a new record.
update This flow updates a new record.
delete This flow deletes a new record.

Document spaces module : Library

Flow command Description
view This flow allows to browse the document space : folders, categories, documents. The objects could be both definition objects (administrative objects) and dynamic objects (documents).
get This flow will allow to retrieve detailed information on a Process object by using a URI protocol.
create This flow creates a new item in the document space: documents, folders.
update This flow updates an existing item in the document space: documents, folders.
delete This flow removes an existing item in the document space: documents, folders.
move This flow moves an item to an another folder.
checkout This flow locks a document.
undocheckout This flow aborts a lock on a document.
checkin This flow unlocks a document.

Directory module : Directory

Flow command Description
view This flow allows to browse the Process directory such as organizations, localizations, groups and users. The browsing is done by tree structure, thanks to structuring objects that are organization, localizations and groups.
get This flow allows to retrieve object informations from the element ID (the URI protocol)
create This flow creates new item in Process directory.
update This flow creates new item in Process directory.
delete This flow updates new item in Process directory.
enable This flow enables new item in Process directory.
disable This flow disables new item in Process directory.

Source : https://wiki.myvdoc.net/xwiki/bin/view/Dev+Floor/SDKFlowsReference