Servicio de Azure Fluid Relay personalizado
Aunque probablemente prefiera usar nuestro servicio hospedado gratuito, hay situaciones en las que resulta beneficioso usar su propio servicio De Azure Fluid Relay para la aplicación Live Share.
Requisitos previos
- Cree un panel lateral de la reunión y una extensión de reunión de la aplicación de fase, como se muestra en el tutorial de rodillos de dados.
- Actualice el manifiesto de la aplicación para incluir todos los permisos necesarios.
- Aprovisione un servicio de Azure Fluid Relay como se describe en este tutorial.
Conexión al servicio Azure Fluid Relay
Al llamar a inicializando LiveShareClient
, puede definir su propio AzureConnectionConfig
. Live Share asocia los contenedores que crea con reuniones, pero debe implementar la ITokenProvider
interfaz para firmar tokens para los contenedores. En este ejemplo se explica el de AzureFunctionTokenProvider
Azure, que usa una función en la nube de Azure para solicitar un token de acceso desde un 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
¿Por qué usar un servicio de Azure Fluid Relay personalizado?
Considere la posibilidad de usar una conexión de servicio AFR personalizada si:
- Requerir almacenamiento de datos en contenedores Fluid más allá de la duración de una reunión.
- Transmitir datos confidenciales a través del servicio que requiere una directiva de seguridad personalizada.
- Desarrolle características a través de Fluid Framework para su aplicación fuera de Teams.
¿Por qué usar Live Share con el servicio personalizado?
Azure Fluid Relay está diseñado para trabajar con cualquier aplicación basada en web, lo que significa que funciona con Microsoft Teams o sin él. Esto plantea una pregunta importante: si creo mi propio servicio de Azure Fluid Relay, ¿todavía necesito Live Share?
Live Share tiene características que son beneficiosas para escenarios comunes de reuniones que aumentan otras características de la aplicación, entre las que se incluyen:
Asignación de contenedores
El LiveShareClient
objeto es @microsoft/live-share
responsable de asignar un identificador de reunión único a los contenedores de Fluid, lo que garantiza que todos los participantes de la reunión se unan al mismo contenedor. Como parte de este proceso, el cliente intenta conectarse a un containerId
asignado a la reunión que ya existe. Si no existe, se usa para crear un contenedor mediante AzureConnectionConfig
y, a continuación, AzureClient
retransmitirlo a otros participantes de la containerId
reunión.
Si la aplicación ya tiene un mecanismo para crear contenedores de Fluid y compartirlos con otros miembros, como insertando en la containerId
dirección URL compartida en la fase de reunión, puede que no sea necesario para la aplicación.
Comprobación de roles y objetos activos
Las estructuras de datos en directo de Live Share, como LivePresence
, LiveState
, y LiveEvent
están adaptadas a la colaboración en reuniones y, por tanto, no se admiten en contenedores Fluid que se usan fuera de Microsoft Teams. Características como la verificación de roles ayudan a la aplicación a alinearse con las expectativas de nuestros usuarios.
Nota:
Como ventaja adicional, los objetos activos también presentan latencias de mensajes más rápidas en comparación con las estructuras de datos fluid tradicionales.
Para obtener más información, consulte la página de funcionalidades principales .
Uso de Live Share sin LiveShareClient
Todavía puede usar Live Share aunque no quiera usar la clase para el LiveShareClient
servicio Azure Fluid Relay personalizado. Esto resulta útil si desea controlar cuándo se crea un contenedor o cómo se comparte con los participantes de la reunión.
A continuación se muestra un ejemplo de cómo puede hacerlo en la aplicación:
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
Como alternativa, puede usar o invalidar .AzureLiveShareHost
Esto le permite obtener nombres y roles para mostrar de usuario personalizados de , en lugar de AzureAudience
a través de 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
Muchas API de Live Share dependen de una API global de marca de tiempo, que permite LiveDataObject
a los objetos determinar el orden de los mensajes remotos. Si usa estructuras de datos que dependen de la TimestampProvider
clase , debe usar desde LiveShareHost
la teams-js
biblioteca o invalidar la getTimestamp()
función en AzureLiveShareHost
con un valor devuelto por el servidor.