Migrar fluxos de trabalho Alteryx

O PlaidCloud converte fluxos de trabalho, aplicações analíticas e macros do Alteryx em fluxos de trabalho avançados que podem ser revistos, agendados, parametrizados e executados no PlaidCloud. O importador preserva o grafo do fluxo de trabalho, carrega os ficheiros referenciados para Document, cria fluxos de trabalho de macro quando necessário e mapeia as ferramentas para passos de fluxo de trabalho nativos ou para executores de tarefas geridos.

Utilize este guia quando estiver a mover para o PlaidCloud um único fluxo de trabalho, um grupo de fluxos de trabalho relacionados ou um portefólio Alteryx de maior dimensão.

O que o PlaidCloud cria

O PlaidCloud cria um fluxo de trabalho avançado executável a partir da conceção do Alteryx:

As ferramentas do fluxo de trabalho passam a ser passos de fluxo de trabalho do PlaidCloud, preservando-se as relações originais a montante e a jusante.
As macros do Alteryx passam a ser fluxos de trabalho de macro do PlaidCloud, com entradas e saídas de macro explícitas.
As perguntas das aplicações analíticas passam a ser variáveis de fluxo de trabalho controladas, que os utilizadores podem definir antes de uma execução.
Os ficheiros de entrada, os ficheiros de saída, os ficheiros auxiliares espaciais, as imagens, os PDF e os artefactos gerados são guardados em Document no caminho selecionado durante a importação.
Os pipelines de Assisted Modeling (machine learning) passam a ser passos de fluxo de trabalho nativos ML Train e ML Score.
As operações avançadas, como a correspondência difusa, o processamento espacial, a extração de PDF, o OCR, o NLP e a criação de relatórios, são executadas através dos executores de tarefas geridos do PlaidCloud quando uma operação SQL ou de fluxo de trabalho nativa não é a mais adequada.
As caixas de comentários e os Tool Containers chegam à área de desenho do fluxo de trabalho como notas, caixas de destaque e grupos. Explicam o fluxo de trabalho convertido exatamente como explicavam o original e não acrescentam trabalho em tempo de execução.
O Browse e outros objetos que servem apenas de visualizador passam a fazer parte da área de desenho em vez de passos, pelo que não acrescentam trabalho em tempo de execução — a tabela de saída de cada passo já está disponível para consulta.

Antes de começar

Reúna os ficheiros do fluxo de trabalho e as dependências antes de importar:

Inclua os ficheiros de fluxo de trabalho, aplicação e macro do Alteryx: .yxmd, .yxwz e .yxmc.
Inclua os ficheiros de dados de entrada, como CSV, Excel, Access, YXDB, XML, JSON e extrações de bases de dados.
Inclua em conjunto os ficheiros auxiliares espaciais. Por exemplo, mantenha os grupos de shapefiles e os ficheiros MapInfo na mesma pasta.
Inclua os recursos dos relatórios, como imagens, PDF, camadas de mapas e modelos.
Escolha o projeto do PlaidCloud onde os fluxos de trabalho convertidos devem ser criados.
Escolha a conta de documentos e a pasta para onde o PlaidCloud deve carregar os ficheiros importados.
Decida se esta migração exige apenas validação estrutural ou validação da paridade das saídas.

Importar um fluxo de trabalho

Abra o projeto de destino no PlaidCloud.
Abra Ferramentas → Importar fluxo de trabalho Alteryx.
Escolha o projeto de destino e selecione o ficheiro .yxmd, .yxwz ou .yxmc a importar.
Opcionalmente, defina prefixos para os nomes dos fluxos de trabalho, dos passos e das tabelas. Os nomes das tabelas já têm como prefixo o nome do próprio fluxo de trabalho — consulte Nomes de tabelas num fluxo de trabalho convertido mais abaixo.
Escolha a conta de documentos e a pasta onde os ficheiros importados devem ser guardados.
Adicione quaisquer ficheiros ou pastas referenciados de que o fluxo de trabalho precise em tempo de execução.
Inicie a importação.
Numa importação limpa, a janela fecha-se automaticamente e abre o fluxo de trabalho avançado gerado — não precisa de a fechar manualmente. Tudo o que mereça uma segunda análise surge depois sob a forma de notificação, em vez de atrasar a importação.
Se o fluxo de trabalho tiver um passo que não foi convertido, um ficheiro que lê estiver em falta ou outro problema exigir atenção, a janela permanece aberta e mostra o relatório de conversão, para que o possa rever antes de continuar.

Quando algum passo exige atenção — uma ferramenta descartada ou não convertida — a janela de importação substitui o formulário por um relatório de conversão: um resumo de quantos passos foram mapeados com confiança alta e de quantos precisam de revisão, e uma tabela dos passos de menor confiança ou com ressalvas, que indica o nome, a operação, a confiança e as notas de cada passo. Utilize-o para ir diretamente aos passos que merecem verificação antes de executar o fluxo de trabalho; cada um desses passos também inclui a mesma nota de confiança no respetivo memorando do passo, na área de desenho.

O PlaidCloud guarda as dependências importadas na localização de Document selecionada durante a importação. Os passos convertidos referenciam depois esses caminhos de Document, pelo que o fluxo de trabalho pode ser executado repetidamente sem depender de um sistema de ficheiros de secretária.

Ficheiros em falta

A importação já não falha só porque falta um ficheiro lido pelo fluxo de trabalho — por exemplo, um caminho de partilha de rede que nunca foi carregado. O fluxo de trabalho é convertido na mesma e o relatório de conversão enumera cada ficheiro em falta com:

O caminho de Document para onde o carregar.
O caminho original do Alteryx de onde era lido.
Quaisquer folhas que o fluxo de trabalho espera dele.
As ferramentas do Alteryx que o leem.

