SDK essential

API

SDKFactory

Depuis Process2024.1.0, un nouvel accès qui deviendra le seul point d’entrée aux fonctionnalités du SDK a été créé.

Il s’agit de la SDKFactory, accessible sans instanciation.

Modules

L’accès à l’API passe par des classes gestionnaires que l’on nomme “module” : ce sont vos points d’entrées dans le SDK. La règle d’Or : Si vous cherchez une fonctionnalité, vérifiez d’abord sur votre module les méthodes disponibles.

Les modules sont classés par fonction :

• Les modules sont accessibles dans tout code et peuvent être utilisés dans des classes Java “non identifiées Process”.
• Si vous vous intégrez dans un contexte Process identifié, on vous fournira le module le plus approprié (pas nécessaire de le déclarer)
• Rien ne vous empêchera par contre de déclarer vos propres modules.
• Plusieurs modules peuvent cohabiter dans un même code.
• Un module peut être initialisé via la classe Modules.get…; il doit alors être libéré par Modules.releaseModule(…)

Objets “métier”

Les modules manipulent des objets Process qui leur sont propres. Ces objets n’intègrent pas obligatoirement toutes les APIs pour naviguer entre eux ; c’est le rôle du module.

Exemple : si je récupère un dossier de la publication documentaire, pour récupérer les documents de ce dossier, on ne fera pas iFolder.getFiles(); mais plutôt iLibraryModule.getFiles(iFolder);.

Identifiants

Process intègre différents identifiants :

• La IStorageKey : cette classe encapsule l’ID “base de données” de l’objet que vous manipulez; il est unique et est dépendant de la base et n’est pas obligatoirement unique sur toute la base (dépend du type d’objet)
• La Protocol URI : il s’agit d’une chaîne de caractère produite par Process (ou par vous en spécifique) et qui permet d’identifier de manière unique un objet dans Process. Cette clé sera privilégiée quand il s’agira de stocker des liens entre objets (ou autre besoin de stockage).

Scripts

Principe d’exécution de Scripts Java côté serveur

Process permet en effet de définir des scripts directement dans l’interface d’administration de Process : Workflow, EasySite, …

Il faut bien garder à l’esprit qu’il ne s’agit pas de Javascript client mais bien de Javascript côté serveur; ces codes sont évalués côté serveur et donne lieu à des exécutions qui auraient pu être faites par des codes Java (extensions par exemple).

Nous ne nous étendrons pas ici sur le JS puisque que les objets sont les mêmes qu’en Java et qu’à quelques exceptions prêt, la syntaxe sera la même qu’en Java.

Pour plus d’informations sur l’utilisation des scripts, reportez vous à la page dédiée.

Exécutions libres de codes SDK Process

Agents

La création d’un agent passe par un héritage de la classe com.axemble.vdoc.sdk.agent.base.BaseAgent. La méthode execute de cet agent sera lancée.

Vous pouvez déclarer vos agents dans l’interface Process en renseignant le nom complet de votre classe.

Les agents se situent dans l’administration dans Serveur / Planification des agents. Vous avez la possibilité dans cette version de déclarer vos agents dans des fichiers XML sous forme de modèles. Ces déclarations se font dans le dossier custom/webapp/WEB-INF/storage/custom/agents.

Controllers

Le principe du Controller est de reproduire dans l’environnement Process et avec plus de souplesse la logique des servlets Java. Vous pouvez donc créer un code qui sera déclenchable à volonté (en mode authentifié ou non) depuis une URL HTTP.

La création d’un Controller passe par un héritage de la classe com.axemble.vdoc.sdk.controllers.BaseController et l’appel d’un Controller se fera via le modèle d’URL suivant : http://SERVERNAME/vdoc/navigation?Controller=com.chemin.de.ma.Class.

Les Controllers peuvent être définis dans des fichiers XML (même principe que les déclarations de servlets). Il sera ainsi possible d’appeler une URL plus “humaine”.

Vous pouvez évidemment utiliser tous les objets SDK dans vos propres objets Java.

Système d’extensions

Les extensions sont des classes Java Process à étendre. Ces classes Java ont donc une pré-organisation et vous pouvez greffer vos développements sur des évènements identifiés (méthodes de la classe).

Workflow / Réservoirs de données

Il existe également les triggers, dans lesquels il s’agit également de capter des évènements bas-niveau (même principe que la BaseResourceDefinitionExtension) mais plusieurs différences :

• Sur des objets de différents types : workflow, annuaire, publication documentaire, … (Seulement sur l’annuaire pour l’instant)
• Le scope est différent : sur l’ensemble de Process et non des éléments précis (pas seulement sur une application de workflow par exemple)

Authentification

Annuaire

Publication WEB

Packaging

Protocol URI

Framework graphique

Process utilise pour construire ces écrans un “framework graphique” qui est mis à disposition du SDK. Ainsi, vous pouvez créer des écrans personnalisés utilisant ce framework.

Avantages :

• Facilité de conception
• Facilité pour inclure ces écrans dans Process (Inclusion native)
• Cohérence graphique et ergonomique entre le standard Process et les développements spécifiques
• Migrations plus simples

Ecrans

Chaque écran du framework intègre :

• Une description XML : positionnée dans le dossier “navigation” (voir plus haut)
• Une classe provider : cette classe permet de controller l’écran et de gérer son comportement : chargement, sauvegarde, interactions avec l’utilisateur, … Chaque type d’écran possède sa propre classe de Provider qu’il faudra étendre.

Champs personnalisables

Vous pouvez créer vos propres champs personnalisables SDK en contrôlant à la fois la configuration, le stockage et le rendu final de votre champ.

System names

Data types in SDK

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