Estratégia de versão do biztalk

BizTalk Fringe.

Contos da fronteira de integração:

"Como é que quando ninguém sabe e não faz sentido, eles vêm até nós?"

domenica, gennaio 09, 2011.

Estratégia de versionamento do BizTalk (2/4)

Esta é a segunda parte da discussão sobre versionamento, a primeira parte aqui.

Mensagens e Objetos: Dois lados da mesma moeda.

O BizTalk tem um dualismo estranho quando se trata de processamento de mensagens:

De um lado, o BizTalk é um aplicativo e, portanto, uma mensagem é identificada por seu Tipo, a montagem que o contém e seu Nome Forte.

Por outro lado, o BizTalk é um middleware de processamento Orientado a XML e, portanto, uma mensagem (se é um xml) também é identificada por suas características XSD (o que é chamado na terminologia do BizTalk de seu tipo de mensagem). identificado pelo nome do nó raiz e pelo namespace)

No exemplo abaixo, cliquei duas vezes em um esquema implementado no console de administração do biztalk, apenas para descobrir que o esquema é identificado pelo seguinte par de propriedades:

Tipo: BizTalk_Server_Project1.Schema1, BizTalk Server Projeto1, versão = 1.0.0.0, Culture = neutral, PublicKeyToken = a76ffbe6c9882f67.

O mesmo dualismo pode ser lido em uma instância de mensagem inspecionada por meio do console de administração: como você pode observar nas propriedades de contexto MessageType e SchemaStrongName.

Por que essa distinção é importante?

Essa distinção é extremamente importante porque nos ajuda a entender alguns comportamentos biztalk estranhos e antecipar problemas de versionamento:

Se você tentar implantar dois esquemas diferentes, mas com o mesmo nome de nó raiz e espaço de nomes em dois assemblies diferentes, o BizTalk explodirá assim que uma mensagem correspondente ao esquema entrar na caixa de mensagem com a seguinte exceção.

Não é possível localizar a especificação do documento porque vários esquemas corresponderam ao.

tipo de mensagem "http: / MySchema1 # Root"

(O mais desagradável desse problema é que obviamente afeta todas as mensagens que correspondem ao esquema, não apenas as mensagens da implantação incorreta, isso significa que um dia um processo funciona corretamente, um dia depois de alguém decidir implantar outro esquema para outro projeto sem perceber a incompatibilidade de tipo de mensagem e o processo que estava funcionando corretamente não está mais funcionando. Esta experiência me ensinou a colocar esquemas em assemblies separados para sistemas em vez de processos: reduzir a possibilidade de colocar o mesmo tipo de mensagem em assembly diferente porque geralmente o nome do sistema é também contido no namespace xml da mensagem)

Conhecendo o dualismo descrito acima, o problema agora está claro:

BizTalk receber uma mensagem XML do externo, a primeira coisa que faz é procurar em seu banco de dados para encontrar o tipo relacionado a essa mensagem XML (usando MessageType como chave).

Se tiver duas correspondências, não poderá decidir qual tipo usar para desserialização de mensagens e lançará a exceção.

Mas, se você implantar o mesmo tipo de mensagem em outra versão do mesmo assembly, nenhuma exceção será gerada.

Isso se deve ao fato de que (como descrito aqui) o mecanismo biztalk tem uma exceção à regra sem vários resultados: Se a correspondência múltipla vier de versões diferentes do mesmo assembly, o esquema vindo do mais recente (versão mais alta) será usado.

Equipado com todos esses novos conhecimentos, vamos ver como todos os artefatos biztalk irão reagir a uma atualização de esquema (isto é, versão de esquema antiga = 1.0.0.0 enquanto o novo esquema é implementado lado a lado com a versão = 1.0.0.1).

O componente XmlDisassembler é responsável por identificar e promover o MessageType e o SchemaStrongName da mensagem.

Portanto, aplicando o que é visto até agora, o xmldisassembler atribuirá o MessageType sem problemas (afinal, ele simplesmente concatena o nome Root e o namespace) e resolverá o SchemaStrongName para a versão 1.0.0.1.

Se, por alguma razão, você quiser sobrescrever o & # 8220; padrão para versão superior & # 8221; regra você pode indicar explicitamente o SchemaStrongName nos "Esquemas do documento" & # 8221; propriedade do componente de pipeline.

Mapas são simplesmente transformações XLST, portanto, eles geralmente não são de todo interessados ​​em SchemaStrongNames ou Types, mas olham apenas para o MessageType.