Na maioria dos ficheiros, basta carregá-lo para o caminho indicado no relatório e executar novamente o fluxo de trabalho — não é necessário importar de novo. Alguns tipos de ficheiros em falta são lidos no momento da conversão e não em tempo de execução, pelo que o relatório indica que deve importar o fluxo de trabalho novamente depois de o ficheiro estar no sítio: um ficheiro de esquema ASCII de largura fixa do Alteryx, uma entrada com carateres universais, um modelo de Dynamic Input e uma origem de mudança de nome FirstRow pertencem a este grupo.

Um ficheiro lido apenas por uma ferramenta dentro de um Tool Container desligado nunca aparece nesta lista e nunca é copiado para Document. Essas ferramentas nem sequer são importadas — consulte Comentários e Tool Containers na área de desenho — pelo que o fluxo de trabalho convertido não tem nenhum passo que precise do ficheiro. Ligue o contentor no Alteryx, ou importe com a opção que traz as ferramentas de um contentor desligado como passos normais, para também importar o ficheiro.

Outros problemas num fluxo de trabalho — uma macro ou um esquema de ficheiro simples que o PlaidCloud não consegue ler, um ficheiro que já existe no caminho de destino com conteúdo diferente, uma ferramenta que não pode ser convertida — assinalam esse passo com um aviso em vez de fazerem falhar toda a importação, pelo que o resto do fluxo de trabalho é importado na mesma.

Quando a importação é recusada

Se o ficheiro que carrega não puder ser convertido de todo, a importação é recusada de imediato em vez de produzir um resultado parcial, e o erro indica o que fazer. Isto acontece quando o ficheiro não é um fluxo de trabalho do Alteryx; quando é um pacote do Alteryx (.yxzp), caso em que deve exportar o respetivo fluxo de trabalho .yxmd a partir do Alteryx Designer e carregá-lo com os ficheiros que utiliza; quando o ficheiro do fluxo de trabalho está em falta ou não tem permissão para o ler; ou quando um nome de tabela de que precisa colide de uma forma que a importação não consegue resolver sozinha.

Se o próprio conversor encontrar um defeito interno ao trabalhar no seu fluxo de trabalho, a importação é recusada com uma mensagem que identifica o defeito: “PlaidCloud could not convert this workflow because of a converter defect (<error>). It has been logged for the PlaidCloud team; include the request ID when you contact support.” Nesse caso não há nada de errado com o seu ficheiro — contacte o suporte com o ID do pedido indicado na mensagem, para que a equipa possa analisar a falha registada.

Nomes de tabelas num fluxo de trabalho convertido

Cada passo convertido escreve a sua própria tabela, com o nome da ferramenta do Alteryx de que provém — tool_4_out para a Tool 4. O Alteryx numera as ferramentas por ficheiro, pelo que esses nomes se repetem entre fluxos de trabalho, e um projeto do PlaidCloud é um único espaço de nomes de tabelas. Por isso, cada importação coloca como prefixo das suas tabelas o nome do próprio fluxo de trabalho, o que dá 03_measure_the_quality_of_data_tool_4_out. É isto que permite que uma pasta inteira de fluxos de trabalho do Alteryx seja importada para um único projeto sem que uns substituam os resultados dos outros.

O nome do fluxo de trabalho é a única coisa que distingue duas importações. Dois ficheiros com o mesmo nome — ou com nomes que diferem apenas na pontuação ou nos espaços, como Sales Report e Sales-Report — produzem na mesma o mesmo prefixo, tal como um ficheiro que não tem nome. Defina o seu próprio prefixo do nome da tabela ao importá-los, ou importe-os para projetos separados.

Essas importações já não se sobrepõem: uma importação que peça um nome de tabela que o projeto já possui obtém a sua própria tabela, com o sufixo -duplicate- no nome, e os respetivos passos utilizam-na. Cada importação mantém os seus resultados, mas os nomes das tabelas da segunda são mais difíceis de ler — por isso, continua a valer a pena definir um prefixo próprio.

Importar o mesmo fluxo de trabalho duas vezes, o que acontece quando uma primeira importação precisa de ser corrigida, funciona da mesma forma: a segunda importação obtém o seu próprio conjunto de tabelas em vez de substituir o primeiro. Elimine o fluxo de trabalho e as tabelas da importação anterior quando estiver satisfeito com a nova.

Defina o seu próprio prefixo do nome da tabela durante a importação para substituir o predefinido, ou deixe-o vazio para recuperar os nomes simples tool_4_out. Nada depende destes nomes além dos próprios passos convertidos, pelo que mudar o nome de uma tabela depois implica reapontar os passos que a leem.

Saídas escritas em Parquet

Uma ferramenta Output Data que escreve .parquet ou .avro é convertida num passo de exportação para esse formato. Uma que escreve .yxdb, .hyper ou .dbf é escrita em Parquet. Numa saída .yxdb, o ficheiro é um .parquet com o mesmo nome, na mesma pasta.

Um fluxo de trabalho convertido que lê esse ficheiro .yxdb lê automaticamente o .parquet: o passo Importar Alteryx YXDB recorre ao .parquet com o mesmo nome quando o .yxdb não existe e mostra um aviso a indicá-lo.

Comentários e Tool Containers na área de desenho

As notas e os grupos que um autor do Alteryx desenhou em torno do seu trabalho acompanham-no:

Uma caixa de comentário com texto passa a ser uma nota na área de desenho, na posição e com a dimensão com que foi desenhada.
Uma caixa de comentário desenhada como um contorno vazio em torno de um conjunto de ferramentas passa a ser uma caixa de destaque, que é a função que desempenhava no Alteryx.
Uma caixa de comentário que apresenta um documento ligado mantém a ligação como texto.
Um Tool Container passa a ser um grupo que contém os passos que foram desenhados no seu interior, mantendo a legenda, se estava fechado e se estava desligado. Os contentores aninhados passam a grupos aninhados, e um passo dentro de ambos pertence a ambos.

Mova, edite, mude a cor ou elimine qualquer um deles da mesma forma que faria com um que tivesse desenhado.

Há duas coisas que se comportam de forma diferente do original:

