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

L’infrastructure Fluid enregistre régulièrement l’état, appelé résumé, sans aucune action de sauvegarde explicite lancée par l’utilisateur. Ce flux de travail se produit toutes les minutes s’il n’y a pas d’activité utilisateur, ou plus tôt s’il y a plus de 1 000 opérations en attente. Chaque opération en attente se traduit approximativement en une action utilisateur individuelle (sélection, entrée de texte, etc.) qui n’a pas encore été résumée.

API clientes Azure

Nous avons ajouté les méthodes suivantes à AzureClient qui permettent aux développeurs de récupérer des données à partir de conteneurs endommagés.

getContainerVersions(ID, options)

getContainerVersions permet aux développeurs d’afficher les versions générées précédemment du conteneur.

copyContainer(ID, containerSchema)

copyContainer permet aux développeurs de générer un nouveau conteneur détaché d’une version spécifique d’un autre conteneur.

Exemple de plan de récupération

async function recoverDoc(
    client: AzureClient,
    orgContainerId: string,
    containerScema: ContainerSchema,
): Promise<string> {
    /* Collect doc versions */
    let versions: AzureContainerVersion[] = [];
    try {
        versions = await client.getContainerVersions(orgContainerId);
    } catch (e) {
        return Promise.reject(new Error("Unable to get container versions."));
    }

    for (const version of versions) {
        /* Versions are returned in chronological order.
        Attempt to copy doc from next available version */
        try {
            const { container: newContainer } = await client.copyContainer(
                orgContainerId,
                containerSchema,
                version,
            );
            return await newContainer.attach();
        } catch (e) {
            // Error. Keep going.
        }
    }

    return Promise.reject(new Error("Could not recreate document"));
}

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.