Récupération des données de conteneur

Dans ce scénario, nous explorons la récupération des données. Nous considérons que les données sont endommagées lorsque le conteneur atteint un état non valide où il ne peut pas traiter d’autres actions utilisateur. Le résultat de l’état endommagé est que le conteneur est fermé de manière inattendue. Souvent, il s’agit d’un état temporaire et, à la réouverture, le conteneur peut se comporter comme prévu. Dans un cas où un conteneur ne parvient pas à se charger même après plusieurs nouvelles tentatives, nous offrons des API et des flux que vous pouvez utiliser pour récupérer vos données, comme décrit ci-dessous.

Comment l’infrastructure Fluid et Relais Azure Fluid enregistrent l’état

Infrastructure Fluid enregistre régulièrement des instantanés des données dans le conteneur, qui résument toutes les modifications apportées aux données jusqu’à ce point. Pendant le chargement normal de l’instantané le plus récent, toutes les modifications suivantes sont appliquées au-dessus de cet état.

Si la dernière capture instantanée ou les modifications suivantes sont endommagées, Fluid peut ne pas être en mesure de les charger normalement. Dans ce cas, Fluid offre une collection d’API pour afficher les versions d’instantané stockées et les charger en mode affichage seule sans aucune modification ultérieure appliquée. Cela permet aux données d’être extraites et éventuellement injectées dans un nouveau conteneur pour reprendre la collaboration.

API clientes Azure

API pour l’affichage et le chargement des versions de conteneur

AzureClient a les méthodes suivantes pour prendre en charge ce scénario :

Obtenir des versions de conteneur

getContainerVersions(id, options?)

Récupérez la liste des versions disponibles qui peuvent être chargées à partir de.

Parameters:

• id: ID de conteneur. Il s’agit du même ID que celui utilisé lors de l’appel getContainer.
• options?: Facultatif, objet options à spécifier :
  • maxCount: nombre maximal de versions à récupérer. S’il existe plus de versions disponibles que demandées, les versions les plus récentes sont récupérées. Valeur par défaut : 5

Returns: Promesse qui se résout en tableau d’objets qui représentent les versions disponibles (triées les plus récentes vers les plus anciennes). Les objets ont les propriétés suivantes :

• id: ID de version.
  • Remarque : cela diffère de l’ID de conteneur et fait référence spécifiquement à une version d’instantané plutôt qu’au conteneur.
• date: horodatage lorsque la version a été générée.

Afficher la version des conteneurs

viewContainerVersion(id, containerSchema, version, compatibilityMode)

Chargez une version spécifique d’un conteneur uniquement pour l’affichage. Toute version récupérée getContainerVersions peut être utilisée, mais pour récupérer des données endommagées, il est recommandé de commencer par la version la plus récente et de revenir en arrière pour trouver la version non endommagée la plus récente.

Le conteneur est chargé dans un état suspendu, ce qui signifie qu’il n’applique pas les modifications suivantes aux données qui se sont produites après la génération de cet instantané. Lorsqu’elles sont chargées dans cet état, les données du conteneur peuvent être lues, mais pas modifiées.

Parameters:

• id: ID de conteneur. Il s’agit du même ID que celui utilisé lors de l’appel getContainer.
• containerSchema: schéma de conteneur. Il s’agit du même schéma que celui utilisé lors de l’appel getContainer.
• version: objet de version référençant la version à charger. L’objet de version peut être récupéré via getContainerVersions.
• compatibilityMode: mode de compatibilité. Il s’agit du même mode de compatibilité que celui utilisé lors de l’appel getContainer.

Returns: Promesse qui se résout en objet représentant le conteneur chargé avec une propriété unique :

• container: objet conteneur. Il s’agit du même type d’objet que l’objet conteneur retourné par getContainer, mais est suspendu dans son état antérieur de la version sélectionnée.

Exemple

const azureClient = new AzureClient(/* ... */);
const versions = await azureClient.getContainerVersions(id);
// Since the versions are sorted in order from newest to oldest, versions[0] will attempt to load the most recent version.
// If the most recent version is corrupted, we could try again with versions[1] and so on to find the most-recent uncorrupted version.
const { container } = await azureClient.viewContainerVersion(id, containerSchema, versions[0], "2");

// We can now start reading the data from the container.
const someData = container.initialObjects.someSharedMap.get("hello");

// With the data extracted, we can inject it into a new uncorrupted container and attach it to start collaborating again.
const { container: newContainer } = await azureClient.createContainer(containerSchema, "2");
newContainer.initialObjects.someSharedMap.set("hello", someData);
const newId = await newContainer.attach();

Observations clés

Nous créons un conteneur

Nous ne récupérons pas (restauration) un conteneur existant. copyContainer nous donnera une nouvelle instance, avec des données copiées à partir du conteneur d’origine. Dans ce processus, l’ancien conteneur n’est pas supprimé.

Le nouveau conteneur est détaché

Le nouveau conteneur est initialement dans l’état detached. Nous pouvons continuer à travailler avec un conteneur détaché ou immédiatement attacher. Après avoir appelé attach, nous récupérerons l’ID de conteneur unique, représentant l’instance nouvellement créée.

Considérations relatives à la post-récupération

Lorsqu’il s’agit de créer des cas d’usage autour de scénarios de post-récupération, voici quelques considérations sur ce que l’application peut faire pour que ses collaborateurs distants travaillent à nouveau sur le même conteneur.

Si vous modélisez vos données d’application uniquement à l’aide de conteneurs fluides, le « lien » de communication est effectivement rompu lorsque le conteneur est endommagé. L’exemple réel similaire peut être un appel vidéo où l’auteur d’origine a partagé le lien avec les participants et que ce lien ne fonctionne plus. Dans cette perspective, une option consiste à limiter les autorisations de récupération à l’auteur d’origine, et à le laisser partager un nouveau lien de conteneur de la même façon qu’il a partagé le lien d’origine, après avoir récupéré la copie du conteneur d’origine.

Sinon, si vous utilisez une infrastructure fluide pour les données temporaires uniquement, vous pouvez toujours utiliser vos propres données sources de vérité et les services de prise en charge pour gérer des flux de travail de récupération plus autonomes. Par exemple, plusieurs clients peuvent lancer le processus de récupération jusqu’à ce que votre application ait une première copie récupérée. Votre application peut ensuite inviter tous les clients participants à basculer vers un nouveau conteneur. Cela peut être utile, car tout client actif peut débloquer le groupe participant afin de poursuivre la collaboration. L’un des éléments à prendre en considération ici est le coût de redondance.