Como você implementa grupos de conversação para vários usuários usando sua própria instância dos aplicativos de usuário, mas enviando mensagens relacionadas à fila do agente de serviços? Algum bom exemplo desse tipo de implementação? Eu tinha imaginado que eu mesmo poderia definir o ID do grupo de conversação, garantindo que certos grupos de mensagens de vários usuários sejam relacionados, mas parece que esse valor vai ser gerado automaticamente como um UNIQUEIDENTIFIERS... Será que essa é mesmo a melhor maneira fazer isso?
Eu gostaria de ter certeza de capturar e bloquear mensagens relacionadas onde dois usuários "no mesmo time", por exemplo, estão fazendo lances no mesmo item juntos, para que a lógica do aplicativo do servidor possa processar adequadamente essas mensagens relacionadas juntas (basicamente apenas a primeira será aceito e o segundo será rejeitado até que a visualização do usuário possa ser atualizada para que ele saiba que o outro usuário já alterou o lance).
a direção do fluxo é dos usuários A, B, C enviando mensagens xml para a fila e, em seguida, um serviço de desenfileiramento que envia o xml para um serviço da Web externo. As mensagens que estamos enviando são mensagens xml estruturadas que modificarão pedidos em diferentes itens no serviço da Web externo após o desenfileiramento.
Obrigada!
Você não pode usar grupos de conversação para excluir instâncias de aplicativos, se é isso que está tentando fazer. Se a instância A precisar receber mensagens da fila apenas para a instância A e a instância B precisar receber mensagens apenas para a instância B, a instância A precisará usar a fila A e a instância B precisará usar a fila B . O grupo de conversação pode ser usado somente quando a instância A e a instância B podem processar quaisquer mensagens, mas você deseja excluí-las do processamento simultâneo de mensagens correlacionadas . Toda vez que vi alguém tentando pré-gerar IDs de grupos de conversação, a ideia sempre foi ruim.
Atualizar
O iniciador não pode controlar o grupo de conversação do destino (target). Mesmo que A e B estivessem no mesmo grupo de conversação no site iniciador, isso não significa que eles seriam os mesmos no site de destino, pois o grupo de conversação é um conceito local e não viaja com a mensagem. Se você deseja que as mensagens enviadas por A e B pertençam ao mesmo grupo de conversação no lado de destino, o diálogo deve ser iniciado na ordem 'inversa': o destino inicia o(s) diálogo(s) e os coloca em um único grupo de conversação, então o(s) alvo(s) começa(m) a enviar mensagens neste(s) diálogo(s). Assim, as conversas funcionam como um 'convite' para enviar mensagens, o 'alvo' lógico age como o 'iniciador' real.
Atualização nº 2.
é assim que funcionaria, em teoria: digamos que você tenha 10.000 produtos. Para fazer o padrão 'reverso', quando um usuário deseja participar do aplicativo, ele precisa 'participar'. Então, ele inicia uma conversa com o servidor e envia uma mensagem 'Quero participar' (ele chama isso de 'conversa 0 '). O servidor processa esta mensagem iniciando uma conversa com este novo usuário para cada produto. Agora o usuário tem 10.000 conversas nas quais pode enviar 'lances'. Para o produto A, ele usa a conversa 1, para o produto B, a conversa 2, etc. Quando o usuário B deseja entrar, ele também inicia uma nova conversa com o servidor e envia uma mensagem 'Quero entrar'. O servidor responde iniciando 10.000 conversas com esse novo usuário, novamente uma para cada produto, e garante que cada um esteja no grupo correspondente ao produto, de modo que a conversa do produto A com o usuário 1 esteja no mesmo grupo da conversa do produto a para o usuário 2.
Agora, obviamente, qualquer um descobrirá que esse esquema é falho: requer number_of_products X number_of_user chats, torna a adição e remoção de produtos uma dor de cabeça (deve manter todas essas conversas do usuário!) E assim por diante. Uma alternativa é multiplexar produtos por conversa. Digamos que o servidor inicie apenas 10 conversas com cada usuário e o usuário use a conversa correspondente ao último dígito do ID do produto (portanto, o produto 1 vai para a conversa 1, mas o produto 11 ou 101 também). Isso é mais viável, requer muito menos conversas e não requer gerenciamento especial de conversas quando produtos são adicionados ou removidos. Você pode considerar que é uma desvantagem que agora o servidor bloqueia não todas as mensagens do produto 1, mas também todas as mensagens do produto 11, todas do 101 etc, mas considere o seguinte: só importa se você tivermais threads de processamento no servidor do que o número de conversas por usuário . Se você tiver 5 threads, não importa se você bloqueou 1, 11, 101, ainda há mensagens para processar para os outros 4 threads. Só importaria se você tivesse 11 threads, já que o 11º thread não tem nada para processar.
Agora não estou defendendo a implantação exatamente disso, estou apenas apontando algumas possibilidades. Na maioria dos casos, o bloqueio de CG seria por usuário, não por produto, e adicionar essa dimensão extra de usar o bloqueio de CG para evitar problemas de simultaneidade em cada produto é um pouco heterodoxo.
E não esqueça que a única construção que garante a ordem no SSB é uma conversa. Portanto, se os usuários precisarem enviar lances para A na conversa 1, seguidos de lances para B na conversa 2, não há garantia de que o lance para A será processado depois que o lance para B for processado. A única garantia é que se o usuário 1 enviar dois lances para A, eles serão processados na ordem enviada.
Além disso, se dois usuários diferentes enviarem lances para o produto A, não há garantia da ordem de processamento desses lances. No entanto, se os lances do produto A terminarem no mesmo CG, existe a garantia de que apenas um 'processador thread' verá o lance do usuário 1 e o lance do usuário 2, mas tenha cuidado porque não há garantia de que os lances são apresentados no conjunto de resultados RECEIVE na ordem em que foram recebidos. A RECEIVE apenas garante que:
mas a ordem das conversas no resultado é basicamente aleatória (é orientada pela ordem do identificador de conversa, um GUID).
Antes que eu me esqueça: lembre-se de que também existe,
MOVE CONVERSATIONmas confiar no MOVE (em vez de iniciar conversas diretamente no CG correto) é muito, muito propenso a impasses.