As ferramentas de um Tool Container desligado não são importadas de todo. O Alteryx também não as executa, pelo que importá-las colocaria no fluxo de trabalho passos que nunca fazem nada. O próprio contentor é importado na mesma, como uma caixa de destaque com a sua legenda, para que possa ver o que lá estava. Para importar as respetivas ferramentas, ligue o contentor no Alteryx e importe novamente. (A importação através da API ou de um agente de IA também aceita uma opção para importar as ferramentas de um contentor desativado como passos normais e executáveis — útil para fluxos de trabalho de exemplo que são distribuídos com tudo desligado.)
As cores das caixas não são transportadas. A área de desenho oferece um conjunto fixo de seis cores e as caixas do Alteryx são quase sempre brancas ou cinzentas, pelo que todas chegariam com o mesmo tom. Chegam com a cor predefinida da área de desenho; defina a cor pretendida a partir do menu de contexto.

O texto de uma nota é agora apresentado num cinzento neutro. Anteriormente chegava em âmbar/laranja sobre a área de desenho escura — uma cor que se lê como um aviso, mesmo num comentário banal transportado diretamente do Alteryx.

Um Tool Container que acabe por não conter nenhum passo — porque estava desligado ou porque só continha comentários — continua a aparecer, como uma caixa de destaque com a sua legenda, em vez de desaparecer da área de desenho.

Um fluxo de trabalho que seja apenas comentários — uma página de documentação sem ferramentas — é importado como uma área de desenho com esses comentários e indica que foi convertido sem nenhum passo executável. Esse é o resultado correto, não uma falha: não havia nada para executar.

Control Containers

Um Control Container do Alteryx executa as ferramentas que contém apenas quando o fluxo ligado à sua entrada Control transporta registos. Essa condição é transportada com o contentor, e não apenas o contorno do contentor:

O contentor passa a ser um grupo na área de desenho como qualquer outro, mantendo a legenda e o conteúdo.
Todos os passos que estavam no seu interior são importados já configurados para serem executados apenas quando os dados condicionados têm linhas e para serem ignorados quando não as têm. Os passos em contentores aninhados no seu interior ficam condicionados da mesma forma. Não precisa de ligar a condição por si.
Um Control Container sem nada ligado à sua entrada Control foi sempre apenas um agrupamento visual e é convertido exatamente como um Tool Container.
Um Control Container desenhado em torno de nada mantém a legenda na área de desenho como uma caixa de destaque.

Por vezes, a ferramenta que alimenta a entrada Control não produz dados para testar, pelo que não há nada a partir do qual construir a condição. A importação já não ignora isto em silêncio. O contentor chega como um passo marcado como não convertido, com uma nota a indicar que, de outro modo, as ferramentas no seu interior seriam executadas sempre, e é enumerado no relatório de conversão como um passo sobre o qual tem de atuar. Esse passo falha quando o fluxo de trabalho lá chega, pelo que a conversão não pode ser executada como se nada estivesse errado.

Anteriormente, o interior era importado para ser executado incondicionalmente e nada na área de desenho o indicava, o que é a versão silenciosa do mesmo problema.

Para o resolver, altere o fluxo de trabalho do Alteryx de modo que a entrada Control provenha de uma ferramenta que produza dados e importe novamente, ou elimine o passo assinalado e coloque você mesmo a condição nos passos que estavam dentro do contentor — consulte Condições dos passos.

A ferramenta Browse

Um Browse do Alteryx é um visualizador. Apresenta os registos que chegam até si, não altera nada e não tem conector de saída. No PlaidCloud, a tabela de saída de cada passo já está disponível para abrir, pelo que aquilo para que um autor desenhou um Browse está a um clique do passo acima dele — selecione esse passo e consulte a respetiva tabela.

Por isso, um Browse passa a fazer parte da área de desenho em vez de um passo. Não cria nenhum passo, não reivindica nenhuma tabela e não é contabilizado entre as ferramentas que a conversão não conseguiu tratar:

Não é criada nenhuma tabela para ele. Cada Browse costumava passar a ser um passo que não fazia nada e que o fluxo de trabalho depois descartava, reivindicando ainda assim uma tabela própria no armazém que nada escrevia e nada lia. No nosso conjunto de referência de 179 fluxos de trabalho do Alteryx, eram 152 tabelas.
Um ramo com falha é reportado uma só vez, contra a ferramenta que falhou. Um Browse costumava ser enumerado no relatório de conversão como uma ferramenta que não foi convertida sempre que a ferramenta que o alimentava falhava, pelo que o mesmo problema aparecia duas vezes — uma contra a ferramenta que realmente tem de corrigir e outra contra um visualizador que nunca poderia ter sido executado. Catorze das falhas reportadas nesse conjunto de referência eram deste tipo. Essas entradas desapareceram; a ferramenta que realmente tem a culpa continua a ser reportada.

Isto remove entradas enganadoras do relatório de conversão, e não as falhas que estão por trás delas. O número de fluxos de trabalho que são convertidos com todas as ferramentas convertidas é o mesmo de antes.

Uma forma de fluxo de trabalho agora pára onde antes era executada, e isso é a correção e não uma nova falha.

Quando um fluxo de trabalho numera uma ferramenta dentro de uma macro da mesma forma que uma ferramenta na área de desenho que a chama, um passo abaixo da macro resolvia o nome da tabela do Browse em vez da saída da própria macro. Se importar novamente um fluxo de trabalho assim, esse passo pára agora, indicando uma tabela que não existe.

O passo nunca estava a ler os registos do Browse. Essa tabela era criada na importação e depois nunca era escrita por nada — o próprio Browse era descartado antes de o fluxo de trabalho ser construído — pelo que o passo lia uma tabela vazia e a execução reportava êxito sem ter processado nenhum registo. Os valores que produzia provinham do nada e nada o indicava. Com a tabela deixando de ser criada, o passo di-lo.

