Machine MDM à remonter dans le temps - 8.0

Introduction

La machine MDM à remonter dans le temps s'appuie sur le journal (rapports de mise à jour) créé à chaque fois qu'une mise à jour est effectuée sur un enregistrement MDM. Vous pouvez voir la machine à remonter dans le temps fonctionner lorsque vous naviguez vers le fichier de log précédent ou suivant dans le journal.

L'interface REST utilise les mêmes concepts, d'une manière plus ouverte aux programmes, facilement invoquée depuis un Job Talend.

Limitations connues

Toutes les opérations de navigation dans MDM ont une limitation connue : puisqu'un enregistrement créé n'est pas sauvegardé dans le journal, MDM ne peut parcourir les modifications lorsque l'un des événements est un événement de suppression, que ce soit de mise à la corbeille ou de suppression physique.

Cette limitation est similaire à celle de l'application Web “Journal”.

Appels REST pour la machine MDM à remonter dans le temps

Voici plusieurs exemples présentant comment effectuer des appels REST avec une machine MDM à remonter dans le temps :

• Obtenir la dernière version d'un enregistrement spécifique
• Obtenir la version d'un enregistrement spécifique à une date et heure données
• Scénario d'utilisation du paramètre “datetime” dans un appel REST
• Se déplacer dans l'historique des enregistrements
• Scénario d'utilisation du paramètre “swing”
• Utilisation des informations de métadonnées

Obtenir la dernière version d'un enregistrement spécifique

Pour obtenir la version d'un enregistrement spécifique, utilisez un appel REST au format suivant :

GET

Dans les URL ci-dessus, "container_name" et "type_name" doivent respectivement être remplacés par le nom du conteneur sur lequel effectuer la requête et le nom du type de l'entité. Le paramètre "id" doit être remplacé par l'ID de l'instance de l'enregistrement MDM à récupérer.

Pour un type d'entité ayant une clé composite, utilisez le séparateur "." (point) dans l'ordre de déclaration, dans le type de l'entité. Par exemple, si vous avez (age, name) comme clé, vous pouvez utiliser "10.John" comme “id” pour l'appel REST.

Par exemple, pour obtenir la dernière version de l'instance du Store d'ID 12 dans le conteneur TMDM-6892, utilisez l'appel REST comme suit :

http://localhost:8080/datamanager/services/data/TMDM-6892/Store/12

La réponse HTTP contient l'enregistrement XML à récupérer.

Tous les appels HTTP doivent être authentifiés à l'aide d'un utilisateur ou d'une utilisatrice MDM autorisé à accéder à ce type d'entité.

Obtenir la version d'un enregistrement spécifique à une date et heure données

Pour obtenir la version d'un enregistrement spécifique à une date et heure spécifiques, utilisez un appel REST aux formats suivants :

GET

Le paramètre facultatif "datetime" indique à la solution MDM où se positionner dans l'historique des enregistrements. Cette URL retourne l'enregistrement tel qu'il était au moment spécifié et non une modification survenue à ce moment "datetime".