Na verdade, ao colocar vários mapas em uma porta, uma mensagem é direcionada para um ou outro mapa apenas examinando seu tipo de mensagem e nada mais.

Mas, em tempo de compilação, os mapas são compilados contra esquemas biztalk (esquemas de origem e de destino) e, portanto, no final dos mapas de transformação, simplesmente & # 8220; acrescentar & # 8221; o destino esperado MessageType e SchemaStrongName para a mensagem de saída.

Em outras palavras, se você tiver compilado seu mapa com a versão 1.0.0.0 de seu esquema, o mapa continuará funcionando sem problemas se você enviar uma versão 1.0.0.1 de sua mensagem para dentro, mas produzirá uma versão 1.0.0.0 do resultado.

As orquestrações são diferentes: elas são um bloco de código estaticamente compilado e, portanto, não estão cientes das mensagens XML, mas só entendem os tipos.

Portanto, se você enviar para uma orquestração (compilada na versão 1.0.0.0) mensagens com a versão 1.0.0.1, mesmo que elas sejam idênticas (de um ponto de vista xml) à orquestração de mensagem 1.0.0.0, haverá uma exceção ( & # 8220; Recebido tipo de mensagem inesperada & # 8221; visto na parte anterior).

Fazendo uma rápida recapitulação, portanto, podemos dizer que a implantação do esquema lado a lado com o seu & ldquo; padrão para a versão superior & # 8221; regra é boa quando você apenas mapeia e faz pipelines (então é perfeito em um cenário somente de mensagens), mas falhará miseravelmente se você orquestrar em sua solução.

Na próxima parte, tentaremos encontrar uma solução para esse problema.

BizTalk Fringe.

Contos da fronteira de integração:

"Como é que quando ninguém sabe e não faz sentido, eles vêm até nós?"

venerdì, gennaio 07, 2011.

Estratégia de versionamento do BizTalk (1/4)

Como dito no post anterior, o gerenciamento de soluções BizTalk pode ser uma tarefa desafiadora devido à complexidade do processo de atualização de artefatos biztalk.

O BizTalk faz o possível para evitar a possibilidade de deixar o sistema em estado inconsistente, e isso é uma coisa boa, mas, ao fazê-lo, lança o fardo de um fluxo de trabalho de implementação incrivelmente burocrático no desenvolvedor, mesmo quando é claramente desnecessário.

Vamos fazer o seguinte caso não tão hipotético:

Eu tenho uma orquestração (contida em um assembly ProcessA. orchestrations. dll) que usa um mapa (contido em ProcessA. maps. dll) que usa alguns esquemas (contidos em System1.schemas. dll e System2.schemas. dll) .

Como você pode ver, eu segui as melhores práticas de separar diferentes artefatos do BizTalk em diferentes assemblies e aprimorei-os um pouco (separando ainda mais artefatos para processos e sistemas) para detectar facilmente o impacto de nossas modificações futuras no projeto.

Digamos que precisamos implementar outro processo entre os mesmos sistemas.

O que precisamos fazer é adicionar um novo esquema ao System1.schemas. dll para representar novas mensagens trocadas no segundo processo.

Bem, para atualizar o arquivo System1.schemas. dll, precisamos:

Como você está atualizando uma dll de esquema, é preciso removê-la. Como o esquema é usado em mapas, é necessário remover os mapas que o estão usando (ProcessA. maps. dll). Como os mapas são usados ​​na orquestração, você precisa remover também as orquestrações (ProcessA. orchestrations. dll) Para remover uma montagem de orquestração, é necessário desmarcar todas as orquestrações contidas nela. Para desmarcar todas as orquestrações, você deve encerrar todas as ocorrências de serviços existentes referenciando-as. Se a orquestração estiver vinculada a uma porta física, será necessário parar & amp; unenlistar todas as portas relacionadas. Se os mapas forem usados ​​em uma porta, você precisará remover manualmente os mapas de todas as portas em que são usados. Finalmente, você pode implantar o esquema. Mas depois que você precisar reimplantar também os mapas removidos (ProcessA. maps. dll), mas após precisar reimplementar também as orquestrações que você removeu (ProcessA. orchestrations. dll), lembre-se de inscrever novamente a orquestração. Você deve se lembrar de se inscrever / iniciar receber / enviar portas Você precisa configurar os mapas nas portas de recebimento / envio que foram removidas.

Uma sequência muito longa de etapas, especialmente considerando que fui forçado a reimplantar completamente o ProcessA quando sei que não é necessário, porque a única modificação que fiz na montagem do esquema foi adicionar um novo esquema deixando intocado o antigo & # 8230; em outras palavras, minhas alterações eram compatíveis, mas por padrão o biztalk assume que elas não são e isso causa o problema.

Um pouco injusto.

Eu sei, acima eu omiti voluntariamente algumas coisas que teriam facilitado a vida e eu vou remediar aqui adicionando também as razões pelas quais eu não as considero uma solução.

Usando & # 8220; Modificar & # 8221;

Se você selecionar um recurso do Console de Administração do BizTalk e pressionar a tecla direita do mouse, você observará um erro & # 8220; Modificar & # 8230; & # 8221; voz no menu pop-up.

Esta opção nos leva a uma janela de diálogo quase idêntica à janela & # 8220; Adicionar & # 8211; & gt; Novo assembly do BizTalk & # 8230; & # 8221;

Mas com uma diferença: se decidirmos por & # 8220; Atualizar & # 8221; a montagem com um novo, o BizTalk ficou mais inteligente e nos permitirá implantar o novo sem remover o antigo. Portanto, no cenário superior, todas as listas de passos que relatei poderiam ser evitadas usando simplesmente o Modify em vez do clássico & # 8220; Adicione & # 8211; & gt; Novo assembly do BizTalk & # 8211; & gt; Substituir & # 8221;

Por que a equipe do BizTalk decidiu implementar um comportamento tão diferente para essas duas opções quase idênticas (Add with overwrite e Modify) é um mistério para mim, mas desde que eu saiba que a diferença está lá, é ok para mim.

Então problema resolvido?

Não, definitivamente não e por duas razões (IMHO bom):

Modificar a opção não tem equivalente linha de comando, BTSTask. exe, na verdade, tem apenas a alternativa AddResource / Overwrite, deixando-nos incapaz de usar esse recurso para scripts de instalação / atualização ou msi de implantação automática. Modificar funciona muito bem se não houver dependências entre aplicativos, mas falhar miseravelmente (com o mesmo problema de AddResource com Overwrite) se houver alguma referência de aplicativo.

A segunda razão precisa de uma explicação melhor: Vamos dizer que para o projeto acima eu defini diferentes aplicativos, como Common (contendo todos os componentes comuns, como esquemas, funções auxiliares e assim por diante) ProcessA (contendo orquestrações, portas e mapas pertencentes ao ProcessA ) e assim por diante.

Obviamente, o ProcessA Application fará referência ao Common Application e, quando tentarmos modificar o schema. dll em Common (exatamente como fizemos antes, quando todos os processos no mesmo aplicativo) obtivermos uma falha, conforme descrito abaixo.

Versão crescente do conjunto.

Outra solução poderia ser simplesmente aumentar a versão do assembly da dll de esquemas modificados (digamos, de 1.0.0.0 a 1.0.0.1).

O BizTalk permite a implantação lado a lado de assemblies (mais sobre isso depois) e, portanto, esta poderia ser a solução que estávamos procurando:

O ProcessA continuará a usar a versão 1.0.0.0 dos esquemas, enquanto o novo ProcessB usará a nova versão 1.0.0.1 (contendo, portanto, o novo esquema)

Isso pode parecer funcionar, mas mais cedo ou mais tarde (se você usar orquestrações), você enfrentará uma exceção semelhante.

Para entender por que (e quando) esta exceção será levantada e como podemos resolver o problema de uma vez por todas, precisamos examinar o mecanismo de resolução do BizTalk em profundidade.

Estratégias de upgrade e versionamento para aplicativos.

Neste artigo.

O controle de versão do aplicativo BizTalk pode se tornar um problema quando você precisar executar duas versões de uma solução do BizTalk lado a lado ou se não for possível usar o tempo de inatividade do aplicativo BizTalk para implantar uma nova versão. Se você não precisar executar duas versões da solução simultaneamente (por exemplo, quando não tiver orquestrações de longa execução) e se as janelas de manutenção de serviço estiverem disponíveis, será perfeitamente aceitável que você desimplante a versão antiga e implante a nova versão. como uma estratégia de versão (sem versão de assembly). Essa é uma estratégia de versionamento possível, embora ainda seja recomendável incrementar o número da versão do arquivo (para que você saiba qual versão é implantada nos computadores que executam o BizTalk Server).

Quando usar o controle de versão.

Se você precisar dar suporte a orquestrações de longa execução e / ou precisar executar implantações de aplicativos do BizTalk sem tempo de inatividade do aplicativo BizTalk, será necessário implementar e praticar uma estratégia de versão sólida e completa do BizTalk Server para os diferentes cenários de versão. . Isso inclui versões de versões e versões de todos os artefatos do BizTalk, que incluem esquemas, mapas, pipelines, componentes de pipeline, orquestrações, adaptadores personalizados, classes personalizadas chamadas em orquestrações e mapas, regras de negócios e BAM.

O controle de versão do esquema é exclusivo porque os pipelines do BizTalk Server determinam o tipo de mensagem de uma mensagem com base no namespace de destino, além do nome do nó raiz definido no esquema. Para obter mais informações, consulte Resolução de esquemas em componentes de pipeline. Se você precisar criar uma versão dos seus esquemas, um indicador de versão deve fazer parte do namespace de destino. Alterar a versão do esquema tem um efeito cascata em toda a sua solução e, portanto, deve ser planejado com antecedência. Ao criar mensagens de orquestração, procure pelo BizTalk Server: 8 dicas e truques para uma melhor programação do BizTalk (dica 1: usar sempre tipos de mensagens de várias partes). O uso desse método fornece maior flexibilidade ao esquemas de versão.

Usando Factoring para Versionamento de Montagem.

Se você precisar dar suporte a orquestrações de longa duração, implantações lado a lado ou upgrades sem tempo de inatividade, deverá implementar uma estratégia de controle e controle de versões de montagem. Para executar o versionamento de assembly dos artefatos do BizTalk, seus assemblies de solução do BizTalk precisam ser fatorados (empacotados) de forma a permitir a versão do BizTalk Server. Existem três tipos de fatoração:

Todos os artefatos do BizTalk estão em um assembly. Isso é o mais fácil de entender e implantar, mas oferece a menor flexibilidade.

Cada artefato do BizTalk está em seu próprio assembly. Isso fornece a maior flexibilidade, mas é o mais complexo de implantar e entender.

Em algum lugar entre "não factoring" e "full factoring" com base na análise aprofundada de seus aplicativos do BizTalk. Além do controle de versão, isso permite que você implemente facilmente o design do Host do BizTalk. Isso é obtido procurando por relacionamentos entre os artefatos do BizTalk. Artefatos que sempre são versionados juntos normalmente podem ser colocados no mesmo assembly. Se versões independentes dos artefatos forem necessárias, elas deverão ser colocadas em diferentes montagens. Este é o nível de fatoração que você deseja alcançar.

Recursos adicionais.

Defina e pratique uma estratégia de versão sólida para garantir que ela forneça estratégias de implantação lado a lado que você possa precisar. Recursos para atualização de aplicativo do BizTalk Server e estratégias de versão incluem o seguinte:

O sistema de feedback para este conteúdo será alterado em breve. Comentários antigos não serão transportados. Se o conteúdo de um tópico de comentário for importante para você, salve uma cópia. Para mais informações sobre a próxima mudança, convidamos você a ler nossa postagem no blog.

Implementando uma estratégia de controle de versão.

Neste artigo.

O controle de versão é o ato de atualizar a implementação de um artefato e incrementar seu número de versão.

Problemas gerais de versão.

A versão do aplicativo BizTalk pode se tornar um problema quando você precisar executar duas versões de uma solução do BizTalk lado a lado, ou se não puder agendar o tempo de inatividade do aplicativo BizTalk para implantar uma nova versão. Se você não precisar executar duas versões da solução simultaneamente (por exemplo, se você não tiver orquestrações de execução longa), será perfeitamente aceitável desimplantar a versão antiga e implantar a nova versão como uma estratégia de versão (nenhuma versão de assembly ). Essa é uma estratégia de versionamento possível, embora ainda seja recomendável incrementar o número da versão do arquivo (para que você saiba qual versão é implantada nos servidores do BizTalk). Para obter mais informações sobre como atualizar um aplicativo implantado, consulte Checklist: atualizando um assembly.

Se você precisar dar suporte a orquestrações de longa execução e / ou precisar executar implantações de aplicativos do BizTalk sem tempo ocioso do aplicativo BizTalk, uma estratégia de versão de BizTalk precisa ser implementada e praticada de ponta a ponta para os diferentes cenários de versão. Isso inclui versões de versões e versões de todos os artefatos do BizTalk. Isso inclui esquemas, mapas, pipelines, componentes de pipeline, orquestrações, adaptadores personalizados, classes personalizadas chamadas em orquestrações e mapas, regras de negócios e BAM. Para obter mais informações sobre versões lado a lado, consulte Atualizando usando o controle de versão lado a lado.

Versionando um Assembly.

Quando você atualiza uma montagem, você pode escolher entre o seguinte:

Escolhendo uma versão de montagem fixa para uma determinada entrega e incrementando apenas o número da versão do arquivo.

Incrementando a versão de montagem e a versão do arquivo durante o desenvolvimento.

Essas abordagens são comparadas na tabela a seguir:

Estratégia de versão de API da Web.

Quando você faz alterações na API, o consumidor deve continuar usando a API da maneira que estava usando antes de as alterações serem feitas. É aqui que o controle de versão é essencial. Essa é uma maneira pela qual a API evolui para adicionar novos recursos a ela sem quebrar a maneira atual de consumi-la. Na minha opinião, isso não é o mesmo que a nova versão do assembly ou nova compilação. O que quer que você mude atrás do qual o consumidor não pode ver na API, não deve exigir a nova versão da API. A nova versão da API só deve ser lançada sempre que “como consumir alterações de peça”. Ex: quando o recurso ou a assinatura muda.

Se a API é um pouco complexa e serve para consumidores de grande variedade, o controle de versão da API é obrigatório. Existem diferentes abordagens. Vou abordar todos eles com relação às abordagens de versionamento da API da Web ASP e sugerir a melhor abordagem. Também tentarei convencer o leitor com os exemplos e justificativas apropriados.

Abordagem nº 1: versionamento de URI.

Vamos adicionar o número da versão ao URI, então esse URI mapeia para o método naquele controlador.

Bastante fácil de implementar. Podemos fazer isso simplesmente usando o atributo de roteamento sobre o método.

Com a abordagem acima, estamos quebrando uma das restrições. O URI representa o recurso e, desde que o recurso não mude, o URI não deve mudar também. Obviamente, o URI para o mesmo recurso não deveria permanecer igual? Se a nova versão do próprio recurso for alterada, o novo URI deverá ser a abordagem válida. Você também pode querer torná-lo acessível em um URI completamente diferente. Nesse contexto, uma nova versão do recurso é um recurso diferente.

Essa abordagem é frequentemente usada. Uma das vantagens disso é a capacidade de exportação do navegador. Podemos acessar as diferentes versões da API da web sem precisar resolver com aplicativos como o Fiddler para enviar solicitações personalizadas à API da web. Assim, podemos categorizar este como uma abordagem pragmática.

Abordagem 2: Negociação de Conteúdo.

No exemplo anterior, obtemos a mensagem como JSON ou XML definindo o tipo de conteúdo como application / json ou application / xml. Por meio do Tipo de conteúdo personalizado no cabeçalho Aceitar, podemos criar tipos de conteúdo personalizados que informarão à API da Web sobre qual versão deve ser retornada no cabeçalho de aceitação.

Aqui você não está apenas mencionando que precisa de dados no formato JSON, mas também informações sobre a versão. Para criar essa API, o prefixo de fornecedor “vnd” deve ser usado. Indica que o tipo de conteúdo é específico do fornecedor e seguido por um identificador personalizado, a versão e o formato do recurso.

Nesta abordagem, é um pouco mais difícil navegar na API no navegador. Para invocar o método da API, a solicitação deve ser criada com o cabeçalho de aceitação apropriado.

Abordagem nº 3: cabeçalho de solicitação personalizada.

A terceira abordagem é o cabeçalho customizado adicionado ao pedido contendo o número da versão. É um tipo de abordagem 2, mas sem o tipo de conteúdo personalizado.

Aqui, a API deve ler o cabeçalho personalizado e, a partir dessa informação, executar a versão correta do código.

É um pouco mais difícil de navegar e a solicitação precisa ser criada com o cabeçalho da solicitação personalizada.

As abordagens descritas acima podem ser usadas em combinação também. Como, versões principais são solicitadas através do URI e as versões secundárias são solicitadas através do cabeçalho da solicitação.

Abordagem nº 4: o controle de versão do parâmetro URI.

É óbvio que não vejo muitas pessoas usando:

Este método é muito usado pela Amazon, Google e Netflix, mas ainda não é tão popular. O cliente sabe sobre qual versão ele quer e o provedor de API da Web não tem problemas para manter várias versões. Quando nenhuma versão é especificada, o cliente obterá a versão mais recente ou padrão. Versões mais recentes não quebram os hiperlinks existentes, pois estamos usando o parâmetro URL e não alteraremos o nome e o local do recurso.

No lado do servidor, isso parece um pouco mais difícil - os servidores precisam analisar toda a cadeia de parâmetros antes de saber para onde encaminhar a solicitação - algo que eles tentam evitar. Além disso, existe o mesmo argumento de não colocar números de versão no URI - os parâmetros são para especificar a função de serviços e não os atributos da implementação.

Exemplos de implementação da API da Web ASP:

Abordagem nº 1:

Tão simples como isso, apenas mudamos a versão no atributo de roteamento. Por isso, gostaria de prestar mais atenção a outras duas abordagens: o tipo de conteúdo personalizado e o cabeçalho de solicitação personalizada.

Abordagem 2:

Quando um consumidor solicita uma representação de recurso para um determinado URI, temos que ler a solicitação de tipo de conteúdo personalizado. Podemos ler o método da API usando Cabeçalhos de Solicitação e executamos o código correto dependendo do que encontramos no cabeçalho, mas fazer isso dentro do método da API não é a melhor maneira, porque a solicitação é finalizada no mesmo controlador e método e então temos que processá-lo.

Essa abordagem é melhor implementada por meio dos atributos do Custom Route Factory e da restrição de roteamento customizada. Na restrição personalizada, poderemos verificar o cabeçalho de aceitação ou o cabeçalho da solicitação personalizada, pois vamos implementar os dois tipos de versão. Os atributos Fábrica de Rota Personalizada usarão essa restrição e cada restrição terá a oportunidade de impedir a rota da solicitação especificada.

Vamos criar um atributo de fábrica de rota personalizada, uma rota com versão que adicione uma restrição a cada rota de atributo e, em seguida, evite potencialmente a rota. Isso nos permitirá decorar o controlador ou um método específico no controlador com esse atributo.

Se a solicitação corresponder à nossa lógica de restrição, ela permitirá que a rota correta evite a rota. Para implementar de forma genérica, tenho uma versão modificada da classe personalizada “Version Constraint”.

Método da API da Web após a implementação das classes sobre.

Exemplo para o tipo de conteúdo personalizado da abordagem 2 no cabeçalho de aceitação:

Método de amostra GET versão 1 para controle de versão com tipo de conteúdo personalizado no cabeçalho:

(o exemplo de invocação da versão 1 é semelhante para a Abordagem 2 e a Abordagem 3)

Execução: a solicitação com a API / report / 1 URI version # 1 será invocada.

Agora, os pedidos com a versão 1 corresponderão à rota acima. Como mencionamos a versão como nº 1 e sua versão padrão, se não passarmos a versão no cabeçalho, a versão padrão # 1 será executada.

Método de amostra GET versão 2 para controle de versão com tipo de conteúdo personalizado no cabeçalho de aceitação:

Execução: agora para invocar a versão 2, no cabeçalho da solicitação personalizada,

use o mesmo URI de chamada recebida: API / report / 1.

Aceite: application / vnd. ServiceAPIname. v2 + json (sepecify no cabeçalho de aceitação não no URI)

agora ele invocará o método get da versão nº 2.

Método de amostra GET versão 1 para controle de versão com cabeçalho de solicitação personalizado:

Execução: a solicitação com a API / report / 1 URI version # 1 será invocada.

Agora, os pedidos com a versão 1 corresponderão à rota acima. Como mencionamos a versão como nº 1 e sua versão padrão, se não passarmos a versão no cabeçalho, a versão padrão # 1 será executada.

Método de amostra GET versão 2 para controle de versão com cabeçalho de solicitação personalizado:

Execução: agora para invocar a versão 2, no cabeçalho da solicitação personalizada,

use o mesmo URI de chamada recebida: API / report / 1.

Versão da API: 2 (especifique no cabeçalho da solicitação, não no URI)

agora ele invocará o método da versão 2.

O Facebook e o Twitter estão usando uma parte da URL que vem antes da definição do Serviço de API e antes da própria definição de recurso (por exemplo, exemplo / v2.7 /) porque pode-se dizer que a URL inteira é o identificador de recurso.

No entanto, alguns podem dizer que o identificador de recursos é apenas o e o que vem antes disso é o identificador HOST e o API SERVICE. É um pouco mais claro ao usar a API do Twitter: api. twitter / 1.1 / blocksabc, aqui o HOST = api. twitter, o API Service = blocos e a versão do Serviço da API que vem antes da definição do Serviço da API 1.1.

Conclusão.

Todos os esquemas de versão são problemáticos se não houver necessidade. O controle de versão é desnecessário se os clientes forem muito poucos. Por exemplo, equipes com apenas um cliente insistem em um esquema de controle de versão que é ridículo. O tipo de recurso não deve ser alterado de forma a quebrar a compatibilidade com versões anteriores. Eu vi em muitos projetos usando "V1" na URL do recurso, como "v1 / GetData" e nunca muda para "V2". Nestes cenários, o versionamento é desnecessário.

Eu prefiro o Approach # 3 & # 8211; cabeçalho personalizado por um motivo forte. Vou justificar porque não gosto de outros. Os relacionamentos de URL são ótimos para controle de versão quando envolvem alterações de recursos e comportamentos (digamos que você mude de "usuário" para "cliente", que agora realiza um processo de faturamento e de email de back-end, mas não altera a estrutura do próprio recurso). Mas e se você precisar alterar algo em uma camada diferente, como passar do OAuth 1.0 para o OAuth 2.0? Ou você está fazendo um pivô como empresa? Ou algo mais que eu nem pensei ainda? Não gosto que a URL se aproxime porque eles simplesmente fazem algo sobre a representação de recursos em que o cabeçalho é, novamente, em uma camada muito mais alta. Espero nunca mudar a versão do cabeçalho, mas tê-la como um parâmetro obrigatório garante que nunca quebremos a integração que não especificar o que deseja. Facebook e Twitter fizeram isso e não foi bem recebido pela comunidade de desenvolvedores. A primeira solicitação à nossa API torna esse parâmetro obrigatório claro em uma resposta de erro e, depois de manipulado, nunca mais é lembrado. Como você disse, os proxies hoje lidam bem com isso. Eu também li que podemos abandonar a convenção "X", já que não estamos pensando que nosso cabeçalho personalizado estará sempre a caminho de ser globalmente aceito.

Use um cabeçalho HTTP personalizado, especialmente quando o controle de versão é necessário em um nível de serviço da API e não em um nível de recurso.

Recomendo implementar o controle de versão da abordagem nº 3 por meio do cabeçalho de solicitação personalizada. Não quebramos os princípios de manutenção de recursos e recursos que ocorrem no controle de versões de URI. Dessa forma, podemos integrar a versão incorporada à API da web sem interromper os consumidores que desejam acessar versões antigas. Consumidor nunca enfrenta a complexidade do controle de versão no URI, em vez disso, ele especifica no cabeçalho da solicitação, mas mais se não especificar a versão, pelo menos, a versão padrão enviará a resposta. Assim, evita os conflitos de URI de rotas inacessíveis.

Biblioteca para suporte de versão API no Microsoft ASP Web API está disponível como um pacote NuGet. Para instalar o suporte de versão da API da Web ASP, execute o seguinte comando no Console do Gerenciador de Pacotes.

PM & gt; Install-Package SDammann. WebApi. Versioning - Version 2.8.0.

Métodos GET com versão mais alta não podem ser acessados ​​via navegador. Em vez disso, é necessária uma ferramenta de depuração da Web, como o Fiddler, para construir o cabeçalho da solicitação com o número adequado da versão da API.

Essa abordagem pode ser bastante problemática quando você está usando os gateways de API. Quando você envia o cabeçalho "api-version", pode causar algum erro a qual API exatamente você está se referindo - o Serviço de API que é seu Gateway de API (que pode ser versionado por ele) ou o Serviço de API da Web que deve receber a chamada do gateway da API.

Richard Seroter & # 8211; SoCal BizTalk Musings Richard Seroter & # 8211; Reflexões do SoCal BizTalk.

Blog com dicas, código e orientação para o BizTalk Server, Commerce Server e Host Integration Server da antiga Microsoft Technology Specialist BizTalk do sul da Califórnia. Para novos lançamentos, confira seroter. wordpress.

Estratégia de versionamento para assemblies do BizTalk.

Eu gastei um pouco de tempo hoje revisando algumas práticas recomendadas para a versão de montagem em aplicativos do BizTalk, e queria também obter feedback da comunidade.

Uma das primeiras coisas que um novo desenvolvedor do BizTalk é informado ao criar uma solução do BizTalk é não empinar todos os vários artefatos em um único projeto. Muitas vezes, o desenvolvedor será instruído a colocar esquemas em um projeto, mapas em outro, pipelines em outro e, finalmente, orquestrações em um projeto isolado. Eu me tornei menos fã dessa estrutura rígida. Mas primeiro, vamos ver como eu faria uma atualização de uma solução configurada dessa maneira.

Estou começando com um projeto simples, contendo um único arquivo de esquema. A mensagem parece com isso:

Eu construí e implantei este projeto e construí um simples "receive location" e "send port" onde a porta de envio tinha uma assinatura / filtro no BTS. MessageType. Eu testei, e tudo viaja muito bem.

Em seguida, construí uma orquestração simples que toma uma decisão e grava no log de eventos. Se parece com isso:

Eu fiz referência ao projeto de esquema, construí, implantei e testei a orquestração com sucesso. O próximo passo foi criar uma nova versão do esquema. Então, adicionei um nó "Status" e alterei a versão de montagem.

Eu então reconstruí e implantei o projeto do esquema. Agora, dado que você foi constantemente informado de que namespace # root tem que ser único, a imagem abaixo pode lhe preocupar.

Se você quiser ler mais sobre como os pipelines resolvem os esquemas, leia aqui. Portanto, você pode esperar que eu receba uma espécie de erro de "referência ambígua" quando tento enviar a mensagem de entrada agora. No entanto, quando eu solto o arquivo, a orquestração ainda o pega, o processa e continua seu caminho alegre. Mas o que acontece se eu "interromper" a orquestração para que eu possa ver a mensagem em andamento e investigar a propriedade SchemaStrongName atribuída pelo pipeline? O que você vê é isto:

Surpresa. O esquema foi resolvido para a versão mais recente, e THIS é o arrancado pela orquestração. Isso me surpreendeu um pouco. Eu teria esperado que a porta de envio contendo o filtro BTS. MessageType extraísse a versão mais recente do esquema, uma vez que ele só se importava com "tipo", mas eu achava que a orquestração só pegaria a versão explicitamente referenciada. Agora, se eu tentar remover o assembly de esquema "1.0" por meio do Admin Console, recebo um erro informando que a orquestração está fazendo referência a ele.

Então, para se livrar do projeto de esquema "1.0", eu teria que reverter o projeto Orchestrations com uma compilação atualizada. Em seguida, após a transição para a nova orquestração "1.1", eu poderia remover seguramente os assemblies herdados.

Agora, se eu usei um pipeline de recebimento personalizado, ENTÃO, parece que posso ditar a versão do esquema que a orquestração consome (esquema antigo ou novo esquema). Eu testei isso colocando um pipeline de recebimento (com componentes XML Disassembler e Validator) no projeto com o esquema. Eu implantei isso (versão 1.0 novamente). Então, eu levantei a versão para "1.1" e construí e implantei. So, now I have schema/pipeline projects for "1.0" and "1.1" and an orchestration project still built with "1.0".

By switching the pipeline, the orchestration would grab specific versions of the schema. For instance, if I dropped a "1.0" message (no "Status" field) when the "1.0" pipeline was selected, everything ran fine. If I dropped a "1.1" message with the "1.0" pipeline still in place, I got a suspended message. Same situation when I flipped to the "1.1" pipeline. The orchestration consumed either the "1.0" OR "1.1" message.

So, any conclusions here? Changing Assembly Version has broad impact, regardless of how you've factored your projects. One recommendation I've seen is to only change the Assembly File Version so that you still have an incremented build number, but the core version stays the same (allowing for lower impact changes). However, that could get dicey if you are truly introducing breaking changes. You'll also see recommendations to version schemas by changing the namespace#root combination (e. g. changing the namespace to Microsoft. Project. BizTalkStuff. v1 ). Of course then you HAVE to change all the dependent artifacts (maps, pipelines, orchestrations) because you've made a core modification.

This leads me to a solution structure that is less segmented by artifact type , but more by artifact relevance . That is, group related artifacts in the same project. You still may have a "base schemas" project, but it's also ok to have a subsequent project that contains a few schemas, maps and orchestrations. Try and group the items that will change and version together. Now if I have to version the schema, I can fairly naturally version the sibling artifacts and deploy fewer assemblies.

So I ask you : any other versioning strategies that you prefer when you want to lessen the impact of production modifications? How do you like organizing your solution structure? If you only have to make a slight change, how do you prevent the rebuild of every dependent project?