A reparação: reaponte esse passo para a tabela que foi desenhado para ler — a saída do passo de macro acima dele — e execute novamente o fluxo de trabalho.

Os fluxos de trabalho que importou antes desta versão mantêm a conversão que lhes foi dada, tabelas incluídas. Importe-os novamente para beneficiar desta alteração.

Bases de dados Calgary

Uma base de dados Calgary do Alteryx (um ficheiro .cydb) é um armazenamento indexado proprietário. O PlaidCloud não tem forma de ler o formato do ficheiro e não existe uma especificação aberta para ele. Em vez de recusar todas as ferramentas que lhe tocam, a conversão trata cada caminho .cydb como representando uma tabela normal do PlaidCloud, com o nome calgary_<database name> sob o prefixo de tabela que a importação aplica. Quando a base de dados é uma tabela normal, as ferramentas construídas em torno dela passam a ser operações normais: uma consulta guardada é um filtro, os baldes de contagem cruzada são contagens condicionais e a lista de campos de um carregador é um conjunto de colunas.

Um Calgary Loader convertido escreve essa tabela a partir da sua entrada. Os tipos de índice que declara são descartados durante a conversão — um armazém cria os seus próprios índices — mas a lista de campos é mantida.
Um Calgary Input convertido volta a ler a tabela, aplicando a sua consulta guardada como filtro. As colunas da própria tabela são resolvidas quando o passo é executado, uma vez que nada no ficheiro do fluxo de trabalho regista o que a base de dados continha.
Um Calgary Input (Count Only) ou Calgary Cross Count convertido lê a tabela como um agregado: os campos indexados simples agrupam as linhas e cada um dos valores nomeados de um campo personalizado passa a ser uma coluna contada.
Um Calgary Join convertido faz corresponder cada registo recebido à tabela, mantendo os registos que correspondem e transportando as colunas da própria entrada. É convertido quando o campo recebido é um valor simples e não espacial — consulte Calgary Join e Cross Count Append mais abaixo para os casos em que não é.
Um Calgary Cross Count Append convertido faz corresponder cada registo recebido à tabela da mesma forma e depois indica quantos registos da base de dados correspondeu, anexados à entrada — novamente quando o campo recebido é um valor simples e não espacial.

Um fluxo de trabalho que lê uma base de dados que ele próprio não construiu obtém um passo que pára, indicando a tabela. Os ficheiros .cydb demográficos e de referência fornecidos pelo Alteryx são o caso habitual — nada no seu fluxo de trabalho os escreveu, pelo que ainda não existe nenhuma tabela do PlaidCloud para ler. Até essa tabela existir, o passo convertido pára e indica-a, em vez de não ler nada em silêncio e reportar êxito. Exporte os dados de origem para a tabela indicada — a partir do .cydb original, se tiver o Alteryx disponível para o ler, ou do local onde os dados realmente se encontram — antes de executar o fluxo de trabalho.

Or, And e Not numa consulta Calgary

Uma consulta Calgary é uma árvore de And, Or e Not sobre os campos indexados da base de dados, e a árvore é agora convertida tal como foi escrita: um Or em qualquer ponto da mesma e um Not a envolver mais do que uma condição são ambos convertidos. Um termo de contém ou de começa por também é convertido — num LIKE de SQL no caminho de contagem e numa correspondência de subcadeia na leitura de registos. Isto abrange a leitura de registos de um Calgary Input, a sua leitura apenas de contagem, o Calgary Cross Count e os baldes dentro dos campos personalizados de um Cross Count.

Algumas formas de consulta continuam a não ser convertidas, e cada uma identifica-se no relatório de conversão e no passo:

Uma consulta que utiliza uma pesquisa espacial (ou um contém/começa por negado) em vez de uma comparação de colunas — uma operação de índice sem equivalente ao nível da coluna.
Uma leitura limitada por Skip Records ou Max Records — a tabela de substituição não tem ordem de registos em relação à qual saltar ou limitar.
Um Cross Count agrupado por mais do que um campo personalizado. As contagens são genuinamente um único agregado sobre a base de dados, mas o Alteryx não documenta como nomeia nem como ordena as colunas resultantes, e não há nenhum exemplo à mão para verificar.
Uma leitura apenas de contagem que não indica nenhuma coluna sobre a qual contar, uma vez que as colunas da própria base de dados não são legíveis a partir do ficheiro do fluxo de trabalho.
Um Calgary Loader que não armazena nenhum campo de dados, o que escreveria uma tabela sem colunas.
Uma ferramenta Calgary que não indica nenhuma base de dados.

Calgary Join e Cross Count Append

O Calgary Join e o Calgary Cross Count Append fazem corresponder cada registo recebido à base de dados através de um dos seus índices, e o ficheiro do fluxo de trabalho regista o nome do índice mas não o seu tipo. A mesma configuração significa uma junção por igualdade quando o índice contém valores normais e uma correspondência do tipo “que pontos caem dentro desta forma” quando contém geometria espacial — o ficheiro não permite distinguir qual.

A conversão decide com base no tipo declarado do próprio campo recebido: um índice espacial só pode ter sido emparelhado com um campo espacial, pelo que

um campo recebido com o tipo de objeto espacial pára, indicando o campo, a interpretação que produziu e a tabela de substituição contra a qual reconstruir a correspondência como um passo Spatial Match;
um campo recebido cujo tipo não pôde ser determinado pára, indicando isso como motivo — nunca é adivinhado;
um campo recebido normal e não espacial é convertido, fazendo a correspondência com a tabela de substituição.

Seja como for, o passo regista a interpretação que tomou e o tipo de campo a partir do qual a tomou, pelo que uma conversão com a qual discorde mostra o seu raciocínio em vez de o deixar a inferi-lo.

