Ola a todos
Li na mundo java nro 3 ontem… a principio nao gostei muito da arquitetura do sistema, pois segundo o artigo o sistema faz bastante uso de stored procedures, o que o deixa dependente do Oracle.
Alguem conhece?
Versao “tropicalizada”
www.compiere.com.br
Olha, eu nunca usei, mas pelo que vi no site é bom sim…
Eu sei que eles pretendem ficar independentes do Oracle, mas isto não tem previsão ainda…
PS: não sei se ajudou muito… mas sei como é quando ninguém te responde… :-p
Ate hoje nao existe suporte a outro banco de dados por ser uma tarefa estupidamente dificil de fazer. O compiere simplesmente depende do Oracle.
A arquitetura dos caras eh bastante complexa tambem, e se voce quiser suporte decente, vai ter que pagar pros caras.
Rafael
Deeeeeeeeus do céééééu, que horror! :?
[quote=“Rafael Steil”]Ate hoje nao existe suporte a outro banco de dados por ser uma tarefa estupidamente dificil de fazer. O compiere simplesmente depende do Oracle.
A arquitetura dos caras eh bastante complexa tambem, e se voce quiser suporte decente, vai ter que pagar pros caras.
Rafael[/quote]
Acho quem uma das razoes de depender do banco de dados ORACLE é a velocidade de processamento, pois um ERP trabalha mto com o banco de dados. Alem do que , o oracle é bem completinho na parte de processamento dos dados dele ( triggers, procs, etc ) fora a estrutura do banco em si ( se falei bosta, podem corrigir )
Agora, falar que depende dos caras ( compiere ) pra dar manutenção no sistema acho bobagem. Se a aplicação tah bem documentada, creio que qqer um quem entenda o minimo de java, oracle e EPR ( negócio ) , dá manutenção facil, facil nele.
Mas se os caras fizeram de proposito pra ninguem entender, aí nao tem bixo que entenda :roll:
Eu já trabalhei com erp em diversas linguagens e acho que se vc manja da coisa,~e tah tudo bem feitinho, vc mexe nela sussa… 
Agora essa coisa de independencia do banco de dados, acho bem legal, so nao sei o q seria melhor, pois, como disse antes, um ERP tem alguns processos ( pra nao dizer mts ) que trabalham pesado com banco de dados. Fazer esse processos na linguagem, acho que vão matar a aplicação, devido a velocidade: banco-aplicação. A comunicação entre eles deveria ser tao rapido qto desenvolvido no banco de dados propriamente. Logico, isso qdo se trata de uma empresa de porte médio, pois, claro que uma empresa de fundo de quintal nao tera problemas com demora no processamento.
Abraços!
Olá,
Uma duvida que me surgiu…estes tempos eu dei uma olhada neste Compieri e não curti muito naum. A instalação parece bem complicada ( Claro é um ERP ).
Mas esse esquema de usa so Oracle como o Bruno falou tem suas explicações. Agora para quem ja mexeu no codigo, qual a dificuldade de migrar para Postgre sendo que não é tão dificil assim migrar os PL/SQL por Pg/SQL??
[quote=“fabgp2001”]Olá,
Uma duvida que me surgiu…estes tempos eu dei uma olhada neste Compieri e não curti muito naum. A instalação parece bem complicada ( Claro é um ERP ).[/quote]
Acho que a instalação em si nao deve ser complicada: imposta-se a base com as tabelas e dados princpais e tem-se a aplicação configurada
Agora… Soh achei ele meio “proble” de graficos. Parece mais uma telinha básica de cadastro…rs… coisa feinha :lol:
Vcs ja viram ele rodando ? Nao acham tb ?
Abraços!
Olá,
Só um detalhe o CompiereBR não é free neh?
]['s
[quote=“RodrigoSol”][quote]
O desenho da solução de independência de banco de dados para o CompiereBR
implementou a separação das regras de negócio das camadas cliente e banco de
dados para uma camada de negócios. Essa separação foi obtida pela utilização
consistente de Enterprise Java Beans (EJB) para a comunicação entre os clientes
e a camada de negócios. Essa solução torna o CompiereBR capaz de executar
transações através de diferentes maquinas, diferentes gerenciadores de banco de dados, em threads separadas e diversos modelos de “load-balancing”.
[/quote][/quote]
Porra, eles deveriam ter vergonha de colocar egra de negócio em banco de dados, e não dizer que a “brilhante” solução foi simplesmente fazer o que já deveriam ter feito desde o início!
Fora que quando o mundo todo passa a questionar “precisamos de EJB quando?” o sistema coloca lá os tramboios pra rodar…
[quote=“RodrigoSol”][quote]
Como EJB container foi utilizado o JBoss - a melhor implementação Open-Source
do J2EE Aplication Server, que é hoje a mais popular aplicação deste tipo,
detendo 27% do marketshare. O JBoss já era utilizado, em uma versão mais
antiga do CompiereBR. Para a utilização via browser a solução adotada se utiliza
do servidor de web Tomcat 5.0, que é instalado conjuntamente com o JBoss.
[/quote][/quote]
Porra, se market share disesse que algo é bom, os software da M$ seriam os melhroes da parada! Nada contra o JBoss, ams isso aí de “mlehos OSS” é 100% marketing.
[quote=“RodrigoSol”][quote]
Para persistência e recuperação de dados foi utilizado o software Hibernate,
também distribuído como Open-Source pela mesma organização responsável pelo desenvolvimento do JBoss e que vem recebendo diversos prêmios de excelência como solução de persistência relacional.
[/quote][/quote]
Pois é, depois que o Fleury disse que tem parte do Tomcat e do Hibernate, falo nada.
[quote=“RodrigoSol”][quote]
mantendo assim o paradigma do Compiere de mínimo uso de programação
procedural e ênfase em programação declarativa.
[/quote][/quote]
Que tal o mínimo de procedural e o máximo de OO?
Dei uma olhada certa vez no Compiere, me pareceu um projeto legal [é um dos mais ativos no sf.net], mas depois deste rpess-release, comecei a duvidar seriamente desta estrutura…
COlocar regras de negócio no banco é sempre um erro, a menos que seja uma arquitetura C/S antiga [que por si só já é um erro!], ou que você precise muito do desempenho das SPs [o que não justifica o erro, só ameniza a auditoria 
].
SGBDs guardam…DADOS!!! Funções para manipular dados, no máximo, e mesmo assimd e modo não intrusivo, ou você quebra o encapsulamento totalmente.
[]s
[quote=“pcalcado”]
COlocar regras de negócio no banco é sempre um erro, a menos que seja uma arquitetura C/S antiga [que por si só já é um erro!], ou que você precise muito do desempenho das SPs [o que não justifica o erro, só ameniza a auditoria ].[/quote]
Um dos motivos que tivemos que colocar regras no banco foi pq exitem varios clientes com diferentes front ends ( VB, Swing, Forms ).
Ja imagino ter refazer em todas !?
Mas sim, concordo que regra nao se fica no banco e dim de papo. Ainda to convencento todo mundo a passar pra java
huahauuahauhaauha…
Ps: Pensei que o JBoss tivesse “suportando” o Hibernate, e nao “desenvolvido”… :roll:
Que tal Corba? HTTP? Pow, qualquer coisa, ams que fique na camada de lógica…
[quote=“brlima”]
Ps: Pensei que o JBoss tivesse “suportando” o Hibernate, e nao “desenvolvido”… :roll:[/quote]
Parece que ot ermo certo é se apoderou ;). O problema é o hibernate virar zumbi do FLeury…
[]s
O pessoal do compierebr gastou um bom tempo pra adaptar o compiere…
o codigo eh puta complexo, e a curva de aprendizado vai pra estratosfera tmb… ninguem consegue dar manutencao naquilo “facil, facil”.
Em relacao a ficar regra no banco, eh meio estranho dizer que tem que ficar tudo no banco ou tudo na aplicacao…
Se o teu sistema vai usar banco de dados com certeza, nao eh produto ( ou seja, eh um sistema desenvolvido pra uma necessidade especifica do cliente ), entao tem mais eh que usar os recursos disponiveis mesmo, da melhor forma possivel.
Ha muitos casos onde vc precisa juntar muitos dados com varias condicionais, e ( no caso do oracle ), pl/sql ajuda muito nesse ponto.
Rafael
[quote=“Rafael Steil”]Ha muitos casos onde vc precisa juntar muitos dados com varias condicionais, e ( no caso do oracle ), pl/sql ajuda muito nesse ponto.
[/quote]
Bulk Collection é um exemplo. Para sistemas com INSERT em massa ( importacao de arquivos por exemplo) esse recurso do PL/SQL deixa muito mais rapido.
Podem criticar, mas aqui acho dificil conseguir fazer com a mesma performance se isso tivesse na aplicacao.
]['s
Fábio,
Por isto que falei que se a performance for importante e houver uma diferença real, vale a pena. A questão é: o paradigma é quebrado. Isto é bom? Não. É necessário? Às vezes, ainda mais no nosso mundo bizarro onde ora dados são relacionais, ora objetos.
Note: você estará mexendo em dados, não em objetos. Isto é complicado, mas já me estendi demais neste ponto.
Ninguém vai criticar você por colocar um milhão de isnerts em uma SP simples, mas com certeza se fizesse auditoria onde a regra de negócio está no SGBD, porque é “portável” ou qualquer outro motivo, a emrpesa contratante iria receber um relatóriozinho de várias páginas falando sobre isso.
É bom? Não. Útil? Algumas vezes. Tem como evitar? Se você precisa de performance e está preso a um SGBD, não.
É bom também lembrar que StoredProcedures procedurais tambémd evem ser escritas seguindo boas práticas. São rotinas, estas devem ser bem escritas e documentadas. Assim, facilita na migração de Pl/SQL pra XYZ/SQL amanhã.
[]s
Phillip,
Realmente, sobre o exemplo que eu dei é um caso bem especifico e que pode naum fazer diferenca para uns e fazer muita para outras. O que eu acho é que uma Procedre como essa naum afeta em nada a aplicação. Pois um, duas ou até 10 naum é dificil de migrar. E sobre o exemplo naum tem nada de regra de negocio é mais insert puro.
]['s
Uma perguntinha básica… alguem encontrou alguma documentação do Compiere que seja decente e de graça?
No site oficial do Compiere só tem uma documentação muito superficial… a documentação que presta mesmo, é paga.
Documentação de Usuário, 40USD
Documentação Técnica nem existe, eles só oferecem uns treinamentos e consultorias…
Dei uma olhada no fonte desse ERP !.
So acho que eles precisava ser mais padronizado …
Marcio
Cada dia mais eu tou aderindo a filosofia do “A coisa mais simples que funcione”, isso significa que atendendo aos requisitos minimos, sejam eles ser portavel entre bancos, codigo não feder, ser eficiente, me deixar orgulhoso ou simplesmente funcionar, eu uso a solução que me leve ao resultado mais rápidamente. Se isso envolver SPs, VB, anti-patterns, código digno de 100 chibatadas/linha ou qualquer outra coisa eu não ligo.
Quero apenas ter feito e fazendo somente aquilo que foi concebido para. Se meu cliente é um oracle shop a 15 anos, acabou de torrar alguns milhoes e o código sendo produzido nunca vai ser usado fora dele, não me importaria em usar extensões proprietarias do OC4J, stored procedures do oracle, TopLink, bla bla bla bla. Tudo aquilo que seria um crime em nome do reuso.