Compartilhar via

Considerações sobre a automação autônoma do Office no Microsoft 365 para ambiente RPA autônomo

  • Artigo

Embora o Microsoft 365 para RPA autônoma forneça uma licença que permite a automação do Office sem nenhum usuário presente, todas as versões atuais do Office foram projetadas e testadas para serem executadas como produtos de usuário final em uma estação de trabalho do cliente com um usuário presente para interagir com a interface do aplicativo. Comportamentos inesperados resultantes do uso de aplicativos sem um usuário presente não são defeitos. Se você quiser executar o Office nesta configuração, deverá estar preparado para responder por esses comportamentos inesperados na lógica do aplicativo.

Este artigo descreve algumas das considerações sobre a automação autônoma do Office para ajudá-lo se você usar essa abordagem. No entanto, observe que o uso do Office nessa configuração é estritamente "AS IS" e deve responder por esses comportamentos inesperados. As informações fornecidas aqui não são exaustivas e não são garantidas para resolve todos os problemas para todos os clientes. Incentivamos você a testar sua solução completamente antes de implantar.

Problemas comuns na automação autônoma

Se você quiser usar o Office sem um usuário presente, esteja ciente das seguintes áreas em que o Office pode se comportar de forma diferente do esperado. Para que sua solução seja executada com êxito, ela deve resolver esses problemas e minimizar seus efeitos o máximo possível. Considere esses problemas com cuidado ao criar seu aplicativo.

Importante

Atualmente, a Microsoft não recomenda e não dá suporte à automação de aplicativos do Microsoft Office de qualquer aplicativo ou componente cliente autônomo e não interativo (incluindo ASP, ASP.NET, DCOM e NT Services), pois o Office pode exibir um comportamento instável e/ou um impasse quando o Office é executado nesse ambiente. Para obter mais informações, confira Considerações sobre a automação do Office no lado do servidor.

Elementos interativos da interface do usuário

Os aplicativos do Office supõem que estão sendo executados interativamente. Se ocorrer um erro inesperado ou se um parâmetro não especificado for necessário para concluir uma função, o Office será projetado para solicitar ao usuário uma caixa de diálogo que pergunte ao usuário como ele deseja proceder. Na automação autônoma, isso pode fazer com que o aplicativo apareça como "travado" à medida que o aplicativo para até receber essa entrada. Se você estiver automatizando o Office por meio de suas APIs públicas, poderá suprimir muitos desses alertas configurando propriedades como Application.DisplayAlerts e Application.AutomationSecurity adequadamente. Seu código deve ser projetado para identificar e processar alertas de bloqueio a qualquer momento.

Identidade do usuário

Os aplicativos do Office exigem uma identidade de usuário quando os aplicativos são executados, mesmo quando o aplicativo é iniciado por meio da automação. Essa identidade de usuário pode causar qualquer um ou todos os seguintes:

  • A presença de interface do usuário de entrada adicional que deve ser tratada.
  • Arquivos que não podem ser abertos e/ou editados com base em permissões de acesso por usuário.
  • Alterações inesperadas nos metadados do arquivo (por exemplo, determinadas propriedades de arquivo serão atualizadas com base na identidade do usuário da instância de aplicativo automatizada).

Várias abordagens podem ajudar a atenuar esses problemas; por exemplo, executando o Inspetor de Documentos para remover metadados. Considere se essas abordagens são apropriadas com base em seu cenário.

Segurança do lado do servidor

Ao executar o conteúdo de arquivo arbitrário sem vigilância e processamento do Office, não há proteções adicionais específicas nesse ambiente para impedir que macros armazenadas nesses arquivos sejam carregadas e executadas. O Office não protege você de executar macros involuntariamente do código ou de iniciar outro servidor que possa executar macros. Você pode usar propriedades como Application.AutomationSecurity para mitigar esse risco, mas deve garantir que você esteja carregando apenas conteúdo confiável.

Além disso, o Office usa muitos componentes (como MAPI Simples, WinInet e MSDAIPP) que podem armazenar em cache informações de autenticação do cliente para acelerar o processamento. Quando o Office está sendo automatizado no lado do servidor e processando vários arquivos, se as informações de autenticação tiverem sido armazenadas em cache para essa sessão, um cliente poderá usar as credenciais armazenadas em cache de outro cliente. Portanto, o cliente pode obter permissões de acesso não concedidas se passando por outros usuários.