O Calgary Cross Count Append é convertido num campo recebido simples e não espacial, tal como um Calgary Join. Enquanto o Join mantém os registos correspondentes, o Append indica quantos registos da base de dados cada registo de entrada correspondeu: conta, por registo de entrada, as correspondências e anexa essa contagem à entrada. Um registo de entrada que não correspondeu a nada conta zero em vez de desaparecer, e dois registos de entrada idênticos mantêm cada um a sua própria linha — a contagem é por registo, não por conjunto distinto de valores. Um único campo de contagem cruzada simples é convertido desta forma; uma grelha de valores personalizados nomeados não é, porque anexaria uma coluna de contagem por valor e o Alteryx não documenta quantas colunas são nem como as nomeia.

Um Calgary Join em modo Count Only é convertido da mesma forma — conta, por registo de entrada, os registos da base de dados correspondidos, contando zero um registo que não corresponde a nada — em vez de manter os registos correspondentes.

Um Calgary Join ou Cross Count Append também pára, identificando-se, quando faz a correspondência com um intervalo de valores de índice em vez de um único valor, quando a sua saída de registos sem correspondência está ligada a algo a jusante, quando não indica nenhum campo para fazer corresponder à base de dados e quando não há nada ligado à sua entrada de onde fazer corresponder registos.

Um Loader convertido e os leitores do que ele escreveu ficam ligados entre si, pelo que um leitor não pode ser executado em paralelo com a escrita que preenche a sua tabela.

As colunas de um Calgary Input chegam como texto: a tabela de substituição indica os seus nomes, não os tipos da própria base de dados.

Ferramentas In-Database

Um fluxo de trabalho In-Database envia o seu trabalho para o armazém em vez do motor do Alteryx, e um passo do PlaidCloud já é SQL de armazém — por isso, as ferramentas de operação In-Database são convertidas exatamente nos mesmos passos que as suas equivalentes em memória. O Filter In-DB passa a ser um filtro, o Formula In-DB uma fórmula, o Summarize In-DB um agregado, e o mesmo acontece com Join, Select, Sample, Sort, Union e Browse.

O que não é convertido é o par de ferramentas em cada extremo da cadeia. O Connect In-DB e o Write Data In-DB abrem uma ligação ativa ao armazém, que as ferramentas entre eles mantêm e contra a qual enviam SQL, e o PlaidCloud não tem equivalente a essa ligação mantida aberta. Cada um chega como um passo assinalado para revisão, indicando a ferramenta e apontando para a sua substituição: um passo de importação ou exportação de SQL associado a uma ligação do PlaidCloud. Troque os dois extremos por esses passos e as ferramentas de operação intermédias são convertidas sem alterações.

Data Stream In, Data Stream Out, Dynamic Input In-DB, Dynamic Output In-DB e In-Database Macro Input/Output são recusados pelo nome, pelo mesmo motivo.

Uma União alimentada por uma junção por posição ou por uma Multi-Row Formula

Um fluxo de trabalho com uma Union a ler de um Join emparelhado pela posição do registo, ou de uma Multi-Row Formula, era convertido sem problemas mas podia falhar quando o executava — parando a meio com uma coluna que não conseguia resolver. A conversão parecia correta; só a execução do fluxo de trabalho revelava o problema.

Isto está corrigido: um fluxo de trabalho assim é agora executado até um resultado correto. Se encontrou este erro num fluxo de trabalho importado anteriormente, execute-o novamente — não é necessário importar de novo.

Colunas de saída do Join Multiple

Quando um Join Multiple enumera todos os campos no seu separador Select, o Alteryx Designer dá a cada um o nome Input_#1_<field>, Input_#2_<field> e assim sucessivamente. A Junção de várias tabelas convertida mantém essas colunas com os seus nomes de saída normais e aplica as alterações de nome e as desselecões do separador. Um Join Multiple convertido antes desta correção chegava sem colunas de saída e o seu passo falhava ao ser executado; importe esse fluxo de trabalho novamente para beneficiar da correção.

Colunas de percentagem e de total do Cross Tab

Um Cross Tab com um dos seus métodos derivados — Percent Row, Percent Column, Total Column ou Total Row — costumava interromper a conversão e arrastar consigo todos os passos abaixo. Os quatro são agora convertidos:

Percent Row e Percent Column são a parte da célula no total da respetiva linha, ou da respetiva coluna, do campo de dados.
Total Column é esse total da linha, com o nome que a ferramenta registou para ele.
Total Row é um registo adicional com os totais, sem valor nos campos de agrupamento.

Cada total é uma soma do campo de dados, independentemente dos métodos que a ferramenta calcula para cada célula.

Duas formas continuam a ser assinaladas para revisão em vez de convertidas: um Total Row num Cross Tab sem campo de agrupamento, que produziria o mesmo registo duas vezes sem nada que distinga as cópias, e um Total Column cujo nome a ferramenta nunca registou, que de outro modo faltaria por completo na saída.

As colunas Double do Alteryx mantêm a precisão total

Uma coluna Double do Alteryx é agora convertida numa coluna numérica de 64 bits, que corresponde à precisão com que o próprio Alteryx calcula. Anteriormente era convertida numa coluna de 32 bits — cerca de 7 algarismos significativos — pelo que qualquer valor com mais algarismos do que isso era arredondado em silêncio na leitura, e todos os cálculos construídos sobre ele herdavam o erro. Um caso real: 16 862 441,27 voltava como 16 862 442,00.

Dentro de uma macro convertida, uma coluna Double passada como entrada de macro costumava chegar como texto; agora chega como número. Se a lógica da macro dependia do antigo comportamento de texto — concatenação de cadeias, formatação com zeros à esquerda, correspondência de padrões de texto — reveja-a depois de converter novamente, uma vez que um número genuíno pode comportar-se de forma diferente.

Os fluxos de trabalho convertidos antes desta correção mantêm os tipos de coluna com que foram convertidos. Importe-os novamente para beneficiar desta alteração.

Macros num fluxo de trabalho convertido

