0

6 La navigation dans le manuel de Kentika est réservée aux utilisateurs identifiés



KAAT (Kentika As A Toolbox) : utilisation de l'API

#API (Application Programming Interfaces) ; Recherche documentaire ; Web services ; Gestion électronique de documents

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.

KAAT (Kentika As A Toolbox) : using the API

Preamble

The KAAT API is intended for business applications requiring EDM functions. In the case of a management application, the database manages all the information relating to the areas covered, the EDM supports the documents (example: an invoice, a report, a contract ... in pdf format, doc, xls ...).

Use cases

A / Kentika is the information management application in his company, the EDM API is used by a business application to benefit from these functions and / or the API is used to disseminate information natively in Kentika on a portal.

B / The business application feeds Kentika's EDM via API, performs searches, inserts EDM links into result pages.

C / The business application feeds the Kentika document database and EDM, uses the Kentika (Atomic) portal to disseminate its information.

In these three cases, the API will be used. In case A: a further analysis will be conducted to determine which indexes would be fed when the files were poured into the document application. In case B, a minimum supply of indexes would be set up. In case C, the Atomic information dissemination portal would be analyzed.

Whatever your project, our experts can accompany you.

Start-up

Kentika and KDE must be installed and operational beforehand. For more information on installing the software: click here. The KDE API is used by Kentika and can also be used by another business application.After launching Kentika server, make sure the http server responds correctly. In case of difficulty: click here.

It will also be necessary to ensure that the firewall does not block requests to the Kentika http server.

Start-up

In order for the API to respond to requests in REST, it is sufficient that the following option is checked:

Kentika's web services use the http server, the requests are sent in "POST", the parameters are expressed in JSON, the result is also obtained in JSON.

The dialog shown above is used to test the operation of the API and to familiarize with its operation. It allows, from a Kentika client, to send a request to the Kentika server and to visualize the result.

If you know the 4D language (Kentika is fully written in 4D and uses the integrated server), the application available to you will facilitate the writing of your own code. To download it: click here.

Data structure

Your project will be different depending on whether Kentika is used as a portal or as a toolbox. Kentika's three strengths are metadata management, portal and electronic document management functions. It is possible to use the API for only part of the possibilities.

If you want to use the Kentika Atomic portal to publish information available in a business application: special attention will be given to the data structure to provide multi-criteria search tools.

If it is the advanced features of electronic document management that matter, a few headings are enough.

If you want to publish information on a portal (other than Kentika Atomic) available in Kentika, you only need to know the structure in place.

To create a "private" storage space in an existing Kentika database to receive data from a business application, additional configuration may be required.

The "master" tables of Kentika

Persons: can access the database end benefit from the possibilities offered by the software.

Documents: any information whatever its nature (examples: contracts, invoices, patents, photos, reports ...).

The "references": any entity that characterizes information (example: services, customers, suppliers, partners, etc.).

Types

Each master table can be divided into different types. Each type can receive different metadata and can be used to set specific permissions per person (or user).

Fields

The Kentika dadata dictionnary is open and scalable. At any time, we can make it evolve according to its needs.

If, when feeding via the webservice "update", a document is created with an unknown field, the content is saved and can be restored via a "select" but can not benefit from all documentary functions offered by the software.

Rights management

Kentika allows rights mapping from the simplest to the most sophisticated schema. Depending on the project to be implemented, a suitable rights organization will have to be defined.

Kentika is used as a EDM toolbox, rights are managed in the business application: a basic organization will be sufficient (an administrator, without restriction).

Kentika publishes the information of a business application on the Atomic portal: a replication (total or partial) will be implemented.

Kentika hosts data in addition to an existing database: further configuration may be considered.

API and identification

The API fully respects the permissions a user would have if he logged in directly to the application or portal. Also, when a request is made to the Kentika server, it must be ensured that the person specified in the request has the necessary rights.

It is therefore necessary to create some "personnae" type and indicate the identifier / password during the requests, or to synchronize the people of the business application with those of Kentika (via the API ...).

Basic ou Digest ?

The security level is very low, if your solution allows it, the Digest mode will be preferred.

Connection settings

Host: expressed as "http: // (server name) /"

URL: REST / (service name)

Example : http://localhost/REST/Select

User ID / password: to transmit, in "Basic" or "Digest" mode (see above).

Method : POST

Parameters : JSON

Services

Fields : list of search fields and food with attributes and values allowed (case of closed list), click here.

Select : search on a table / type; mono or multi-criteria, click here.

Update : create / edit record; archiving files, click here.

Delete : delete records, click here. ​