Partilhar via

Serviço personalizado de Reencaminhamento de Fluidos do Azure

  • Artigo

Embora prefira utilizar o nosso serviço alojado gratuito, existem situações em que é vantajoso utilizar o seu próprio serviço Azure Fluid Relay para a sua aplicação Live Share.

Pré-requisitos

  1. Crie um painel lateral da reunião e a extensão de reunião da aplicação de palco, conforme mostrado no tutorial de rolos de dados.
  2. Atualize o manifesto da aplicação para incluir todas as permissões necessárias.
  3. Aprovisione um serviço de Reencaminhamento de Fluidos do Azure, conforme descrito neste tutorial.

Ligar ao serviço Azure Fluid Relay

Ao efetuar a inicialização LiveShareClientdo , pode definir o seu próprio AzureConnectionConfig. O Live Share associa contentores que cria com reuniões, mas tem de implementar a ITokenProvider interface para assinar tokens para os seus contentores. Este exemplo explica o do Azure, que utiliza uma função da cloud do AzureFunctionTokenProviderAzure para pedir um token de acesso a partir de um servidor.

import { LiveShareClient, LivePresence } from "@microsoft/live-share";
import { LiveShareHost } from "@microsoft/teams-js";
import { SharedMap } from "fluid-framework";
import { AzureFunctionTokenProvider } from "@fluidframework/azure-client";

// Define a custom connection for your app
const options = {
  connection: {
    tenantId: "MY_TENANT_ID",
    tokenProvider: new AzureFunctionTokenProvider(
      "MY_SERVICE_ENDPOINT_URL" + "/api/GetAzureToken",
      { userId: "userId", userName: "Test User" }
    ),
    endpoint: "MY_SERVICE_ENDPOINT_URL",
    type: "remote",
  },
};
// Join the Fluid container
const host = LiveShareHost.create();
const liveShare = new LiveShareClient(host, options);
const schema = {
  initialObjects: {
    presence: LivePresence,
    ticTacToePositions: SharedMap,
  },
};
const { container } = await liveShare.joinContainer(schema);

// ... ready to start app sync logic

Porquê utilizar um serviço personalizado do Azure Fluid Relay?

Considere utilizar uma ligação de serviço AFR personalizada se:

  • Exigir armazenamento de dados em contentores fluidos para além da duração de uma reunião.
  • Transmita dados confidenciais através do serviço que requer uma política de segurança personalizada.
  • Desenvolva funcionalidades através do Fluid Framework para a sua aplicação fora do Teams.

Porquê utilizar o Live Share com o seu serviço personalizado?

O Azure Fluid Relay foi concebido para funcionar com qualquer aplicação baseada na Web, o que significa que funciona com ou sem o Microsoft Teams. Isto levanta uma questão importante: se criar o meu próprio serviço de Reencaminhamento de Fluidos do Azure, ainda preciso do Live Share?

O Live Share tem funcionalidades que são benéficas para cenários de reunião comuns que aumentam outras funcionalidades na sua aplicação, incluindo:

Mapeamento de contentores

O LiveShareClient in @microsoft/live-share é responsável por mapear um identificador de reunião exclusivo para os seus contentores fluidos, o que garante que todos os participantes da reunião se juntem ao mesmo contentor. Como parte deste processo, o cliente tenta ligar-se a uma containerId reunião mapeada que já existe. Se um não existir, o AzureClient é utilizado para criar um contentor com o seu AzureConnectionConfig e, em seguida, reencaminhar o containerId para outros participantes da reunião.

Se a sua aplicação já tiver um mecanismo para criar contentores de Fluidos e partilhá-los com outros membros, por exemplo, ao inserir o containerId no URL partilhado na fase da reunião, poderá não ser necessário para a sua aplicação.

Objetos dinâmicos e verificação de função

As estruturas de dados dinâmicas do Live Share, como LivePresence, LiveStatee LiveEvent são adaptadas à colaboração em reuniões, pelo que não são suportadas em contentores de Fluidos utilizados fora do Microsoft Teams. Funcionalidades como a verificação de funções ajudam a sua aplicação a alinhar-se com as expetativas dos nossos utilizadores.

Observação