As macros são convertidas em construções nativas do PlaidCloud — e não numa emulação do motor de macros do Alteryx. Cada tipo de macro é mapeado para uma funcionalidade de fluxo de trabalho de primeira classe, pelo que uma macro convertida executa a mesma lógica com o mesmo comportamento por registo ou por iteração que o original, com total fidelidade:

As macros padrão são incorporadas no fluxo de trabalho que as chama: as ferramentas da macro passam a ser passos normais na área de desenho, pelo que não há nenhuma caixa negra em que confiar — cada passo permanece visível, revisível e editável. As macros padrão aninhadas são incorporadas a qualquer profundidade, e uma macro que acabe por se chamar a si própria é detetada e identificada em vez de entrar num ciclo infinito.
As macros em lote passam a ser um fluxo de trabalho de macro executado uma vez por registo do parâmetro de controlo, com a saída de cada passagem recolhida de volta num único fluxo — a mesma execução por grupo que o Alteryx efetua. O parâmetro de controlo é associado como variável por passagem, exatamente como conduz o lote no Alteryx.
As macros iterativas passam a ser um ciclo de fluxo de trabalho nativo que transporta o estado entre passagens e é executado até a macro convergir. O limite de passagens do ciclo é o Maximum Number of Iterations da própria macro, a mesma definição com que o Alteryx a executa; quando está deixado no valor predefinido de proteção contra execução descontrolada do Alteryx, ou não está definido, a conversão aplica o seu próprio limite máximo. Se uma macro ainda não tiver convergido nesse limite, a execução pára e di-lo — indicando o limite que atingiu — em vez de reportar um resultado parcial como resposta final. Uma macro que precise genuinamente de mais passagens do que o limite máximo permite pode ser importada novamente com um limite superior: a opção iteration_ceiling da importação define-o.
Os parâmetros de controlo, as portas Macro Input e Macro Output, as ferramentas Action e as ramificações Detour são todos convertidos nos respetivos equivalentes nativos, pelo que o mecanismo que liga uma macro é preservado — e não aproximado. Uma macro chamada de dentro de uma macro em lote ou iterativa é resolvida e convertida juntamente com quem a chama.

Duas disposições são recusadas pelo nome em vez de convertidas, para que o saiba no momento da importação: uma macro em ciclo aninhada dentro de outra macro em ciclo e as ferramentas In-Database Macro Input/Output.

As conversões anteriores faziam com que cada passagem escrevesse a sua própria tabela de saída, com o passo que reunia os resultados a lê-las todas por nome — pelo que uma macro conduzida por apenas algumas dezenas de registos construía uma única consulta que abrangia esse número de tabelas, e a base de dados recusava planeá-la. O fluxo de trabalho parava a meio, sem nada de útil que apontasse como causa.

As passagens acumulam-se agora numa única tabela que o passo de reunião lê diretamente, e essa tabela é corretamente esvaziada no início de cada execução, pelo que uma execução cuja macro não produz passagens devolve um resultado vazio em vez de voltar a servir as linhas da execução anterior.

Se um fluxo de trabalho de macro em lote costumava bloquear ou falhar a meio, importe-o novamente para beneficiar da correção.

Uma macro Location Optimizer é apenas a passagem de pontuação de uma pesquisa. A própria pesquisa — a geração de conjuntos de locais candidatos, o número de locais, os limites de geração e a semente — reside na ferramenta que a chama e no motor do Alteryx e não no ficheiro do fluxo de trabalho. Fora do caso de distância linear acima — um núcleo gravitacional, uma macro de pontuação personalizada, um objetivo em que mais alto é melhor ou qualquer transformação da distância antes da pontuação (um custo fixo da instalação, um Summarize, uma junção) — o PlaidCloud não tem equivalente para esse ciclo de otimização. A chamada da macro chega agora como um passo assinalado para revisão, indicando a macro, a entrada em que chegam os seus conjuntos de candidatos, a saída que os classifica e se vence uma pontuação alta ou baixa.

Uma macro destas costumava ser convertida e executar-se com êxito, e os seus valores estavam errados. Era tratada como uma macro normal, pelo que a passagem de pontuação era executada exatamente uma vez sobre um único conjunto de candidatos e a execução reportava êxito — um resultado que parecia uma resposta mas era um palpite pontuado e não uma solução otimizada. Se importar novamente um fluxo de trabalho assim e vir uma recusa onde antes funcionava, o resultado anterior não era um em que devesse ter confiado.

Relatórios num fluxo de trabalho convertido

Uma imagem a que o esquema de um relatório se refere é agora empacotada com o fluxo de trabalho, pelo que um relatório convertido a encontra em Document em vez de falhar num recurso que só existia na máquina do Alteryx. Isto abrange uma imagem indicada por um caminho fixo — uma imagem cujos bytes estão incorporados no fluxo de trabalho, ou cujo caminho é tirado de uma coluna por registo, não tem ficheiro separado a obter.

Uma parte de um relatório cujos dados de origem não puderam ser lidos é agora reportada como tal. Quando as colunas de uma tabela não puderam ser lidas, um fragmento de relatório construído a partir dela costumava ser ignorado e uma secção de tabela do relatório costumava ficar vazia, ambos em execuções que reportavam êxito. O passo agora pára e diz que a informação das colunas não pôde ser lida, e porquê. Um relatório que antes saía com uma secção em falta pode agora parar com uma explicação — consulte a respetiva entrada de correção em agosto de 2026.

Utilizar o fluxo de trabalho convertido

Depois da importação, utilize o fluxo de trabalho como qualquer outro fluxo de trabalho avançado do PlaidCloud:

Abra a área de desenho do fluxo de trabalho convertido.
Reveja os passos e os ramos gerados.
Defina as variáveis do fluxo de trabalho para quaisquer perguntas de aplicações convertidas ou parâmetros de tempo de execução.
Execute o fluxo de trabalho.
Reveja o histórico de execuções, as saídas dos passos, as notas de prontidão e os artefactos gerados.
Agende o fluxo de trabalho quando estiver pronto para operação repetível.

