Estamos planejando migrar o atual PI 7.1 dual stack para o PI 7.31 com a stack java apenas.
Minha dúvida é se o novo sistema Java BPM vai importar a funcionalidade do atual sem problemas, e se a SAP vai dar suporte ao novo BPM no que diz respeito a NFe?
Existe algum documento onde esclarece essa questão? Tenho que reportar isso a nossa empresa, pois segundo o documento abaixo seria suportado.
In 7.3.1, Netweaver Business Process Management (BPM) and Netweaver Process Integration (PI) will be combined into a single package to provide a unified platform to support human-to-human and system-to-system workflow, as well as application integration requirements. The design/development environments of the two platforms will be unified in the Eclipse-based Netweaver Developer Studio.
The old cross-component BPM (ccBPM) feature of Netweaver PI will be replaced with the Netweaver BPM orchestration engine (although ccBPM will continue to be supported for backward compatibility). This will complete the planned Netweaver PI transition toward a 100% Java code base started with Netweaver PI 7.1.
Na verdade é o contrário. Se suportasse, haveria dizendo que suporta.
O trecho que vc colou nao quer dizer que ccBPMs rodam no novo BPM, ele diz que o BPE Engine (que executa ccBPMs) vai continuar a ser suportado, mas para isso vc precisa do dual stack.
Pelo que entendo dos documentos atuais da SAP, esta planeja acabar com o stack PI ABAP e para isso criou o BPM Orchestral Engine para substituir o antigo ccBPM. ("The old cross-component BPM (ccBPM) feature of Netweaver PI will be replaced with the Netweaver BPM orchestration engine")
Tens data de quando planeja suportar NFe no novo BPM?
This is a very interesting thread. Even though SAP has released the AEX with the BPM option to support ccBPMs ([Process Integration and Orchestration Package|http://help.sap.com/saphelp_nw73ehp1/helpdata/en/f1/24e6e6f548480b85197bde372d13c9/frameset.htm] ), are you indicating that the NF-e ccBPMs will not be supported with this package? Djoni asked a very pertinent question: if the NF-e ccBPMs are not going to be initially supported with the PI/OP package are there plans in the future to do so?
It seems odd that SAP announces that they will no longer add features to the ABAP stack since they are investing the effort in the Java stack but they won't support NF-e ccBPMs on a Java only installation?
It seems odd that SAP announces that they will no longer add features to the ABAP stack since they are investing the effort in the Java stack but they won't support NF-e ccBPMs on a Java only installation?
These are the portuguese forums, so please refrain from using any language other than portuguese.
That being said, SAP is a huge company with 30k+ more people in development.
So, it's just natural that the directions from technology components are not immediately followed by the application development teams, who consume such technology components.
Of course, at some point in time, NFE development team will need to consider going in that direction, but as of now, they'd rather focus their development efforts on building up more functionality than doing a technical migration that would be usable by, what, less than 1% of our current customers?
Henrique -- Peço desculpas por não escrever meu post em português.
Encontre seu seguinte citação insulto:
Henrique Pinto wrote:
they'd rather focus their development efforts on building up more functionality than doing a technical migration that would be usable by, what, less than 1% of our current customers?
Enquanto nós atualmente pode ser considerados a minoria de clientes (de acordo com você 1), nós tomaram a direção futura definida pela SAP sério e gostaria de ser transmitir pensamento. Em poucos anos, seremos parte da maioria. Faço votos de que a equipe de desenvolvimento de NFE seria também transmitir pensamento e começar a colocar o esforço para a direção futura da PI.
Se minha mensagem soou ofensiva, te peço desculpas, não foi essa a intenção.
Eu apenas te transmiti a informação que recebi do time de desenvolvimento quando eu fiz essa mesma pergunta sobre o Roadmap de migração para stack Java only do PI, há alguns meses, logo depois do TechEd (onde vi o PI Java only sendo mostrado continuamente).. Tb sou totalmente pró-inovação e acredito que olhar para esse caminho é necessário, porém não é prioritário para o desenvolvimento hoje (do qual, quero deixar claro, eu não faço mais parte, desde 2010).
Talvez o melhor caminho seja tentar uma repriorização disso através do time de localização, que é a interface oficial junto ao desenvolvimento, definindo junto com eles o backlog de desenvolvimentos. Tente falar com o Bruno Renzo sobre essa possibilidade de repriorização.
O time de desenvolvimento da NF-e já está testando uma solução com PI single stack (java-only). Em breve vai ser liberada (ainda não decidimos se como parte da solução standard ou não).
O fato é que devemos acima de tudo priorizar as mudanças legais e não é nosso objetivo principal migrar para as tecnologias mais novas, até porque elas às vezes são instáveis e a a NF-e é a aplicação mais crítica para a área de negócios das empresas no Brasil.
Claro que sempre que possível e vantajoso, vamos sim optar por mudar as tecnologias que suportam a aplicação, mas esta não é a prioridade do time.
O ponto importante a discutir é se o PI que usamos pra NFe deve ser o mesmo PI que usamos como integration server pra todas as outras soluções de integração.
Se usarmos o integration server principal para a NFe, estaremos amarrando a evolução da plataforma PI no nosso landscape à versão homologada pela NFe. Me parece natural que a NFe não use sempre a versão mais recente do PI, pelos motivos que o Bruno e o Henrique já colocaram, e outros mais.
Por outro lado, é possível criar uma instância do PI só pro GRC. Embora possa dar um pouco mais de trabalho inicialmente, essa forma de instalação permite que o integration server principal do landscape evolua independentemente da versão homologada pela NFe.
Com um PI pra NFe, a discussão acerca de qual versão vai ser suportada fica em segundo plano. Até porque, não há necessidade (de fato) de evolução dessa plataforma a não ser a evolução legal. Quanto menos alteração tecnológica para NFe, na minha opinião, mais estável fica a solução.
Eu até concordo com a idéia macro, mas é que no caso da mudança dual stack -> single stack, a diferença é brutal e os ganhos são consideráveis. Falando de uma empresa que tenha alto volume e que tenha um PI gigante pra suportar o NFE, eles poderiam conseguir jogar o sizing da máquina de PI pra metade com um cenário single stack, para o mesmo throughput de mensagens.
Claro, uma empresa menor cujo volume nao justifique e performance nao seja crítico, nao vai ter ganho nenhum ou muito pouco.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.