Pular para o conteúdo

Empacotar dependências do Alteryx

O PlaidCloud importa arquivos de fluxo de trabalho do Alteryx a partir do Document e usa caminhos do Document para dependências e artefatos. Você pode carregar arquivos no Document, pedir a um agente conectado por MCP que organize os arquivos para você ou conectar o Document diretamente a um armazenamento compartilhado, como OneDrive, Google Drive, SharePoint, S3, Azure Blob ou SFTP.

Escolha o local de origem que melhor se adapta à sua migração:

  • Carregue o pacote em uma conta de documentos.
  • Conecte um local de armazenamento compartilhado existente como uma conta de documentos.
  • Peça a um agente conectado por MCP que copie, mova, renomeie e organize arquivos já disponíveis no Document.

As conexões de armazenamento compartilhado podem reduzir a preparação da migração, porque a equipe pode manter os arquivos onde já colabora:

Para cada lote de migração, use uma estrutura de pastas como esta antes de importar:

workflow-package/
workflows/
macros/
inputs/
expected-outputs/
reports/
spatial/

Essa estrutura é opcional, mas facilita a revisão e a validação.

Coloque os arquivos de fluxo de trabalho e as macros em pastas previsíveis:

  • Coloque os arquivos .yxmd e .yxwz em workflows/.
  • Coloque os arquivos .yxmc em macros/.
  • Mantenha as macros aninhadas junto com o restante da biblioteca de macros.
  • Evite nomes de macro duplicados no mesmo pacote, a menos que tenham versões intencionais.

O PlaidCloud usa os arquivos de origem das macros para criar fluxos de trabalho de macro do PlaidCloud e conectar as chamadas de macro dos fluxos de trabalho convertidos.

Coloque os dados de entrada em inputs/:

  • Arquivos CSV, TSV, de largura fixa, JSON, XML, Excel, Access, YXDB, SAS, SPSS, Stata, Avro, Parquet e HDF.
  • Arquivos de consulta usados por fórmulas, substituição dinâmica, correspondência aproximada ou junções.
  • Pastas referenciadas pelas ferramentas Directory e Dynamic Input.
  • Arquivos ASCII planos do Alteryx: inclua o arquivo de layout .flat ao lado dos dados que ele descreve. As larguras das colunas existem apenas nesse arquivo, e a conversão o lê para construir a etapa; por isso, um arquivo de layout ausente ainda é convertido, mas o relatório de conversão nomeia o arquivo a ser carregado — forneça-o e importe o fluxo de trabalho novamente, em vez de apenas executá-lo de novo.

Quando o PlaidCloud importa o pacote, as etapas convertidas apontam para os locais do Document selecionados.

Coloque os arquivos espaciais em spatial/ e mantenha os arquivos auxiliares juntos:

  • Shapefiles: inclua .shp, .shx, .dbf e .prj.
  • Arquivos MapInfo: inclua .tab, .map, .id e .dat.
  • Inclua arquivos de projeção e camadas de consulta, quando presentes.
  • Mantenha KML, GeoJSON e outras entradas espaciais no mesmo pacote de dependências.

Não divida os arquivos auxiliares espaciais entre pastas. O PlaidCloud precisa do grupo completo para materializar a geometria corretamente.

Coloque os ativos de relatório em reports/:

  • Imagens usadas pelas ferramentas de composição de relatórios.
  • Entradas em PDF.
  • Fragmentos ou modelos HTML.
  • Camadas de mapa usadas pelos mapas dos relatórios.
  • Exemplos de relatórios gerados, quando a validação de artefatos for necessária.

As etapas de relatório convertidas criam artefatos do PlaidCloud que podem ser revisados no Document e no histórico de execuções do fluxo de trabalho.

Se algum fluxo de trabalho grava uma saída formatada em um modelo do Excel com estilos — as etapas Export to Excel e Export to Excel Sheets, que preservam a formatação — prepare essas pastas de trabalho de modelo na conta de documentos junto com as entradas. Coloque-as em uma pasta 04_Templates ao lado da pasta 03_Inputs em que você preparou os dados de origem, para que a etapa convertida possa ler o modelo que preenche.

Coloque as saídas esperadas em expected-outputs/:

  • Tabelas de saída confiáveis do Alteryx.
  • Relatórios, PDFs, mapas, imagens ou gráficos esperados.
  • Observações sobre a ordenação de linhas, a precisão numérica e o tratamento de datas aceitos.

As saídas esperadas são opcionais para a validação estrutural e são a melhor evidência para a validação de paridade de saída.

Para fluxos de trabalho de banco de dados, API e origens na nuvem, registre:

  1. O nome do sistema de origem.
  2. O tipo de conexão.
  3. Os nomes do banco de dados, esquema, tabela, endpoint ou bucket.
  4. O responsável pela credencial ou o nome do segredo.
  5. A data do instantâneo, quando a paridade de saída depende de uma origem em um ponto no tempo.

Use conexões ou credenciais do PlaidCloud para execuções de produção repetíveis.