Uma ferramenta Download convertida passa a ser um passo Pedido REST, que alcança um ponto final externo através de uma ligação REST em vez de um URL fixado no passo. Atribua uma ligação REST ao passo antes de o executar — o conversor assinala-o no momento da importação com uma nota de prontidão. Consulte Criar uma ligação para configurar uma.

As macros convertidas ficam disponíveis como fluxos de trabalho de macro do PlaidCloud. Um fluxo de trabalho que chamava uma macro do Alteryx chamará a macro do PlaidCloud gerada através do passo de macro. As execuções de macros são isoladas umas das outras, pelo que as execuções simultâneas de fluxos de trabalho podem utilizar em segurança a mesma definição de macro.

Validar a conversão

O PlaidCloud suporta dois níveis práticos de validação.

Validação estrutural

A validação estrutural confirma que o fluxo de trabalho foi convertido num DAG executável do PlaidCloud:

Cada ferramenta do Alteryx tem um caminho de conversão no PlaidCloud.
As macros necessárias foram encontradas ou geradas.
Os ficheiros de entrada necessários foram carregados para Document.
As entradas e as saídas de macro estão ligadas.
Foram criadas variáveis de fluxo de trabalho para as entradas controladas pelo utilizador.
O fluxo de trabalho gerado abre-se e pode ser executado no PlaidCloud.

A validação estrutural é útil para a prontidão da migração, a revisão do inventário e a conversão antecipada do portefólio.

Validação da paridade das saídas

A validação da paridade das saídas compara a execução do PlaidCloud com saídas do Alteryx de confiança:

Os esquemas das saídas coincidem.
As contagens de linhas coincidem.
Os valores das linhas coincidem.
A ordem das linhas é ignorada, a menos que o fluxo de trabalho dependa explicitamente da ordenação.

Nos fluxos de trabalho que criam relatórios, mapas, PDF, imagens ou artefactos de modelos, valide o artefacto gerado ou os dados por trás dele de acordo com a forma como a sua equipa utiliza a saída.

Consulte Validar fluxos de trabalho Alteryx convertidos para uma lista de verificação de validação detalhada.

Amostragem aleatória

Os valores das linhas são o único ponto em que uma ferramenta de amostragem é uma exceção deliberada. Create Samples e Random % Sample extraem ambas ao acaso, e o Alteryx devolve os mesmos registos em cada execução quando é definida uma semente. O PlaidCloud extrai com o seu próprio gerador, pelo que:

Os tamanhos das amostras, as percentagens e as proporções da divisão Estimation / Validation / Holdout são transportados exatamente.
Os registos dentro de cada amostra não são os que o Alteryx escolhe, e uma nova execução escolhe novamente um conjunto diferente.

Cada passo convertido di-lo no relatório de conversão e no próprio passo, e nenhum é reportado como uma ferramenta que não foi convertida. Valide-os com base nas contagens de linhas e nas proporções e não nos valores das linhas.

Quando é importante saber que registo cai em que amostra — um modelo que precisa de reproduzir exatamente ou um holdout sobre o qual já publicou resultados — decida a amostra com uma coluna: um passo Formula que calcula a atribuição da amostra e um passo Filter por amostra.

Conversões de Machine Learning (Assisted Modeling)

Os pipelines de machine learning do Alteryx construídos com a família de ferramentas Machine Learning são convertidos nos passos de ML nativos do PlaidCloud:

Uma ferramenta Classification ou Regression, juntamente com as suas fases anteriores de Assisted Modeling e de transformação e a ferramenta Fit a jusante, funde-se num único passo ML: Treinar modelo. O passo transporta o algoritmo exato, a variável alvo, as colunas de caraterísticas e os hiperparâmetros do fluxo de trabalho do Alteryx e escreve o modelo treinado como uma tabela de modelo de uma linha, com as métricas de treino registadas nela.
Cada ferramenta Predict passa a ser um passo ML: Pontuar que lê a tabela do modelo treinado e a sua entrada de dados. A coluna de previsão tem o nome da variável alvo com o sufixo _predicted.
Os classificadores XGBoost são convertidos com uma nota de aproximação: o modelo é treinado como um classificador de gradient boosting do scikit-learn, e quaisquer parâmetros de árvore específicos do XGBoost sem equivalente são enumerados nas notas de mapeamento do passo. Valide as métricas do modelo em relação à execução do Alteryx antes de confiar na paridade.
Uma ferramenta Image Recognition treina um classificador de imagens no fluxo de trabalho e pontua novas imagens com ele, inteiramente no local — sem conta externa e sem que nenhum dado de imagem saia do PlaidCloud. Um Predict a jusante apontado ao modelo pontua com ele. Duas coisas são transportadas de forma diferente do resto da família ML, pelo que deve validá-las antes de confiar na paridade. Primeiro, o classificador é treinado de novo a partir das suas imagens etiquetadas em vez de copiado do Alteryx, e esse treino é não determinístico — duas conversões do mesmo fluxo de trabalho produzem modelos ligeiramente diferentes, pelo que as previsões são uma aproximação fiel e não uma correspondência bit a bit. Segundo, o treino é executado em CPU, pelo que um conjunto de centenas a poucos milhares de imagens demora vários minutos. O Image Recognition é ativado por área de trabalho; peça ao seu administrador que o ative se um fluxo de trabalho convertido reportar que não está ativado.
Uma ferramenta AutoML funde-se num passo ML: Treinar modelo da mesma forma que Classification e Regression. O AutoML não regista qual dos seus algoritmos candidatos venceu realmente em tempo de execução no Alteryx, pelo que a conversão escolhe o primeiro algoritmo selecionado que o ML Train suporta e regista a escolha em nota, em vez de reproduzir uma pesquisa automatizada. Compare um passo AutoML convertido com os seus próprios resultados do Alteryx.
Um assistente de Assisted Modeling cujo modelo foi escolhido interativamente (e nunca guardado no ficheiro do fluxo de trabalho) não pode ser convertido — o importador mantém um passo de substituição cujas notas registam a variável alvo recuperada, para que possa construir manualmente o passo ML Train.
Uma fase isolada de codificação one-hot é assinalada no relatório de conversão. O passo ML Train fundido codifica internamente em one-hot as caraterísticas categóricas, pelo que a fase isolada normalmente não precisa de substituição.