Alterações na interface do usuário

Os elementos da interface do usuário no Office são em grande parte estáveis, mas o local específico de qualquer elemento da interface do usuário não é garantido e pode ser alterado à medida que o design do produto evolui para incorporar comentários do usuário e atender às necessidades do cliente. A lógica de qualquer automação deve ser responsável por isso. Essas alterações podem resultar em alterações de nomenclatura de botão ou de guia de grupo, movimentação de comandos entre guias, adição de novas guias ou remoção de comandos em alinhamento com nossas políticas de preterição de recursos. Essas alterações podem ocorrer na interface do usuário, bem como nas informações de acessibilidade fornecidas pelo aplicativo, pois essas informações são modificadas para melhorar a usabilidade e a conta para comentários contínuos do cliente e podem ser distribuídas para diferentes usuários em momentos diferentes.

Mesmo sem alterações no produto, as diferenças entre ambientes do sistema (como tamanho da tela/resolução/DPI) podem resultar em alterações no local dos itens na tela. Qualquer abordagem que dependa de coordenadas de tela para simular a entrada do usuário deve considerar essas alterações e se adaptar de acordo.

Threading único

Os aplicativos do Office são aplicativos não reentrantes baseados em STA que são projetados para fornecer funcionalidades diversas, mas intensivas em recursos para um único cliente. Os aplicativos usam recursos globais, como arquivos mapeados de memória, suplementos ou modelos globais e servidores de automação compartilhada. Isso pode limitar o número de instâncias que podem ser executadas simultaneamente e podem levar a condições de corrida se os aplicativos estiverem configurados em um ambiente multicliente. Se você planeja executar mais de uma instância de qualquer aplicativo do Office, deverá planejar isolá-los no nível da máquina virtual para garantir a estabilidade da solução resultante.

Resiliência e estabilidade

Mesmo com as considerações acima, se os aplicativos forem automatizados de maneiras que simulam a entrada do usuário ou para comprimentos de sessão que excedem drasticamente o uso interativo, eles podem encontrar problemas que não estão presentes quando executados interativamente. As soluções que utilizam o Office nesse contexto devem criar mecanismos proativamente para monitorar o estado do aplicativo e reiniciá-los (e/ou a máquina virtual na qual estão em execução) se/conforme necessário.

Alternativas Sugeridas

A Microsoft recomenda fortemente algumas alternativas que não exigem que o Office seja instalado e execute o lado do servidor e que possam executar tarefas comuns de forma mais eficiente e rápida do que a automação nesta configuração. Antes de envolver o Office como um componente do lado do servidor em seu projeto, considere alternativas.

Microsoft Graph

O Microsoft API do Graph fornece acesso aos serviços, dados e inteligência que estão disponíveis para usuários e soluções como parte da nuvem da Microsoft, incluindo muitos serviços que dão suporte às necessidades de automação autônoma: acesso ao email/calendário/contatos/arquivos dos usuários, conversão de documentos, cálculo da pasta de trabalho do Excel e muito mais. Esses serviços são projetados para uso autônomo e acesso em alta escala e utilizam uma sintaxe de API RESTful padrão. Para obter mais informações sobre o Microsoft Graph e como usá-lo para trabalhar com os dados dos usuários, visite o seguinte:

Abrir formatos de arquivo XML

Muitas tarefas de automação envolvem a criação ou edição de documentos. O Office dá suporte a formatos de arquivo Open XML que permitem que os desenvolvedores criem, editem, leiam e transformem conteúdo de arquivo usando tecnologias XML e ZIP padrão, definidas no ISO 29500 International Standard. Esses formatos de arquivo podem ser manipulados por meio de ferramentas ZIP/XML, incluindo o namespace System.IO.Package.IO no Microsoft .NET 3.x Framework. A edição direta dos formatos de arquivo é o método recomendado e compatível para lidar com alterações nos arquivos do Office de um serviço.

A Microsoft fornece um SDK para manipular formatos de arquivo Open XML do .NET 3.x Framework. Para obter mais informações sobre o SDK e como usar o SDK para criar ou editar arquivos XML abertos, visite o seguinte: