KAAT (Kentika As A Toolbox) : utilisation de l'API
Préambule
L'API KAAT s'adresse aux applications métiers nécessitant des fonctions de GED. Dans le cas d'une application de gestion, la base de données gère toutes les informations relatives aux domaines couverts, la GED prend en charge les documents (exemple : une facture, un rapport, un contrat... au format pdf, doc, xls...).

Cas d'utilisations
A/ Kentika est l'application de gestion de l'information dans son entreprise, l'API de GED est utilisée par une application métier pour bénéficier de ces fonctions e t/ ou l'API est utilisée pour diffuser des informations nativement dans Kentika sur un portail.
B/ L'application métier alimente la GED de Kentika via l'API, effectue des recherches, insère des liens GED dans des pages de résultats.
C/ L'application métier alimente la base de données documentaire et la GED de Kentika, utilise le portail de Kentika (Atomic) pour diffuser ses informations.
Dans ces trois cas de figure, l'API sera utilisée. Dans le cas A : une analyse complémentaire sera menée pour déterminer quels index seraient alimentés lorsque les fichiers seraient versés dans l'application documentaire. Dans le cas B, une alimentation a minima des index serait mise en place. Dans le cas C, le portail Atomic de diffusion des informations ferait l'objet d'une analyse.
Quel que soit votre projet, nos experts peuvent vous accompagner.
Installation
Kentika et KDE doivent être préalablement installés et opérationnels. Pour plus d'informations sur l'installation du logiciel : cliquer ici. L'API de KDE est utilisée par Kentika et peut également être utilisée par une autre application métier.
Après lancement de Kentika server, s'assurer que le serveur http répond correctement. En cas de difficulté : se reporter ici.
Il sera également nécessaire de vous assurer que le pare feu ne bloque pas les requêtes vers le serveur http de Kentika.
Démarrage
Pour que l'API réponde aux requêtes en REST, il suffit que l'option suivante soit cochée :

Les web services de Kentika utilisent le serveur http, les requêtes sont envoyées en "POST", les paramètres sont exprimés en JSON, le résultat est également obtenu en JSON.
Le dialogue illustré ci-dessus permet de tester le bon fonctionnement de l'API et de familiariser avec son fonctionnement. Il permet, à partir d'un client Kentika, d'adresser une requête au serveur Kentika et de visualiser le résultat.
Si vous connaissez le langage 4D (Kentika est intégralement écrit en 4D et exploite le serveur intégré), l'application mise à votre disposition vous facilitera l'écriture de votre propre code. Pour la télécharger : cliquer ici.
Structure de données
Votre projet sera différent suivant que Kentika est utilisé comme portail ou comme boîte à outils. Les trois points forts de Kentika sont la gestion des méta données, le portail et les fonctions de gestion électronique de documents. Il est possible de n'utiliser l'API que pour une partie seulement des possibilités.
Si vous souhaitez bénéficier du portail Kentika Atomic pour publier des informations disponibles dans une application métier : une attention particulière sera apportée à la structure des données afin de proposer des outils de recherche multi-critères.
Si ce sont les fonctions évoluées de gestion électronique de documents qui importent, quelques rubriques suffisent.
Si vous souhaitez publier sur un portail (autre que Kentika Atomic) des informations disponibles dans Kentika, il vous suffit de connaître la structure en place.
Pour créer un espace de stockage "privé" dans une base Kentika existante pour recevoir des données provenant d'une application métier, un complément de paramétrage sera peut être nécessaire.
Les tables "maître" de Kentika
Les personnes : toute personne physique devant bénéficier des possibilités offertes par le logiciel.
Les documents : toute information quelqu'en soit la nature (exemples : des contrats, factures, brevets, photos, rapports...).
Les "références" : toute personne morale permettant de caractériser une information (exemple : des services, clients, fournisseurs, partenaires...).
Les types
Chaque table maître peut être déclinée en différents types. Chaque type peut recevoir des méta données différentes et peut être utilisé pour définir des autorisations spécifiques par personne (ou utilisateur).
Les rubriques
Le dictionnaire de données de Kentika est ouvert et évolutif. A tout moment, on peut intervenir sur ce dernier et le faire évoluer en fonction de ses besoins.
Si, lors de l'alimentation via le webservice "update", un document est créé avec une rubrique inconnue de Kentika, cette dernière est stockée sur la fiche et pourra être restituée lors d'un "select" mais ne pourra bénéficier de toutes les fonctions documentaires proposées par le logiciel.
Gestion des droits
Kentika permet une cartographie des droits allant du plus simple au plus sophistiqué. Suivant le projet à mettre en place, une organisation des droits adaptée sera à définir.
Kentika est utilisé comme boîte à outils GED, les droits sont gérés dans l'application métier : une organisation basique sera suffisante (un administrateur, sans restriction).
Kentika publie les informations d'une application métier sur le portail Atomic : une réplication (totale ou partielle) sera mise en place.
Kentika accueille des données en complément d'une base existante : un complément de paramétrage sera peut être envisagé.
API et identification
L'API respecte totalement les autorisations qu'auraient un utilisateur s'il se connectait directement à l'application ou au portail. Aussi, lorsqu'une requête est adressée au serveur Kentika, il convient de s'assurer que la personne spécifiée dans la requête dispose bien des droits nécessaires.
Il convient donc de créer soit quelques "personnae" type et d'indique les identifiant / mot de passe lors des requêtes, soit de synchroniser les personnes de l'application métier avec celles de Kentika (via l'API...).
Basic ou Digest ?
Le niveau de sécurité de "Basic" est très faible, si votre solution le permet, le mode Digest lui sera préféré.
Paramètres de connexion
Host : exprimé sous la forme "http://(nom du serveur)/"
URL : REST/(nom du service)
Exemple : http://localhost/REST/Select
User ID / password : à transmettre, en mode "Basic" ou "Digest" (cf. ci-dessus).
Method : POST
Paramètres : JSON
Les services
Fields : liste des champs de recherche et alimentable avec attributs et valeurs autorisés (cas de liste fermée), cliquer ici.
Select : recherche sur une table / un type ; mono ou multi-critère, cliquer ici.
Update : création / modification d'enregistrement ; archivage de fichiers, cliquer ici.
Delete : suppression d'enregistrements, cliquer ici.