As diretrizes a seguir destinam-se a ajudá-lo no desenvolvimento de artefatos de integração para o WebSphere InterChange Server. Seguindo estas diretrizes, você pode facilitar a migração de artefatos do WebSphere InterChange Server para o WebSphere Process Server.
Embora possa parecer óbvio, é importante que as soluções de integração sigam o modelo de programação e a arquitetura fornecida pelo WebSphere InterChange Server. É melhor ajustado para soluções de integração de processo em tempo real, automatizadas. Além disso, cada um dos componentes de integração no WebSphere InterChange Server desempenha uma função bem definida na arquitetura. Os desvios significativos deste modelo o tornarão mais desafiador para migrar o conteúdo para os artefatos apropriados no WebSphere Process Server.
Outra boa prática geral que aprimorará significativamente o êxito de futuros projetos de migração é documentar o design do sistema. Certifique-se de capturar a arquitetura e design de integração, incluindo os requisitos de design funcional e de qualidade de serviço, as interdependências de artefatos compartilhados entre projetos e também as decisões de design que foram tomadas durante a implementação. Isto ajudará na análise do sistema durante a migração e minimizará os esforços de retrabalho.
Para criar, configurar e modificar definições de artefatos, é importante que apenas as ferramentas de desenvolvimento fornecidas sejam utilizadas. Evite a manipulação manual de metadados de artefatos (ex. edição direta de arquivos XML), que pode danificar o artefato para migração.
Utilizar apenas as APIs publicadas na documentação do produto para os artefatos. Estas tarefas estão descritas detalhadamente nos guias de desenvolvimento do WebSphere InterChange Server. Embora em muitos casos as APIs de compatibilidade serão fornecidas no WebSphere Process Server, apenas as APIs publicadas serão incluídas. Embora o WebSphere InterChange Server possua muitas interfaces internas que um desenvolvedor pode querer utilizar, não há garantia de que elas serão suportadas durante o avanço.
Ao projetar a lógica de negócios e regras de transformação em mapas e gabaritos de colaboração, certifique-se de utilizar a ferramenta Activity Editor para a maior extensão possível. Isto assegurará que a lógica seja descrita por meio de metadados que podem ser mais prontamente convertidos para os novos artefatos. Para operações que você deseja reutilizar nas ferramentas, utilize o recurso “Minhas Coletas” do Activity Editor sempre que possível. Tente evitar bibliotecas de utilitário de código comum desenvolvidas em campo, incluídas como um arquivo Java archive (*.jar) no caminho de classe do WebSphere InterChange Server, pois elas precisarão ser migradas manualmente.
Em quaisquer trechos de código Java que pode ser desenvolvido, é recomendável que o código seja o mais simples e atômico possível. O nível de sofisticação no código Java deve estar na ordem de script, envolvendo avaliações básicas, operações e cálculos, formatação de dados, conversões de tipos, etc. Se for requerida uma lógica de aplicativo mais extensiva ou sofisticada, será necessário utilizar os EJBs em execução no WebSphere Application Server para encapsular a lógica e utilizar chamadas de serviços da Web para chamá-la do WebSphere InterChange Server. Utilize bibliotecas JDK padrão em vez de bibliotecas de terceiros ou externas que precisariam ser migradas separadamente. Colete também toda a lógica relacionada em um único trecho de código e evite utilizar lógica onde os contextos de conexão e de transação estendem vários trechos de código. Com operações do banco de dados, por exemplo, o código relacionado à obtenção de uma conexão, ao início e fim de uma transação e à liberação da conexão deve estar em um trecho de código.
Em geral, certifique-se de que o código projetado para interagir com um EIS (Enterprise Information System) esteja colocado em adaptadores e não em mapas ou em gabaritos de colaboração. Geralmente, esta é a boa prática para design da arquitetura. Além disso, isto ajudará a evitar pré-requisitos para bibliotecas de terceiros e considerações relacionadas no código, como gerenciamento de conexões e possíveis implementações de JNI (Java Native Interface).
Torne o código o mais seguro possível utilizando a manipulação de exceção apropriada. Torne também o código compatível para execução em um ambiente do servidor de aplicativos J2EE, mesmo que ele esteja em execução em um ambiente J2SE. Siga as práticas de desenvolvimento de J2EE, como evitar variáveis estáticas, execução de spawn em encadeamentos e E/S de disco. Estas são as boas práticas recomendáveis que devem ser seguidas, em geral, mas serão pertinentes à portabilidade.
Para maximizar a portabilidade futura, evite manter transações do banco de dados ativas em nós de snippet Java em um gabarito ou mapa de colaboração. Por exemplo, o código relacionado à obtenção de uma conexão, ao início e fim de uma transação e à liberação da conexão deve estar em um trecho de código.
As considerações primárias para o desenvolvimento de objetos de negócios será utilizar apenas as ferramentas fornecidas para configurar artefatos, utilizar tipos de dados e comprimentos explícitos para atributos de dados e utilizar apenas as APIs documentadas.
Os objetos de negócios com o WebSphere Process Server são baseados em SDOs (Service Data Objects), que utilizam atributos de dados altamente especificados. Para objetos de negócios no WebSphere InterChange Server e adaptadores, os atributos de dados não são altamente especificados e, às vezes, os usuários especificam tipos de dados de cadeia para atributos de dados sem cadeia. Para evitar problemas no WebSphere Process Server, seja explícito na especificação de tipos de dados.
Como os objetos de negócios no WebSphere Process Server podem ser serializados no tempo de execução conforme são transmitidos entre componentes, é importante ser explícito com os comprimentos requeridos para atributos de dados, para minimizar a utilização de recursos do sistema. Por isso, não utilize o comprimento máximo de 255 caracteres para um atributo de cadeia, por exemplo. Além disso, não especifique atributos de comprimento zero que, no momento, têm como padrão 255 caracteres. Em vez disso, especifique o comprimento exato requerido para atributos.
As regras XSD NCName se aplicam a nomes de atributos de objeto de negócios no WebSphere Process Server, portanto, não utilize espaços ou ":" em nomes para atributos de objeto de negócios. Os nomes de atributos de objeto de negócios com espaços ou ":" são inválidos no WebSphere Process Server. Renomeie os atributos de objeto de negócios antes da migração.
Se estiver utilizando uma matriz em um objeto de negócios, não poderá depender da ordem da matriz durante a indexação na matriz em Mapas e/ou Relacionamentos. A construção migrada para o WebSphere Process Server não garante uma ordem de indexação, principalmente quando entradas são excluídas.
Mais uma vez, como afirmamos anteriormente, é importante utilizar apenas a ferramenta Business Object Designer para editar definições de objeto de negócios e utilizar apenas as APIs publicadas para objetos de negócios em artefatos de integração.
Muitas das diretrizes descritas anteriormente se aplicam ao desenvolvimento de gabaritos de colaboração.
Para assegurar que os processos sejam descritos apropriadamente com metadados, sempre utilize a ferramenta Process Designer para a criação e modificação de gabaritos de colaboração e evite editar os arquivos de metadados diretamente. Utilize a ferramenta Activity Editor sempre que possível para aumentar a utilização de metadados para descrever a lógica requerida.
Para minimizar a quantidade de retrabalho manual que pode ser requerido na migração, utilize apenas as APIs documentadas em gabaritos de colaboração. Evite utilizar variáveis estáticas. Em vez disso, utilize variáveis não estáticas e propriedades de colaboração para abordar os requisitos da lógica de negócios. Evite utilizar qualificadores Java finais, transientes e nativos em snippets Java. Eles não podem ser impostos em snippets Java de BPEL que são o resultado da migração de Gabaritos de Colaboração.
Para maximizar a portabilidade futura, evite utilizar chamadas de liberação de conexão explícitas e suporte a transações explícito (ou seja, confirmações explícitas & rollbacks explícitos) para Conjuntos de Conexões com o Banco de Dados Definidos pelo Usuário. Em vez disso, utilize a limpeza de conexão implícita gerenciada por contêiner e o suporte a transações implícito. Além disso, evite manter conexões e transações do sistema ativas em nós de snippet Java em um gabarito de colaboração. Isto se aplica a qualquer conexão com um sistema externo, bem como conjuntos de conexões com o banco de dados definidos pelo usuário. Conforme descrito anteriormente, as operações com um EIS externo devem ser gerenciadas em um adaptador e o código relacionado a uma operação do banco de dados deve estar contido em um trecho de código. Isto pode ser necessário em uma colaboração que, quando apresentada como um componente do processo de negócios de BPEL, pode ser seletivamente implementada como um fluxo que pode ser interrompido. Neste caso, o processo pode ser composto de várias transações separadas, apenas com informações de estados e de variáveis globais transmitidas entre as atividades. O contexto para qualquer conexão do sistema ou transação relacionada que estendeu estas transações de processos será perdido.
Não utilize caracteres especiais em nomes de propriedades do Gabarito de Colaboração. Estes caracteres especiais são inválidos em nomes de propriedades de BPEL para as quais eles serão migrados. Renomeie propriedades para remover estes caracteres especiais antes de migrar para evitar erros sintáticos no BPEL gerados pela migração.
Não faça referência a variáveis usando "this." Por exemplo, ao invés de "this.inputBusObj" use apenas "inputBusObj"
Utilize o escopo de nível de classe em variáveis em vez de variáveis com escopo definido pelo cenário. O escopo de cenário não é transportado durante a migração.
Inicialize todas as variáveis declaradas em snippets Java com um valor padrão. Por exemplo, "Object myObject = null;" Certifique-se de que todas as variáveis sejam inicializadas durante a declaração antes da migração.
Certifique-se de que não existam instruções de importação Java nas seções modificáveis pelo usuário de seus Gabaritos de Colaboração. Na definição do Gabarito de Colaboração, utilize os campos de importação para especificar pacotes Java para importação.
Muitas das diretrizes descritas para gabaritos de colaboração também se aplicam a mapas.
Para assegurar que os mapas sejam descritos corretamente com metadados, sempre utilize a ferramenta Map Designer para a criação e modificação de mapas e evite editar os arquivos de metadados diretamente. Utilize a ferramenta Activity Editor sempre que possível para aumentar a utilização de metadados para descrever a lógica requerida.
Quando referir-se a um objeto de negócios filho em um mapa, utilize um submapa para os objetos de negócios filhos.
Evite utilizar o código Java como o "value" em um SET pois ele não é válido no WebSphere Process Server. Em vez disso, utilize constantes. Por exemplo, se o valor configurado for "xml version=" + "1.0" + " encoding=" + "UTF-8", isto não será válido no WebSphere Process Server. Em vez disso, altere-o para "xml version=1.0 encoding=UTF-8" antes da migração.
Para minimizar a quantidade de retrabalho manual que pode ser requerido na migração, utilize apenas as APIs documentadas em gabaritos de colaboração. Evite utilizar variáveis estáticas. Em vez disso, utilize variáveis não estáticas e propriedades de colaboração para abordar os requisitos da lógica de negócios. Evite utilizar qualificadores Java finais, transientes e nativos em snippets Java.
Se estiver utilizando uma matriz em um objeto de negócios, não poderá depender da ordem da matriz durante a indexação na matriz em Mapas. A construção migrada para o WebSphere Process Server não garante uma ordem de indexação, principalmente quando entradas são excluídas.
Para maximizar a portabilidade futura, evite utilizar chamadas de liberação de conexão explícitas e suporte a transações explícito (ou seja, confirmações explícitas & rollbacks explícitos) para Conjuntos de Conexões com o Banco de Dados Definidos pelo Usuário. Em vez disso, utilize a limpeza de conexão implícita gerenciada por contêiner e o suporte a transações implícito. Além disso, evite manter conexões e transações do sistema ativas em trecho de código Java em limites de nó de transformação. Isto se aplica a qualquer conexão com um sistema externo, bem como conjuntos de conexões com o banco de dados definidos pelo usuário. Conforme descrito anteriormente, as operações com um EIS externo devem ser gerenciadas em um adaptador e o código relacionado a uma operação do banco de dados deve estar contido em um trecho de código.
Para relacionamentos, lembre-se de que embora as definições de relacionamentos poderão ser migradas para utilização no WebSphere Process Server, o esquema da tabela de relacionamentos e os dados da instância podem ser reutilizados pelo WebSphere Process Server e também compartilhados simultaneamente entre o WebSphere InterChange Server e o WebSphere Process Server.
As principais considerações para relacionamentos são utilizar apenas as ferramentas fornecidas para configurar os componentes relacionados e utilizar apenas as APIs publicadas para relacionamentos em artefatos de integração.
É importante utilizar apenas a ferramenta Relationship Designer para editar definições de relacionamentos. Além disso, permita que apenas o WebSphere InterChange Server configure o esquema de relacionamento, que é gerado automaticamente durante a implementação de definições de relacionamentos. Não altere o esquema da tabela de relacionamentos diretamente com ferramentas de banco de dados ou scripts SQL.
Além disso, se tiver que modificar manualmente os dados da instância de relacionamento no esquema da tabela de relacionamentos, certifique-se de utilizar os recursos fornecidos pelo Relationship Designer.
Conforme afirmamos anteriormente, é importante utilizar apenas as APIs publicadas para relacionamentos em artefatos de integração.