Implantação de SAP e SQL Server 2012 da Microsoft

Solução ERP interno da Microsoft é o SAP Suite de produtos, incluindo SAP ECC 6.0, SAP BW e SAP SCM. Microsoft testa novo SQL Server versões e Service Packs no teste os sistemas SAP, mas também o sistema de produção de ECC de núcleo que executa o Microsoft em todo o mundo. A instância única ECC 6.0, cliente único sistema é acessado por 95.000 usuários em todo o mundo e transaccione a maioria da $65B USD em receitas a cada ano. SQL Server 7, SQL 2000, 2005, 2008 R2 todos foram testados no núcleo do sistema de produção de ECC antes destes produtos foram lançados. 

Microsoft seguirá o mesmo processo com SQL 2012 para que os clientes possam ter a confiança de que nenhuma versão do SQL Server nunca é liberada sem execução da produção da Microsoft sistema SAP durante vários meses. Queremos alcançar com este artigo e dar uma atualização de status sobre nossas implementações internas.

Desde Janeiro de 2011 testamos compilações de 2012 do SQL Server em um modo seguro que representam cerca de metade da capacidade de nossos sistemas SAP ERP produtivos. Além de testar a funcionalidade usada pela SAP, uma das áreas principais testes foram em torno de nossa nova HA/DR funcionalidade oferecida no SQL Server. Estamos combinados este conjunto de funcionalidade sob o nome de Always on em SQL Server 2012 (http://msdn.microsoft.com/en-us/sqlserver/gg490638 ). Todos os métodos antigos como o Windows Clustering, espelhamento de banco de dados e envio de logs ainda são enviados em 2012 do SQL Server. 

A nova funcionalidade de Always on que permite maior flexibilidade e funcionalidade como vários secundárias ou on-line de leitura de secundárias, são oferecidos em paralelo com a funcionalidade 'antigo'. No início dos testes em sandbox começamos com espelhamento de banco de dados como método de alta disponibilidade. Uma vez que nós à prova que o espelhamento de banco de dados estava funcionando perfeitamente nos mudamos a configuração de alta disponibilidade para AlwaysOn com 2 réplicas (um principal e outro secundário) basicamente substituindo o espelhamento de banco de dados. Desde de julho que tivemos um 3^rd réplica (outro secundário adicional) adicionado à configuração de HA/DR para testar a substituição de envio de logs para nosso Datacenter de recuperação de desastres. Em frente à combinação de espelhamento de banco de dados e envio de logs como usamos até hoje, agora tivemos três servidores usando a mesma funcionalidade de Always on replique as alterações. 

Tivemos um lugar para definir a configuração de HA/DR e um lugar para verificar se tudo iria correr bem. Todos os testes em torno de nossa nova tecnologia HA/DR correram bastante bem. Comentários desses testes para desenvolvimento do SQL Server foi usado para melhorar e afinar a tecnologia AlwaysOn. Deste ponto de vista, os testes iniciais que fizemos juntamente com nossa equipe SAP Basis podem considerar como muito bem sucedida por TI da Microsoft, bem como desenvolvimento do SQL Server. Além de Always on também testamos um novo sinalizador de rastreamento já documentado anteriormente. Essa nova funcionalidade também provou para ser um sucesso completo, eliminando alguns problemas conhecidos que às vezes encontramos com consulta plano geração.

Mudamos nosso sistema seguro para uma compilação final CTP3 atualizar em Julho e continuou a executar testes nele verificar funcionalidade e características diferentes.

Em meados de agosto concentramos nossa atenção nossa instância de teste oficial do SAP ERP que situa-se no nosso site de DR e é usada para negócios regressão, carga de trabalho e testes de escalabilidade. Como tal, este sistema é uma cópia exata do nosso sistema produtivo de SAP ERP. Mudamos essa instância do SQL Server 2008 R2 em SQL Server 2012 CTP3 Refresh com e in-loco. Substituímos o espelhamento de banco de dados neste sistema de teste também com Always on em uma configuração de 2-réplica. Testes de escalabilidade com Always on usando nossa Suite de testes de regressão de negócios mais índice recria executada em paralelo revelou que a replicação de dados de log de transação entre primária e secundária é dimensionamento de maneira melhor do que já fiz DBM. 

Cenários de carga de trabalho de alto volume poderiam causar efeitos descritos. Considerando que a transferência de log de transação de dados projetado novo não apresentaram qualquer problema. Experiência feita em nosso sistema de teste do SAP foram extremamente positiva e pavimentou o caminho para mover SQL Server 2012 em nosso sistema produtivo como aplainadas meados de novembro.

Como uma última instância nos mudamos nossa instância de SAP ERP produtiva para compilação atualizada SQL Server 2012 CTP3 Refresh em 11/11/2011. Foi durante a nossa manutenção trimestral habitual que normalmente usamos para obter novos kernels SAP e pacotes de suporte SAP aplicados ao nosso sistema de ERP SAP quando realizamos upgrades no local de nossas instâncias do SQL Server 2008 R2 para SQL Server 2012. A seqüência dos passos parecia:

1. Atualizado o envio de logs destino no local para o SQL Server 2012 dois dias antes do tempo de inatividade
2. Atualizado o espelhamento de banco de dados anterior para o SQL Server 2012 um dia antes do tempo de inatividade
3. Desligar o sistema de ERP SAP no início do tempo de inatividade.
4. Interromper o espelhamento de banco de dados
5. Abrir banco de dados espelho anterior e deixar que ele adaptou para as etapas de atualização do esquema SQL Server 2012.
6. Depois criamos um nó Always on (nossa nova funcionalidade HA/DR – haverá uma série de Blogs sobre este seguinte) com uma réplica e um ouvinte nome (virtual).
7. Em paralelo a SNAC (SQL Native Client Access) tem implantado para todos os servidores de aplicativos.
8. Após estas etapas foram concluídas que precisávamos substituir o nome do servidor e o nome do parceiro de failover em vários locais da configuração do SAP com o novo nome virtual/ouvinte da configuração Always on.
9. Depois que isso foi feito, temos o sistema e executar novamente para realizar a manutenção trimestral normal, que geralmente se encarrega sobre como atualizar vários pacotes de suporte SAP, SAP kernel exchange e muitos transportes que normalmente implementam novas funções em nosso sistema de ERP SAP.

Após o SAP ser instalado e  ser colocado em produção:

1. Nós atualizado o antigo servidor principal para o SQL Server 2012.
2. Nós deliberadamente não sincronizar o principal antigo e agora secundário não para a configuração de HA enquanto o pacote de suporte as importações e transporta porque nós normalmente sempre manter o servidor espelho sobre o estado do início do tempo de inatividade para ser capaz de recuperar de uma forma rápida se intransponíveis problemas durante o suporte pacote aplicativo ocorreria

Depois que todos os pacotes de suporte e transportes foram aplicadas ao sistema de ERP SAP, realizamos as seguintes etapas

1. Nós então sincronizado esta instância de SQL Server 2012 com os backups de log de transação do objeto atual e adicionado-lo como uma réplica ao grupo de disponibilidade de Always on.
2. Realizamos diversos testes de failover com o sistema de ERP SAP ainda em execução. Nós quisemos marcar com esses testes se a configuração de Always on foi boa e correta.

Até agora o sistema comporta-se perfeitamente e mostra o grande desempenho. 

Fonte site msdn.com

Muito sucesso a todos!!

Prezados Leitores,

A Equipe JR’s, deseja um

PROSPERO ANO NOVO!!!

Para todos os Consultores Jr, Pleno e Sênior...

Que tenham muito sucesso em seus projetos!!

Regras de Substituições no Mod. FI

As regras de substituição são gravadas no Administrador de Regras. Os dados que entram no sistema são substituídos pelo Integration Manager. A substituição ocorre antes de os dados serem acrescentados às tabelas de totais do FI-SL.

Na substituição em FI-SL, os valores entrados no Sistema SAP R/3 são validados de acordo com uma condição definida pelo usuário. Quando se preenche uma condição, o sistema substitui os valores entrados pelos valores substitutos, e os valores substitutos são transferidos para o componente da aplicação FI-SL.

O sistema efetua primeiro a validação e em seguida a substituição. Isto permite que o sistema valide dados que devem ser substituídos.

Um processo de substituição pode conter até 999 etapas. Desta forma, antes de ser efetuar um lançamento, é possível substituir os valores utilizando as expressões booleanas desejadas.

Uma etapa de substituição contém as duas expressões seguintes:

• Expressão da condição

A expressão da condição estabelece as condições que devem ser satisfeitas antes de a substituição ser efetuada. A transação continuará sem substituição, se a expressão da condição for falsa. A transação continuará com a substituição, se a expressão da condição for verdadeira.

• Valores de substituição

O valor de substituição é um valor numérico ou uma seqüência de letras que substitui o valor entrado. Um único processo de substituição pode substituir mais do que um valor.

• Exit de substituição

É possível especificar se a substituição será executada por meio de um exit de substituição. O número do exit de substituição direciona o sistema para um programa ABAP definido pelo usuário. Os exits de substituição permitem definir substituições mais complexas e substituir mais de um valor em uma substituição. Para obter mais informações, consultar User Exits em Validações/Substituições/Regras.

Ao definir substituições, utilizar a mesma sintaxe utilizada com validações. A expressão da condição utilizada em uma substituição pode ser uma expressão simples ou uma combinação complexa de instruções lógicas, regras e sets.

A tabela seguinte contém exemplos de substituições definidas pelo usuário.

Expressão da condição	Substituição
Se o centro de custo for 10,	utilizar o valor 01 para o centro e o valor 30 para a divisão.
Se a conta for 100000 e a divisão for 20,	utilizar o valor 100 para o centro de custo e o valor 012 para a data.
Se a conta pertencer ao set ACCT-23 e o centro de custo pertencer ao set CENTER-56,	utilizar o valor "em branco" para a chave do produto.

A substituição permite atualizar os dados transferidos para o componente da aplicação FI-SL mais detalhadamente.Criação de uma substituição para substituir (acrescentar) o valor 10 na dimensão centro, sempre que a conta entrada se encontre no intervalo 100000 a 200000 e o centro de custo for 200. 

Quando os valores entrados são lançados no FI-SL, o sistema utiliza o valor 10 para a dimensão centro caso a conta entrada se encontre dentro do intervalo 100000 a 200000 e centro de custo seja 200.

A figura a seguir mostra como as substituições de FI-SL interagem com os valores entrados no sistema SAP R/3.

Para cada etapa de validação: 

1. Os dados são entrados no sistema SAP R/3.  
2. Os dados são enviados ao Integration Manager FI-SL (IM) e às regras de substituição. As substituições são parte do Integration Manager juntamente com a validação, regras de seleção de ledger e regras de totalização.
3.  Os dados são verificados de acordo com uma expressão da condição. O sistema executará a substituição, se a expressão da condição for verdadeira. O sistema não executará a substituição, se a expressão da condição não for verdadeira.
4. Caso existam passos adicionais no processo de substituição, o sistema repete os passos aqui descritos.

Caso se pretenda utilizar dados de outras aplicações SAP como valores de substituição no componente de aplicação FI-SL, a dimensão substituída deve ser definida para a classe booleana na qual os dados devem ser substituídos.

Para obter mais informações sobre como criar expressões de substituição, consultar Como criar expressões booleanas para o sistema FI-SL. Para obter mais informações sobre a criação de substituições, consultar Como criar uma Substituição.

Substituições de matriz

Também é possível criar substituições de matriz. As substituições de matriz permitem a execução de uma substituição para o documento completo, inclusive o cabeçalho e todas as linhas do documento.

Só é possível usar substituições de matriz juntamente com o código de momento 0003 dentro da área de aplicação Contabilidade financeira (FI).

 Fonte site help.sap.com

Projeto de Roll Out.

Um projeto de Roll Out é um projeto de migração ou “rolagem” da solução de negócio do sistema ERP de uma empresa para outra empresa que não possui o ERP.

O projeto de Roll Out pode ocorrer sob diversas situações de negócio. Exemplos: uma nova empresa que inicialmente não possui um sistema ERP foi incorporada a uma organização que utiliza um ERP e por decisão executiva passará a utilizá-lo. Uma organização possui subsidiárias no exterior. A matriz passa por um projeto de implantação e posteriormente deseja fazer o Roll Out da solução de negócio para as filiais.

Um grupo de empresas foi comprado por outro grupo, ambos trabalham sobre um sistema ERP porém, em função de avaliação do grupo comprador, decide-se pela rolagem da solução de negócio do grupo comprador para o grupo adquirido ou uma mescla entre as duas soluções, aproveitando o melhor de cada uma.

O ambiente produtivo pode ser um para o grupo de empresas ou os ambientes produtivos são mantidos e os templates (modelos ou orientações de solução de negócio para o sistema ERP) são introduzidos nos processos de negócio das empresas adquiridas.

Percebe-se que as decisões pelo projeto de Roll Out têm natureza diversa. Conseqüentemente, cada caso de negócio é analisado e o escopo e complexidade do projeto dependerão desta análise.

Um projeto de Roll Out na solução SAP consiste em alterações na customização do R/3, adaptações em programas ABAP, ajustes em outras plataformas como Business Warehouse (BW) ou Netweaver, criação de novos SAPscripts, realização de testes unitário e integrado dos processos de negócio adaptados, treinamento de usuários finais, gestão de mudanças, novos perfis e chaves de acesso ao R/3.

Como a característica principal deste tipo de projeto é a “rolagem” da solução SAP de uma empresa para outra, as alterações no R/3 compreendem a customização de nova Company Code (empresa) com as estruturas de logística e de vendas. Customizações adicionais serão feitas nos processos de negócio para receber a(s) nova(s) empresa(s).

A metodologia ASAP também é adotada para um projeto de Roll Out com as ferramentas aceleradoras e mobilização de recursos de consultoria e cliente para a equipe do projeto. Todo o trabalho realizado nas 5 fases do projeto de implantação também é feito no projeto de Roll Out, porém, com um fator acelerador nas fases 2 – Business Blueprint – e fase 3 – Realização: A solução de negócios está customizada no R/3 da empresa modelo e os templates foram definidos.

As configurações para contemplar as empresas que receberão o ERP serão de acordo com os templates da empresa modelo com adaptações no processo de negócio das empresas a implementar. Consequentemente, o tempo de projeto reduz nas duas fases e propicia uma redução de custo para o cliente.

O consultor deve ter atenção na avaliação de propostas para projetos de realização de Roll Out para empresas “virtuais” que ainda não saíram do papel. Este tipo de trabalho pode trazer dificuldades para todas as etapas do trabalho de consultoria pois é de difícil definição de escopo. Desde a pré-venda do projeto, marcos para faturamento do serviço, até a entrega para o cliente.

Fonte site SAP Content.org