Estratégia de versão do biztalk

Fralda BizTalk.
Contos da fronteira da integração:
"Como é que quando ninguém sabe e não faz sentido, eles vem até nós?"
venerdì, gennaio 07, 2011.
Estratégia de versão do BizTalk (1/4)
Como disse no post anterior, o gerenciamento de soluções BizTalk pode ser uma tarefa desafiadora devido à complexidade do processo de atualização de artefatos do biztalk.
O BizTalk faz o seu melhor para evitar a possibilidade de deixar o sistema em um estado inconsistente e isso é uma coisa boa, mas fazendo isso lança o fardo de um fluxo de trabalho de implantação incrivelmente burocrático no desenvolvedor, mesmo quando é claramente desnecessário.
Deixe-nos fazer o seguinte caso não-tão hipotético:
Eu possuo uma orquestração (contida em uma assemblagem 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 BizTalk em diferentes montagens e melhorou um pouco (separando ainda mais artefatos para processos e sistemas) para detectar facilmente o impacto de nossas futuras modificações 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 System1.schemas. dll, precisamos:
Como você está atualizando uma dll de esquema, você deve removê-la. Como o esquema é usado nos mapas, você precisa remover mapas que o estão usando (ProcessA. maps. dll). Como os mapas são usados ​​na orquestração, você precisa remover também orquestrações (ProcessA. orchestrations. dll). Para remover uma assembléia de orquestra, você precisa inscrever todas as orquestrações nele contidas. Para descompactar todas as orquestrações, você deve encerrar todas as instâncias do serviço que as fazem referência. Se a orquestração estiver vinculada a uma porta física, você precisa parar & amp; unenlist todas as portas relacionadas. Se os mapas forem usados ​​em uma porta, você precisará remover mapas de cada porta onde ele é usado. Finalmente você pode implantar o esquema. Mas depois que você precisa redistribuir também os mapas que você removeu (ProcessA. maps. dll) Mas, depois de precisar redistribuir também as orquestrações que você removeu (ProcessA. orchestrations. dll) Você deve se lembrar de recrutar novamente a orquestração. Você deve se lembrar de alistar / começar a receber / enviar portas Você precisa definir mapas nas portas de recebimento / envio que foram removidas.
Uma maldita longa seqüência de etapas, especialmente considerando que eu fui forçado a redetizar completamente o ProcessA quando eu 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 mudanças eram compatíveis com versões anteriores, mas, por padrão, o biztalk assume que elas não são e isso causa o problema.
Um pouco injusto.
Eu sei, acima, voluntariamente omiti um pouco de coisas que tornaram a vida mais fácil e eu vou corrigir aqui adicionando também as razões pelas quais eu não considero uma solução para eles.
Usando o & # 8220; Modify & # 8221;
Se você selecionar um recurso no Console de Administração BizTalk e pressionar a tecla direita do mouse, você notará um & # 8220; Modificar & # 8230; & # 8221; voz no menu pop-up.
Esta opção nos leva a uma janela de diálogo quase idêntica à & # 8220; Add & # 8211; & gt; New BizTalk Assembly & # 8230; & # 8221;
Mas com uma diferença: se decidimos & # 8220; Refresh & # 8221; a assembléia com uma nova, BizTalk tornou-se mais inteligente e nos permitirá implantar o novo sem remover o antigo. Portanto, no cenário superior, todas as listas de etapas que eu relatei poderiam ser evitadas simplesmente usando Modificar em vez do clássico & # 8220; Adicionar & # 8211; & gt; New BizTalk Assembly & # 8211; & gt; Substituir & # 8221;
Por que a equipe BizTalk decidiu implementar um comportamento tão diferente para estas duas opções quase idênticas (Adicionar com substituição e Modificar) é um mistério para mim, mas desde que eu saiba que a diferença está lá, é bom para mim.
Então o problema foi resolvido?
Não, definitivamente não e por dois (IMHO bom) razões:
A opção Modificar não tem equivalente em linha de comando, o BTSTask. exe, de fato, tem apenas a alternativa AddResource / Overwrite, o que nos deixa incapazes 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 existirem dependências inter-aplicações, mas falharem miseravelmente (com o mesmo problema de AddResource com Substituir) se houver alguma referência de aplicativo.
O segundo motivo precisa de uma explicação melhor: digamos para o projeto acima, eu definei diferentes aplicativos como o comum (contendo todos os componentes comuns, como esquemas, funções auxiliares, etc.) ProcessA (que contém orquestrações, portas e mapas pertencentes a ProcessA ) e assim por diante.
Obviamente ProcessA Application irá fazer referência a Aplicativo comum e quando tentamos modificar o schema. dll em comum (exatamente como fizemos anteriormente quando todos os processos em que no mesmo aplicativo) obtivemos uma falha conforme descrito abaixo.
Aumentando a versão da montagem.
Outra solução poderia ser simplesmente aumentar a versão de montagem da dll de esquemas modificados (vamos dizer entre 1.0.0.0 e 1.0.0.1).
O BizTalk permite uma implantação lado a lado de montagens (mais sobre isso mais tarde) e, portanto, esta poderia ser a solução que procuramos:
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 (portanto, contém o novo esquema)
Isso pode parecer funcionar, mas, mais cedo ou mais tarde (se você usar orquestrações), você enfrentará uma exceção similar.
Para entender por que (e quando) esta exceção será levantada e como podemos resolver o problema uma vez por todas, precisamos examinar profundamente o mecanismo de resolução do BizTalk.

Fralda BizTalk.
Contos da fronteira da integração:
"Como é que quando ninguém sabe e não faz sentido, eles vem até nós?"
lunedì, gennaio 10, 2011.
Estratégia de versão do BizTalk (3/4)
Versão.
Então, todos os problemas parecem ser o fato de que a orquestração está fortemente acoplada aos tipos que representam esquemas de mensagens e, portanto, eles não podem executar se forem alimentados com Tipo incorreto.
Na verdade, reduzimos o problema de estratégia do BizTalk Versioning para um Versioning normal:
Nós implantamos um aplicativo (nossa orquestração) referenciando tipos contidos em outra montagem (nossos esquemas, v1.0.0.0). Nós implantamos uma nova versão deste assembly referenciado (v1.0.0.1). Será que o nosso aplicativo continuará funcionando não afetado ao receber tipos 1.0.0.1 em vez de 1.0.0.0?
Na verdade, como mostramos aqui,
A versão específica de uma montagem e as versões dos conjuntos dependentes são registradas no manifesto da montagem. A política de versão padrão para o tempo de execução é que os aplicativos são executados apenas com as versões com as quais eles foram criados e testados.
Então, a resposta parece ser um som não, mas, continuando a ler:
a menos que seja substituído pela política de versão explícita nos arquivos de configuração (o arquivo de configuração do aplicativo, o arquivo de política do editor e o arquivo de configuração do administrador do computador).
Então, existe uma maneira: por padrão, a orquestra falhará (porque receberá tipo inesperado), mas podemos substituir esse comportamento simplesmente declarando explicitamente a política de versão!
A página acima sugeriu 3 abordagens, deixe-as examiná-las em detalhes:
Arquivo de configuração do aplicativo.
Essa abordagem consiste em colocar diretivas de redirecionamento diretamente dentro do arquivo de configuração do aplicativo.
Isso significa que devemos colocar nosso redirecionamento de 1.0.0.0 para 1.0.0.1 diretamente dentro do arquivo BTSNTSvc. exe. config.
Eu não gosto de mexer com o arquivo de configuração de aplicativo BizTalk e ele é errado, mesmo do ponto de vista lógico: esse tipo de redirecionamento é pensado para os desenvolvedores de aplicativos (que neste caso é o grupo de produtos BizTalk) para afirmar explicitamente (na configuração do aplicativo) que o programa funcionará com esses redirecionamentos de versão de montagem. Mas eu não desenvolvi o BizTalk Server, eu simplesmente desenvolvi alguns componentes hospedados no BizTalk Server.
Então, eu não gosto muito desta abordagem.
Arquivo de configuração do administrador do computador.
Essa abordagem consiste em colocar diretivas de redirecionamento dentro do arquivo de configuração da máquina.
Se possível, eu gosto dessa abordagem menos do que a anterior pelas mesmas razões:
Se eu não gostaria de mexer com o BizTalk Configuration File, você pode imaginar o quanto eu odeio mexer com o Machine. config inteiro.
E, do ponto de vista lógico, esse tipo de redirecionamento é pensado para os administradores de sistema da máquina e eu também não sou um desenvolvedor que tenha componentes hospedados naquela máquina.
Arquivo de política do editor.
Essa abordagem, um pouco mais complexa do que as duas anteriores, consiste em gerar um arquivo de assembly de política dupla que, quando implantado em conjunto com a montagem original, habilite o redirecionamento.
Esta é a melhor abordagem para um desenvolvedor do biztalk: ele é usado por um desenvolvedor de componentes (e nós / desenvolvedores de componentes) para indicar que um componente é compatível com outra versão do mesmo (e isso é exatamente o que nós & # 8217; está tentando fazer).
Compreender como gerar um Arquivo de Política do Editor está fora do tópico para esta publicação (muito longa), mas eu coloquei no MSDN Code Gallery um script do powershell que deve ajudá-lo a produzir os arquivos de política do editor.
Minha política de versão de esquema é, portanto, a seguinte:
Cada vez que eu fiz uma mudança (compatível para trás) em um esquema (como adicionar um campo a um esquema existente ou adicionar um novo esquema à montagem), eu simplesmente aumento o número de versão ou compilação.
O meu processo de compilação irá criar os artefatos de esquema recém-alterados produzindo também o arquivo de política do editor (usando uma versão ligeiramente modificada do script que eu liguei acima).
Então, na caixa BizTalk, eu implanto a nova versão dos esquemas (não é necessário criar uma orquestração ou remover artefatos porque eu simplesmente adiciono um novo esquema lado a lado).
Posteriormente, coloco o arquivo de política do editor correspondente aos novos esquemas.
Tivemos um tempo de inatividade zero (nós apenas implantamos novos artefatos, nem paramos nem removemos os antigos) e o efeito líquido é que agora cada artefato de biztalk (orquestração, mapas, pipelines, etc.) usará o artefato mais novo (e compatível com versões anteriores) sem problemas .
1 commento:
O link para o seu script do powershell está quebrado, você pode publicar o script em um novo local.

Estratégias de atualização e versão para aplicativos.
Neste artigo.
O controle de versão do aplicativo BizTalk pode se tornar um problema quando você precisa executar duas versões de uma solução BizTalk lado a lado, ou se você não pode usar o tempo de inatividade do aplicativo BizTalk para implantar uma nova versão. Se você não precisa executar duas versões da solução simultaneamente (por exemplo, onde você não possui orquestrações de longa duração), e as janelas de manutenção do serviço estão disponíveis, é perfeitamente aceitável implantar a versão antiga e implementar a nova versão como uma estratégia de versão (sem versão de montagem). Esta é uma possível estratégia de versão, embora ainda recomendamos 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 Versioning.
Se você precisar suportar orquestrações de longa duração e / ou você precisa executar implantações de aplicativos BizTalk sem tempo de inatividade do aplicativo BizTalk, então você precisa implementar e praticar uma estratégia de controle sólida, de ponta a ponta do BizTalk Server para os diferentes cenários de versão . Isso inclui o controle de versões e o controle de versão de todos os artefatos BizTalk, que 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.
O controle de esquema é exclusivo porque as pipelines do BizTalk Server determinam o tipo de mensagem de uma mensagem com base no espaço de nomes de destino mais o nome do nó raiz definido no esquema. Para obter mais informações, consulte Resolução de Esquema em Componentes de Pipeline. Se você precisa editar seus esquemas, um indicador de versão deve fazer parte do espaço para nome do destino. Alterar a versão do esquema tem um efeito de ondulação em toda a sua solução e, portanto, deve ser planejado com antecedência. Ao criar mensagens de orquestração, procure Servidor BizTalk: 8 dicas e truques para melhor programação BizTalk (dica 1: use sempre tipos de mensagens em várias partes). O uso deste método oferece maior flexibilidade quando esquemas de versão.
Usando o Factoring para o Versioning Assembly.
Se você precisar suportar orquestrações de longa duração, implantações lado a lado ou atualizações sem interrupção, então você deve implementar uma versão de versão e empacotamento de montagem. Para executar a versão de montagem de artefatos do BizTalk, as assemblies de soluções do BizTalk precisam ser fatoradas (embaladas) de forma a permitir o controle de versões do BizTalk Server. Existem três tipos de factoring:
Todos os artefatos BizTalk estão em uma montagem. Este é o mais fácil de entender e implantar, mas fornece a menor flexibilidade possível.
Cada artefato BizTalk está em sua própria montagem. Isso proporciona a maior flexibilidade, mas é o mais complexo para implantar e entender.
Em algum lugar no meio de "nenhum factoring" e "factoring grande", baseado na análise aprofundada de seus aplicativos BizTalk. Além do controle de versão, isso permite que você implemente facilmente o design do BizTalk Host. Isto é conseguido procurando por relacionamentos entre artefatos BizTalk. Os artefatos que são sempre atualizados juntos normalmente podem ser colocados na mesma montagem. Se for necessário um controle de versão independente dos artefatos, eles devem ser colocados em montagens diferentes. Este é o nível de factoring que deseja alcançar.
Recursos adicionais.
Defina e pratique uma estratégia de controle de versão sólida para garantir que ele forneça estratégias de implantação lado-a-lado que você possa precisar. Os recursos para estratégias de atualização e atualização de aplicativos do BizTalk Server incluem o seguinte:

estratégia de versão do Biztalk
Eu tenho um aplicativo que já foi implantado no nome "Applicaiton1 & quot; com o nome da montagem como "Assembly1". Agora eu preciso implementar o mesmo aplicativo sob o nome e o nome da montagem e o nome da montagem. Isso é possível ou quais erros eu enfrentaria tentando implantar.
Tenho esquemas, orquestração em projetos separados. O projeto de esquema é adicionado como uma referência ao projeto de orquestração. E eu tenho um aplicativo implantado. Agora eu quero criar um novo aplicativo e definir o biztalk para escolher uma determinada versão da mesma dll. Como isso pode ser conseguido?
Sobre isso, consulte o documento:
#Vionando seu aplicativo BizTalk.
#Versioning Strategy for BizTalk Assemblies.
Estamos tentando entender melhor as opiniões dos clientes sobre a experiência de suporte social, então sua participação neste projeto de entrevista seria muito apreciada se você tiver tempo. Obrigado por ajudar a tornar os fóruns comunitários um ótimo lugar.
Clique AQUI para participar da pesquisa.
Marcado como resposta por Vivin Muthu quarta-feira, 01 de outubro de 2014 às 6:21.
Todas as respostas.
Sobre isso, consulte o documento:
#Vionando seu aplicativo BizTalk.
#Versioning Strategy for BizTalk Assemblies.
Estamos tentando entender melhor as opiniões dos clientes sobre a experiência de suporte social, então sua participação neste projeto de entrevista seria muito apreciada se você tiver tempo. Obrigado por ajudar a tornar os fóruns comunitários um ótimo lugar.
Clique AQUI para participar da pesquisa.
Marcado como resposta por Vivin Muthu quarta-feira, 01 de outubro de 2014 às 6:21.
Primeiro, explique um pouco sobre por que você quer fazer isso.
& quot; nome e nome da montagem e versão & quot ;. Bem, essa seria uma aplicação completamente diferente até. Então, o que você está perguntando não é muito claro.
Se você compartilhar metas, podemos oferecer algumas orientações.
A Microsoft está conduzindo uma pesquisa on-line para entender sua opinião sobre o site da Msdn. Se você optar por participar, a pesquisa on-line será apresentada quando você deixar o site Msdn.

estratégia de versão do Biztalk
O meu cliente está me pedindo para nos dar o documento de gerenciamento de configurações e configuração de artefatos do BizTalk. it deve conter a estratégia / abordagem recomendada para o controle de versão de mensagens / esquemas / artefatos, lidar com várias mensagens de versão para manipular ou evitar alterações em interfaces etc. deixe-me saber se alguém tem esse documento com você.
Por favor, ajude o tipo de TOC no documento acima deve conter e compartilhar se qualquer coisa tiver um tipo similar de doc ASAP.
Bem, esse link ainda está quebrado. Estes são para BizTalk Server 2009. Eles são essencialmente os mesmos.
Marcado como resposta por Pengzhen Song Segunda-feira, 12 de maio de 2014 9:07.
Todas as respostas.
Aqui estão alguns bons artigos que podem ajudá-lo a criar o documento:
Se isso responder a sua pergunta, marque como resposta. Se esta postagem for útil, vote como útil clicando na seta para cima ao lado da minha resposta.
Todas essas são ótimas referências. No entanto, tenha em mente que as aplicações BizTalk são efetivamente aplicativos para que todas as regras de versão se apliquem.
Quando perguntei esta pergunta, peço suas políticas de versão do aplicativo para. Se eles não tiverem um, então, ter uma política para BizTalk será praticamente impossível de impor.
A menos que você esteja lidando com um padrão publicado, SWIFT ou HIPAA, por exemplo, a decisão sobre quando e como rev um aplicativo de integração é sempre caso a caso, portanto, concentre-se em cobrir os temas gerais, controle de origem, práticas de implantação, controle de mudança, etc.
Não é realmente porque só você saberia o que tratar para satisfazer o requisito. Não há muito para isso: msdn. microsoft/en-us/library/gg608149.aspx.
O único "caso especial" pode ser uma definição de esquema para a qual você teria que incluir um indicador de versão no espaço para nome.
Quanto ao TFS, não há nenhum ponto em ter uma "estratégia" para o BizTalk. O TFS não trata os projetos BizTalk de forma diferente de qualquer outro projeto, então a resposta é definitivamente ", seguiremos as políticas de controle de origem existentes (TFS)".
Bem, esse link ainda está quebrado. Estes são para BizTalk Server 2009. Eles são essencialmente os mesmos.
Marcado como resposta por Pengzhen Song Segunda-feira, 12 de maio de 2014 9:07.
A Microsoft está conduzindo uma pesquisa on-line para entender sua opinião sobre o site da Msdn. Se você optar por participar, a pesquisa on-line será apresentada quando você deixar o site Msdn.

Estratégia de versão de API da Web.
Quando você faz alterações na API, o consumidor deve poder continuar usando a API da maneira que eles estavam usando antes que as alterações fossem feitas. É aqui que o controle de versão é essencial. Esta é 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 de montagem ou nova compilação. Tudo o que você muda por trá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 mudanças nas partes". Ex: quando o recurso ou a assinatura são alterados.
Se a API é um pouco complexa e serve para consumidores de ampla gama, o controle de API é uma obrigação. Existem diferentes abordagens. Vou abordar todos eles no que diz respeito às abordagens de versão do ASP Web API e sugerirei a melhor abordagem. Também tentarei convencer o leitor com os exemplos apropriados e a justificativa.
Abordagem nº 1: versão URI.
Vamos adicionar o número da versão ao URI, então esse URI mapeia o método para esse controlador.
Muito fácil de implementar. Podemos fazê-lo 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 enquanto o recurso não mudar, o URI não deve mudar também. Claro, não deveria o URI para o mesmo recurso ficar igual? Se a nova versão do próprio recurso mudar, o novo URI deve 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 é freqüentemente usada. Uma das vantagens com isso é a exportabilidade do navegador. Podemos acessar as diferentes versões da API da Web sem ter que resolver com aplicativos como o Fiddler para enviar solicitações personalizadas para a API da Web. Então, podemos categorizar este como uma abordagem pragmática.
Abordagem # 2: Negociação de conteúdo.
No exemplo anterior, recebemos a mensagem como JSON ou XML definindo o tipo de conteúdo como application / json ou application / xml. Através do tipo de conteúdo personalizado no cabeçalho de aceitação, podemos criar tipos de conteúdo personalizados que informarão a API da Web sobre qual versão retornar no cabeçalho de aceitação.
Aqui, você não menciona apenas que você precisa de dados no formato JSON, mas também informações sobre a versão. Para criar essa API, o prefixo do fornecedor "vnd" deve ser usado. Isso indica que o tipo de conteúdo é específico do fornecedor e seguido de um identificador personalizado, a versão e o formato do recurso.
Nesta abordagem, é um pouco mais difícil procurar a 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 personalizado adicionado à solicitação 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, execute a versão correta do código.
É um pouco mais difícil procurar e a solicitação deve ser criada com o cabeçalho de solicitação personalizado.
As abordagens descritas acima também podem ser usadas em combinação. Como, as principais versões são solicitadas através do URI e as versões menores são solicitadas através do cabeçalho da solicitação.
Abordagem nº 4: a versão do parâmetro URI.
Este é um óbvio que eu não vejo muitas pessoas usando:
Este método é altamente utilizado pela Amazon, Google e Netflix, mas ainda não é tão popular. O cliente sabe sobre a versão que ele deseja e o provedor da API na Web não tem nenhum problema para manter várias versões. Quando nenhuma versão é especificada, o cliente receberá a versão mais recente ou padrão. As versões mais recentes não quebrarão hiperlinks existentes, pois estamos usando o parâmetro URL e não alteraremos o nome e a localização 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 onde rotear o pedido - algo que eles tentam evitar. Além disso, há o mesmo argumento que não colocar números de versão no URI - os parâmetros são para especificar a função de serviços não atributos da implementação.
Exemplos de implementação da API Web ASP:
Abordagem # 1:
Tão simples quanto isso, apenas mudamos a versão no atributo de roteamento. Então, eu gostaria de prestar mais atenção a outras duas abordagens Tipo de conteúdo personalizado e cabeçalho de solicitação personalizada.
Abordagem # 2:
Quando um consumidor solicita uma representação de recursos para uma determinada URI, devemos ler a solicitação de tipo de conteúdo personalizado. Podemos ler no método da API usando cabeçalhos de solicitação e nós 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 termina no mesmo controlador e método e então devemos processá-lo.
Esta abordagem é melhor implementada através de atributos Custom Route Factory e restrição de roteamento personalizada. Na restrição personalizada, poderemos verificar o cabeçalho de aceitação ou o cabeçalho de solicitação personalizado, pois vamos implementar ambos os tipos de versões. Os atributos Custom Route Factory usarão então essa restrição e cada restrição terá a oportunidade de impedir a rota da solicitação dada.
Vamos criar um atributo de fábrica de rotas personalizado, uma rota de versão que adiciona uma restrição a cada rota de atributos e, em seguida, potencialmente impede 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, então ela permite que a rota correta evite a rota. Para implementar de forma genérica, tenho uma versão modificada da classe personalizada "Restrição de versão".
Método da API da Web após a implementação das classes sobre.
Exemplo para o tipo de conteúdo personalizado do Approach # 2 em aceitar o cabeçalho:
Exemplo do método GET versão 1 para 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 Abordagem # 3)
Execução: pedido com API / relatório / 1 URI versão # 1 será invocada.
agora os pedidos com a versão # 1 coincidirão com a rota acima. Como mencionamos a versão como # 1 e é uma versão padrão, se não passamos a versão no cabeçalho, a versão padrão # 1 é executada.
Exemplo de método GET versão 2 para versão com tipo de conteúdo personalizado em aceitar cabeçalho:
Execução: agora para invocar a versão # 2, no cabeçalho de solicitação personalizado, especifique,
use o mesmo aviso URI: API / report / 1.
Aceitar: application / vnd. ServiceAPIname. v2 + json (sepecify em aceitar o cabeçalho não no URI)
agora invocará o método de obtenção da Versão # 2.
Exemplo de método GET versão 1 para versão com cabeçalho de solicitação personalizado:
Execução: pedido com API / relatório / 1 URI versão # 1 será invocada.
agora os pedidos com a versão # 1 coincidirão com a rota acima. Como mencionamos a versão como # 1 e é uma versão padrão, se não passamos a versão no cabeçalho, a versão padrão # 1 é executada.
Exemplo de método GET versão 2 para versão com cabeçalho de solicitação personalizado:
Execução: agora para invocar a versão # 2, no cabeçalho de solicitação personalizado, especifique,
use o mesmo aviso URI: API / report / 1.
Versão da API: 2 (especifique no cabeçalho da solicitação não no URI)
agora 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 da API e antes da própria definição do recurso (por exemplo, exemplo / v2.7 /), porque pode-se dizer que toda a URL é o identificador do recurso.
No entanto, alguns podem dizer que o identificador de recurso é apenas o que e o que vem antes, o HOST e o identificador do SERVIÇO DA API. É um pouco mais claro ao usar a API do Twitter: api. twitter / 1.1 / blocksabc, aqui o HOST = api. twitter, 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ões são problemáticos se não houver necessidade. A versão não é necessária se os clientes forem muito poucos. Por exemplo, as equipes com apenas um cliente insistem em um esquema de versão que é ridículo. O tipo de recurso não deve ser alterado de forma a que ele quebra a compatibilidade com versões anteriores. Eu vi em muitos projetos usando "V1" no URL do recurso, como "v1 / GetData" e nunca muda para "V2". Nesses cenários, a versão de versão é desnecessária.
Eu prefiro abordagem # 3 e # 8211; cabeçalho personalizado por uma razão forte. Vou justificar porque não gosto dos outros. As relações de URL são ótimas para versões quando envolvem mudanças em recursos e comportamentos (digamos que você passa de "usuário" para "cliente", que agora faz um processo de cobrança e envio de endereços, mas não altera a estrutura do próprio recurso). Mas e se você precisar mudar algo em uma camada diferente, como ir de OAuth 1.0 para OAuth 2.0? Ou você está fazendo um pivô como empresa? Ou ainda não pensei em mais? Eu não gosto do URL abordar porque eles simplesmente fazem algo sobre a representação de recursos onde como um cabeçalho é, novamente, em uma camada muito maior. Espero que nunca mude o nosso controle de cabeçalho, mas ter isso como um parâmetro necessário garante que nunca vamos quebrar a integração que não especificam o que eles querem. Facebook e Twitter fizeram isso e não foi bem recebido pela comunidade de desenvolvedores. O primeiro pedido para a nossa API torna este parâmetro obrigatório claro em uma resposta de erro e, uma vez que é tratado, nunca mais pensou em outra vez. Como você disse, os proxies hoje lidar com isso, é bom. Eu também li que podemos deixar a convenção "X-", pois não estamos pensando que o nosso cabeçalho personalizado estará sempre no caminho para ser aceito globalmente.
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.
Eu recomendo implementar a versão 3 do encaminhamento através do cabeçalho de solicitação personalizado, não quebramos os princípios de manutenção de recursos e recursos que ocorrem no controle de versão URI. Desta forma, podemos integrar a versão integrada com a API da Web sem interromper os consumidores que desejam acessar versões antigas. O consumidor nunca enfrenta a complexidade do controle de versão no URI em vez disso, eles o especificam no cabeçalho da solicitação, mas mais se eles não especificam a versão pelo menos a versão padrão enviará a resposta. Assim, evita os conflitos URI de rotas inacessíveis.
O suporte para a biblioteca para suporte de versão da API na Microsoft ASP Web API está disponível como um pacote NuGet. Para instalar o suporte à versão do ASP Web API, execute o seguinte comando na Console do Gerenciador de Pacotes.
PM & gt; Pacote de Instalação SDammann. WebApi. Versioning - Version 2.8.0.
Os métodos GET de maior versão não podem ser acessados ​​por meio do navegador. Em vez disso, requer uma ferramenta de depuração da Web, como o Fiddler, para construir o cabeçalho da solicitação com o número apropriado da versão da API.
Essa abordagem pode ser bastante problemática quando você está usando Gateways da API. Quando você envia o cabeçalho "api-version", isso pode causar confusão para qual API exatamente você está se referindo - o Serviço de API que é seu Gateway de API (que pode ser versionado por ele próprio) ou o serviço de API da Web que deve ser obtido a chamada do Gateway da API.