| ♥ 0 | Bom Dia, Esta não é uma questão, mas é mais um alerta a quem venha a este fórum em busca de informação relativamente à migração de desenvolvimentos de v10 para Evolution. Não quero criar nenhuma “guerra”, mas não é verdade que TODOS os desenvolvimentos em PEX/API funcionem sem necessidade de alterações no Evolution – e isto é importante porque já tive alguns clientes finais que me referiram isto com base em informações dadas por outros parceiros ou pela própria Cegid – usando isto como argumento para menosprezarem o esforço ($$$) da migração. Embora tenha tido essa indicação por parte de alguns elementos da Cegid, tenho verificado na prática que isso não acontece. Por isso a nossa abordagem é testar cada desenvolvimento ANTES de agendar a migração, e se o desenvolvimento é nosso, validar no código se existe algum potencial problema. Claro que se o desenvolvimento não foi feito por nós (e temos casos em que quem desenvolveu está MIA) a questão é mais complicada… Vamos por partes: No caso dos desenvolvimentos PEX, em que normalmente o contexto da aplicação já está definido pelo ERP, a probabilidade de ocorrerem problemas é menor, mas não significa que não possa ocorrer. Eis um exemplo – um desenvolvimento PEX que funciona sem problemas na v10, e que ao testar no Evolution falha:
Neste caso em concreto (um dos desenvolvimentos que foi feito por outrem), a questão ainda é mais interessante: no 1º teste não ocorreram problemas, mas dias depois encontrámos este erro noutro posto – isto permitiu-nos calcular qual seria o problema: o 1º teste foi feito num dos nossos equipamentos com a v10 e Evolution instalados, o 2º num outro posto da mesma rede mas que só tinha o Evolution. Aqui a questão é que o programador original deve ter utilizado a variável de ambiente PERCURSOSGP100 que não existe no posto com Evolution, provavelmente invocada no AssemblyResolve (criando essa variável de ambiente no posto o módulo já funciona). No caso dos desenvolvimentos de aplicações externas que usam a API o potencial de problemas é maior. Apenas um exemplo simples: Tendo uma aplicação que usa a API, para saber qual a plataforma a usar a aplicação vai usar EnumTipoPlataforma – não sei exactamente há quando tempo foi adicionado EnumTipoPlataforma.tpEvolution, mas é provável que a aplicação ainda não a trate, ou até de todo apenas se permita ligar ao tipo de plataforma para que foi desenvolvida inicialmente (Professional ou Evolution). Posto isto, é evidente que o esforço de migrar os desenvolvimentos da v10 para Evolution não é comparável ao esforço da migração de v9 para v10; agora não se deve passar a mensagem de que esse esforço não existe. De facto, é nossa política tratar mesmo as SRs dentro da mesma linha de produto da mesma forma: a cada nova SR corremos os nossos desenvolvimentos por um processo de validação de modo a detectar eventuais alterações não documentadas – e já temos tido surpresas… Votos de boas migrações!
Marcado como spam |
| Resposta privada MensagensDialogo funciona perfeitamente aqui Marcado como spam | |
| Resposta privada É sempre de esperar alguma fricção em passagens para versões novas. Fiz muita conversão de código da v9 pra v10 e realmente o esforço da parte dos programadores não vai ser a esse nível, mas sou da mesma opinião, dizer que há completa backwards-compatibility e depois ter programas a rebentar porque tentam aceder a variáveis globais... "chato" é o mínimo que consigo arranjar. No nosso caso ainda não houve falhas catastróficas mas por acaso tenho um caso interessante: usamos muito os Dialogos ou MensagensDialogos para apresentar informação ao utilizador e agora essa classe toda está marcada como Obsoleta com uma notificação que devemos usar outra em alternativa... mas não a encontro disponível pra uso. Talvez algures nos .dll do Evolution? Mas se for usar isso na v10 será que tenho problemas? Marcado como spam Comentários Dialogos está marcada como obsoleta, mas mensagensdialogos não (na resposta não consigo colocar uma cópia de écrã, mas em StdPlatBS100 verifico que só Dialogos está marcada como Deprecated. public StdBSDialogos Dialogos => m_objBSO.Dialogos;
public StdBSMensagensDialogos MensagensDialogos => m_objBSO.MensagensDialogos; Estive a ver e sim, tem razão. Mas juro que há uns dias quando tentei usar, ambas davam a mesma mensagem. De qualquer forma, a transição não está a ser 100% suave e isso é um problema.
O validador que diz que usam para verificar se está tudo bem com os desenvolvimentos após actualização do programa, foi construido por vocês? O processo de validação que usamos não é uma aplicação, é um conjunto de procedimentos, que varia em função de cada projecto, que envolve análise de código, execução do módulo usando um conjunto de inputs definido, etc; quando todos esses passos estão validados libertamos o módulo como OK para a versão. É bastante "low tech", no fundo o que era feito no passado pelos produtores, antes de lançarem as releases para os end users testarem... |