Como acontece em todas as conversões, os passos fundidos transportam a sua confiança e as suas notas no relatório de conversão e na área de desenho, pelo que os pipelines que merecem uma verificação dupla são fáceis de encontrar.

Rever a cobertura da conversão

A matriz de conversão do Alteryx enumera cada objeto Alteryx suportado, o respetivo nível de cobertura e a operação do PlaidCloud utilizada durante a conversão.

Utilize a matriz para compreender como o importador trata cada família de ferramentas:

Passos de DAG nativos para preparação de dados comum, junções, filtros, fórmulas, ordenação, uniões, amostragem e reestruturação.
Passos de macro para entradas de macro, saídas de macro, invocação de macros, parâmetros de controlo e concorrência de macros.
Variáveis de fluxo de trabalho controladas para perguntas de aplicações analíticas, como caixas de seleção, listas pendentes, caixas de texto, botões de opção, seletores de pastas e seletores de ficheiros.
Operações de ficheiros alojadas em Document para o comportamento de entrada, saída, diretório e ficheiros dinâmicos.
Passos nativos ML Train e ML Score para pipelines de machine learning de Assisted Modeling.
Uma tabela de substituição para cada base de dados Calgary do Alteryx, para que as ferramentas Calgary Loader, Input, Cross Count e Join sejam convertidas contra uma tabela normal em vez de serem recusadas de imediato — consulte Bases de dados Calgary.
Executores de tarefas geridos para trabalho especializado de espacial, correspondência difusa, PDF, OCR, NLP, relatórios e artefactos.
Equivalentes nativos da nuvem quando o PlaidCloud cria um artefacto duradouro e partilhável em vez de reproduzir um renderizador de secretária específico do Alteryx ou um formato de ficheiro proprietário.

O seu relatório de cobertura do Alteryx

Veja o que existe nos seus fluxos de trabalho do Alteryx antes de se registar.

Abra a página pública em https://app.plaidcloud.com/#coverage-report, com o título See what’s in your Alteryx workflows.
Largue um ficheiro em Drop an Alteryx workflow here ou escolha Escolha um ficheiro. Aceita um fluxo de trabalho (.yxmd), uma macro (.yxmc) ou um pacote (.yxzp) até 10 MB. O PlaidCloud lê o ficheiro e mostra as ferramentas que encontrou e as mais utilizadas. As credenciais guardadas no ficheiro são removidas.
Introduza o seu Work email, aceite os Termos de Serviço e a Política de Privacidade e escolha Email me a verification link.

O seu relatório completo é construído na sua própria área de trabalho gratuita do PlaidCloud. O PlaidCloud converte o carregamento num projeto com o nome Alteryx migration, e o primeiro administrador da área de trabalho que abrir Home vê O seu relatório de cobertura do Alteryx. Enumera cada fluxo de trabalho com quantas das suas ferramentas o PlaidCloud reconheceu e pode converter, quantas estão Para rever e um botão Abrir para o fluxo de trabalho convertido. Os ficheiros de dados não fazem parte do relatório; carregue os ficheiros que os seus fluxos de trabalho leem e depois execute-os. Os botões do relatório conduzem a Utilizar o seu próprio data warehouse e Comprove a sua migração. Um carregamento é mantido durante 7 dias.

Se já tiver uma conta PlaidCloud, o endereço de correio eletrónico que introduziu recebe uma mensagem, Your coverage report is ready — sign in to view it, com uma ligação. Inicie sessão, abra-o, escolha a Área de trabalho e escolha Add the report. Só um administrador da organização da área de trabalho o pode adicionar, e o relatório abre-se da próxima vez que abrir a área de trabalho. Ignorar o correio eletrónico não altera nada na sua área de trabalho. Uma ligação inválida ou expirada di-lo, e um carregamento expirado tem de ser carregado novamente.

Depois de uma conversão, comprove que corresponde às suas saídas do Alteryx.

Prática de migração recomendada

Num portefólio grande, migre em lotes:

Importe os fluxos de trabalho e as macros para um projeto de migração.
Conclua os pacotes de dependências antes de rever fórmulas individuais ou a lógica de negócio.
Execute a validação estrutural em todo o lote.
Dê prioridade à validação da paridade das saídas nos fluxos de trabalho de produção, nos fluxos de trabalho regulamentares e nos fluxos de trabalho com consumidores a jusante.
Promova os fluxos de trabalho validados para o projeto de produção de destino.
Agende as execuções de produção e monitorize o histórico de execuções.

Guias relacionados

Conjunto de documentação de migração

Para migrações maiores, utilize estes guias específicos juntamente com este guia de migração:

Lista de verificação de prontidão da migração do Alteryx para o planeamento da migração e a revisão de pacotes.
Empacotar dependências do Alteryx para ficheiros, pastas, macros, ficheiros auxiliares espaciais e saídas esperadas.
Utilizar aplicações Alteryx convertidas para variáveis de fluxo de trabalho controladas e execuções ao estilo de aplicação.
Orquestrar migrações do Alteryx com MCP para utilizar um agente de IA que organize ficheiros, trabalhe a partir de armazenamento partilhado ligado e coordene muitas conversões através do servidor MCP do PlaidCloud.
Ajustar importações do Alteryx para a conclusão de dependências, a resolução de macros, as variáveis, as comparações de validação e as notas de prontidão dos executores.
Validar relatórios e artefactos do Alteryx para PDF, imagens, mapas, gráficos, painéis de controlo e artefactos de modelos.
Migrar fluxos de trabalho Alteryx espaciais para ficheiros espaciais, lógica de geometria SQL, executores espaciais geridos e validação espacial.