Como benefício adicional, os objetos dinâmicos também apresentam latências de mensagens mais rápidas em comparação com as estruturas de dados fluidas tradicionais.

Para obter mais informações, veja a página principais capacidades .

Utilizar o Live Share sem LiveShareClient

Pode continuar a utilizar o Live Share mesmo que não queira utilizar a classe para o LiveShareClient serviço Azure Fluid Relay personalizado. Isto é útil se quiser controlar quando um contentor é criado ou como é partilhado com os participantes da reunião.

Segue-se um exemplo de como pode fazê-lo na sua aplicação:

import {
  LiveShareClient,
  LivePresence,
  getLiveShareContainerSchemaProxy,
} from "@microsoft/live-share";
import { SharedMap } from "fluid-framework";
import {
  AzureFunctionTokenProvider,
  AzureClient,
} from "@fluidframework/azure-client";
import { LiveShareHost } from "@microsoft/teams-js";

// Define a custom connection for your app
const options = {
  connection: {
    tenantId: "MY_TENANT_ID",
    tokenProvider: new AzureFunctionTokenProvider(
      "MY_SERVICE_ENDPOINT_URL" + "/api/GetAzureToken",
      { userId: "userId", userName: "Test User" }
    ),
    endpoint: "MY_SERVICE_ENDPOINT_URL",
    type: "remote",
  },
};
// Initialize your AzureClient instance
const client = new AzureClient(options);
// Define your Fluid schema
const schema = {
  initialObjects: {
    presence: LivePresence,
    ticTacToePositions: SharedMap,
  },
};
// Create your host
const host = LiveShareHost.create();
// Create the LiveShareRuntime, which is needed for `LiveDataObject` instances to work
const runtime = new LiveShareRuntime(this._host);
// Inject the LiveShareRuntime dependency into the ContainerSchema
const injectedSchema = getLiveShareContainerSchemaProxy(
    schema,
    runtime,
);
// Create (or get) your container
const { container } = await client.createContainer(injectedSchema);

// ... ready to start app sync logic

Em alternativa, pode utilizar ou substituir o AzureLiveShareHost. Isto permite-lhe obter nomes e funções de apresentação de utilizadores personalizados a partir do seu AzureAudience, em vez de através do Microsoft Teams.

import {
  LiveShareClient,
  LivePresence,
  AzureLiveShareHost,
  getLiveShareContainerSchemaProxy,
} from "@microsoft/live-share";
import { SharedMap } from "fluid-framework";
import {
  AzureFunctionTokenProvider,
  AzureClient,
} from "@fluidframework/azure-client";

// Define a custom connection for your app
const options = {
  connection: {
    tenantId: "MY_TENANT_ID",
    tokenProvider: new AzureFunctionTokenProvider(
      "MY_SERVICE_ENDPOINT_URL" + "/api/GetAzureToken",
      { userId: "userId", userName: "Test User" }
    ),
    endpoint: "MY_SERVICE_ENDPOINT_URL",
    type: "remote",
  },
};
// Initialize your AzureClient instance
const client = new AzureClient(options);
// Define your Fluid schema
const schema = {
  initialObjects: {
    presence: LivePresence,
    ticTacToePositions: SharedMap,
  },
};
// Create your AzureLiveShareHost
const host = AzureLiveShareHost.create();
// Create the LiveShareRuntime, which is needed for `LiveDataObject` instances to work
const runtime = new LiveShareRuntime(this._host);
// Inject the LiveShareRuntime dependency into the ContainerSchema
const injectedSchema = getLiveShareContainerSchemaProxy(
    schema,
    runtime,
);
// Create (or get) your container
const { container } = await client.createContainer(injectedSchema);
// Set AzureAudience into the AzureLiveShareHost
host.setAudience(services.audience);

// ... ready to start app sync logic

Muitas APIs do Live Share dependem de uma API de carimbo de data/hora global, que permite LiveDataObject que os objetos determinem a ordem das mensagens remotas. Se estiver a utilizar estruturas de dados que dependem da TimestampProvider classe , tem de utilizar a LiveShareHost da teams-js biblioteca ou substituir a getTimestamp() função com AzureLiveShareHost um valor devolvido pelo servidor.

Confira também