M8 : Choix et application des solutions

Description

• En fonction des projets déterminés autour de l’« Intégration de services dans un éco-système », savoir identifier, choisir (y-c défendre) et adapter les solutions les plus appropriées pour les défis rencontrés.

Mots-clés : Intégration, DLM, architecture, Web Services, automatisation, processus, …

Ma validation

Projet Kinaps

Le projet Kinaps nous a demandé de faire plusieurs choix technologiques tels que :

• L’authentification en utilisant la librairie MSAL, la configuration des tokens dans le portail Azure, etc.
• L’intégration de l’API de Kinaps dans notre application, principalement l’affichage des boards dans un iFrame puis dans un onglet du browser

Ces choix ont été judicieux étant donné que notre POC fonctionne et que les principaux éléments encore non fonctionnels sont liés à des problèmes du côté de Kinaps. (affichage d’un board dans un iFrame dans l’iFrame Teams) Le seul choix que je vais encore explorer d’ici à la fin du mois de janvier et l’utilisation de la fonction loginPopup de MSAL qui permet de faire un login dans une popup browser. Ceci fonctionne très bien dans l’environnement de débugging web, mais lors d’un test dans l’application Teams, le retour d’authentification contenant l’ID TOken se fait via un URL qui s’ouvre dans le navigateur par défaut. La solution est très certainement d’utiliser la fonction loginRedirect de MSAL, mais elle créé une “cascade” de bugs que je n’ai pas encore eu le temps de résoudre.

    loginPopup(userRequest?: AuthenticationParameters): Promise<AuthResponse>;
    /**
     * Use when you want to obtain an access_token for your API via opening a popup window in the user's browser
     * @param {@link AuthenticationParameters}
     *
     * To renew idToken, please pass clientId as the only scope in the Authentication Parameters
     * @returns {Promise.<AuthResponse>} - a promise that is fulfilled when this function has completed, or rejected if an error was raised. Returns the {@link AuthResponse} object
     */

Extrait de code décrivant le loginPopup

    loginRedirect(userRequest?: AuthenticationParameters): void;
    /**
     * Use when you want to obtain an access_token for your API by redirecting the user's browser window to the authorization endpoint.
     * @param {@link (AuthenticationParameters:type)}
     *
     * To renew idToken, please pass clientId as the only scope in the Authentication Parameters
     */

Extrait de code décrivant le loginRedirect

On peut voir que la 2^ème fonction est mieux adaptée à l’utilisation dans un application, étant donné que l’on peut choisir l’authorization endpoint en dehors d’un browser.

Les détails du projet sont disponibles ici

Projet Hackathon

Le projet Hackathon nous a dès le début demandé de faire des choix technologiques entre :

• Le SDK de TBD, basé sur le Web5 et permettant de construire des web apps décentralisées.
• Veramo, un framework JavaScript facilitant l’utilisation de données cryptographiquement vérifiables.
• Universal Resolver, un outil permettant de résoudre des identifiants décentralisés (DID).
• DID Lint, un outil permettant de vérifier la syntaxe et structure d’un document DID.

Nous avons opté pour le SDK de TBD, car il nous permettait de construire une application web décentralisée et fournissait une documentation ainsi que des exemples d’utilisation.

J’ai également choisi de continuer à utiliser les DWN de TBD, bien qu’elles soient encore en développement et que nous avons eu des problèmes avec celles-ci. J’ai fait ce choix, car j’ai essayé d’implémenter ma propre DWN, mais après plus de 8h de travail je n’ai pas réussi à faire fonctionner la DWN. J’ai donc décidé de continuer à utiliser les DWN de TBD, car elles fonctionnaient la majorité du temps et nous permettaient de continuer à avancer dans le projet.

Les détails du projet sont disponibles ici