Le paramètre "datetime" peut être une valeur de type Long (la différence, mesurée en millisecondes, entre l'heure actuelle et le 1er janvier 1970 UTC) ou une date et heure, comme précisé dans les spécifications XML.

Par exemple, si vous utilisez cet appel REST :

http://localhost:8080/talendmdm/services/rest/data/TMDM-6892/Store/12?datetime=2014-02-27T17:00:00,

l'instance du Store du conteneur TMDM-6892 d'ID 12 est retournée, dans son état du 27 février 2014.

Afin de mieux comprendre le paramètre “datetime”, consultez la section Scénario d'utilisation du paramètre “datetime” dans un appel REST.

Scénario d'utilisation du paramètre "datetime” dans un appel REST

Le scénario suivant vous explique plus en détail le paramètre “datetime” d'un appel REST.

Par exemple, un enregistrement a été créé avec le contenu suivant, à la date et à l'heure suivantes 2014-03-05T17:40:00 :

<entity>

<id>1</id>

<value>value1</value>

</entity>

Ensuite, à l'heure suivante 2014-03-05T17:45:00, l'enregistrement a été modifié pour la première fois comme suit :

<entity>

<id>1</id>

<value>value2</value>

</entity>

Enfin, à l'heure suivante 2014-03-05T17:50:00, l'enregistrement a été modifié à nouveau :

<entity>

<id>1</id>

<value>value3</value>

</entity>

Si vous appelez http://localhost:8080/talendmdm/services/rest/data/DataBrowser/Entity/1?datetime=2014-03-05T17:40:00, l'état de l'enregistrement à 17:40:00 est retourné, comme ci-dessous :

<entity>

<id>1</id>

<value>value1</value>

</entity>

Si vous appelez http://localhost:8080/talendmdm/services/rest/data/DataBrowser/Entity/1?datetime=2014-03-05T17:42:30, l'état de l'enregistrement à 17:42:30 est retourné. C'est le même état qu'à 17:40:00, comme ci-dessous :

<entity>

<id>1</id>

<value>value1</value>

</entity>

Notez que la modification suivante de l'enregistrement est survenue deux minutes et 30 secondes plus tard, à 17:45:00.

Se déplacer dans l'historique des enregistrements

Vous pouvez configurer votre position dans l'historique des enregistrements et utiliser le paramètre "swing" pour vous déplacer avant ou après ce point :

GET

La valeur du paramètre "swing" doit être l'une des suivantes :

• closest : comportement par défaut si le paramètre “swing” n'est pas spécifié.
• before : déplacement vers la version précédente de l'enregistrement.
• after : déplacement vers la version suivante de l'enregistrement.

Pour les options "before" et "after", s'il n'y a pas d'état défini (par exemple, si vous êtes au premier ou au dernier état), la solution MDM retourne un résultat, le même que pour "closest".

Voici un exemple :

http://localhost:8080/talendmdm/services/rest/data/TMDM-6892/Store/12?datetime=2014-02-27T17:00:00&swing=before

Si vous vous positionnez à la date à laquelle l'enregistrement a été créé et que vous utilisez "swing=before" dans un appel REST, le service ne retourne aucun contenu. Cela peut être interprété comme "before the record was created, nothing existed for the id" (avant la création de l'enregistrement, rien n'existait pour cet ID).

Scénario d'utilisation du paramètre “swing”

Ici, l'exemple de la section précédente est réutilisé, afin de vous faire comprendre le paramètre "datetime".

Le paramètre "swing" vous permet de vous déplacer dans les modifications des utilisateurs et des utilisatrices.

Pour l'appel REST http://localhost:8080/talendmdm/services/rest/data/DataBrowser/Entity/1?datetime=2014-03-05T17:42:30?swing=after, vous obtiendrez :

<entity>

<id>1</id>

<value>value2</value>

</entity>

Cela est retourné car la modification après 17:42:30 est celle ayant passé "value1" en "value2".

Pour l'appel REST http://localhost:8080/talendmdm/services/rest/data/DataBrowser/Entity/1?datetime=2014-03-05T17:42:30?swing=before, vous obtiendrez :

<entity>

<id>1</id>

<value>value1</value>

</entity>

Utilisation des informations de métadonnées

La solution MDM retourne également les métadonnées standard disponibles dans le résultat.

Par exemple, appeler GET sur l'URL suivante http://localhost:8080/talendmdm/services/rest/data/Customer/Customer/4b1f7d9c-4fda-4a39-bbab-d20506c0af10?datetime=139636124400 retourne les données suivantes :

<Customer xmlns:metadata="http://www.talend.com/mdm/metadata">

    <metadata:timestamp>1396361240263</metadata:timestamp>

    <metadata:task_id>4b1f7d9c-4fda-4a39-bbab-d20506c0af10</metadata:task_id>

    <MDM_Id>4b1f7d9c-4fda-4a39-bbab-d20506c0af10</MDM_Id>

    <source_id>99</source_id>

    <account_num>999</account_num>

    <lname>CarbonCarboneCarbone</lname>

    <fname>Cedric</fname>

    <address1>9rue PagËs</address1>

    <city>Suresnes</city>

    <state_province>FR</state_province>

    <postal_code>92150</postal_code>

    <country>France</country>

    <customer_region_id>1</customer_region_id>

    <marital_status>unknown</marital_status>

    <yearly_income>0</yearly_income>

    <gender>M</gender>

    <total_children>1</total_children>

    <num_children_at_home>1</num_children_at_home>

    <education>Master</education>

    <member_card>GOLD</member_card>

    <occupation>CTO</occupation>

    <houseowner>TRUE</houseowner>

    <fullname>CédricCarbone</fullname>

</Customer>

Vous pouvez constater que l'horodatage dans le document retourné et l'URL ne correspondent pas (1396361240263 != 1396361244000). Ce résultat est attendu, car l'heure de dernière modification est retournée. À t = 1396361244000, la dernière modification de l'enregistrement était t = 1396361240263.