Fonte de Dados Personalizada

Validation logic is only as reliable as the data it validates against. Custom data sources connect your authoritative external systems into Altium platform processes – so that checks run against current, live data, not a snapshot that goes stale.

Na Extensibilidade de Comportamento, fontes de dados personalizadas não são um componente de infraestrutura separado — são um padrão de como verificações e scripts em Python acessam dados externos. Uma verificação escrita em Python pode chamar qualquer API acessível, consultar qualquer banco de dados alcançável e usar o resultado como parte de sua lógica de validação. O sistema externo continua sendo a fonte autoritativa. O Altium o consulta; não mantém uma cópia.

É isso que torna concreta a afirmação de Customizability no roadmap: "Uma verificação pode acessar seu banco de dados interno de peças, sua lista de fornecedores aprovados, seu sistema ERP e retornar um resultado." A fonte de dados personalizada é a chamada que faz isso acontecer.

Por que o Acesso a Dados em Tempo Real é Importante

Uma verificação que valida a aprovação de componentes com base em uma lista estática embutida na lógica da verificação estará correta quando for escrita e errada em poucas semanas. Listas de peças aprovadas mudam. Listas de materiais restritos mudam. Status de ciclo de vida mudam. Uma verificação que chama seu sistema em tempo real obtém a resposta atual toda vez que é executada.

Essa é a diferença entre codificar uma regra e codificar conhecimento. Uma lista estática codifica o estado do conhecimento em um determinado momento. Uma chamada para uma fonte de dados em tempo real codifica a regra de que o estado atual de um sistema autoritativo determina a conformidade. A segunda abordagem envelhece melhor.

Fontes de Dados Externas Comuns

• Approved Vendor / Manufacturer Lists (AVL/AML) – sua equipe de compras ou de engenharia de componentes mantém a lista autoritativa de fabricantes e fornecedores aprovados. Uma verificação que consulta essa lista em tempo real garante que um componente marcado como aprovado no Altium tenha realmente sido aprovado no sistema autoritativo no momento em que a verificação foi executada – não no último momento em que alguém atualizou um arquivo local.

• Component qualification databases – organizações com processos maduros de qualificação de componentes mantêm bancos de dados internos com status de qualificação, dados de teste, restrições de aplicação e casos de uso aprovados. Conectar esses dados às verificações do Altium significa que o status de qualificação fica visível e é aplicado na fase de projeto, e não descoberto apenas na revisão de liberação.

• ERP and inventory systems – verificações que validam lead times, níveis de estoque ou status de aquisição com base em dados ERP em tempo real permitem que engenheiros tomem decisões conscientes sobre sourcing durante o projeto, em vez de descobrirem problemas de suprimento depois que o projeto estiver concluído.

• Compliance and restricted materials databases – ITAR, EAR, RoHS, REACH e listas internas de controle de PI são mantidos por equipes de conformidade e mudam ao longo do tempo. Uma verificação que consulta dados de conformidade em tempo real aplica o estado atual da política sem exigir que a própria verificação seja atualizada toda vez que a política mudar.

• Internal parametric and specifications data – normas de engenharia, especificações de componentes preferenciais, folhas de dados internas e resultados de teste mantidos por sua organização podem ser exibidos em verificações e painéis do Altium, dando aos engenheiros acesso ao conhecimento interno no momento da decisão.

Considerações de Implementação

• Accessibility – uma verificação executada na plataforma do lado do servidor precisa alcançar o sistema externo a partir do contexto de rede do servidor. Uma verificação executada no lado do cliente no Altium Designer precisa alcançá-lo a partir da máquina do engenheiro. Confirme a acessibilidade da rede antes de criar verificações que dependam de chamadas externas.

• Latency – verificações executadas no desktop rodam enquanto o engenheiro está trabalhando. Uma verificação que leva vários segundos para retornar devido a uma API externa lenta cria atrito que os engenheiros tentarão contornar. Mantenha as chamadas externas rápidas, direcionadas e passíveis de cache quando os dados não mudarem com frequência.

• Failure handling – projete as verificações para falharem com segurança quando o sistema externo não estiver disponível. Uma verificação que não consegue acessar a AVL deve falhar em modo fechado – relatar que não pôde ser concluída, não que o componente está aprovado. Permitir silenciosamente a aprovação das verificações porque a fonte de dados estava inacessível é uma falha de confiabilidade com consequências de conformidade.

• Authentication – chamadas de API externas a partir da lógica da verificação precisam de credenciais. Armazene credenciais como segredos do Workspace ou configuração de ambiente, não codificadas diretamente nos scripts de verificação. Trate o código da verificação como trataria qualquer código de produção que manipule credenciais.

O Que Fontes de Dados Personalizadas Não São

Fontes de dados personalizadas, neste contexto, são chamadas a partir da lógica de verificações e scripts – não uma camada separada de integração de dados nem um mecanismo de sincronização. Elas não substituem as fontes de dados de componentes nativas do Altium (Octopart, Silicon Expert, Z2 Data) para cadeia de suprimentos e dados paramétricos de provedores externos. Elas são o padrão para acessar seus próprios sistemas internos a partir de sua própria lógica de validação personalizada.

Para casos de uso que exigem troca bidirecional de dados entre Altium 365 e sistemas externos no nível da plataforma – não apenas leituras a partir da lógica da verificação – a API do Altium 365 e o SDK de Integração PLM são as ferramentas apropriadas.