Desktop para Web - Como lidar com fluxos de trabalho interativos pelo usuário

5

Eu inicio um novo projeto neste verão, consistindo no desenvolvimento de uma versão web de um ERP de desktop proprietário.

O principal objetivo da minha empresa é poder propor uma versão web do seu ERP, com todas as vantagens que envolve (mobilidade, possibilidade de vender versões SaaS, visual moderno e componentes ...), sem perder qualquer recurso comercial . Com isso, quero dizer que os desenvolvedores não podem refazer o lado comercial do aplicativo. O objetivo principal é ser capaz de traduzir os mesmos processos em aplicativos da Web.

A camada de negócios da versão mais antiga não é diretamente reutilizável, pois é realmente dependente da GUI. Esses processos de negócios foram reescritos como diagramas UML, que serão usados como suporte para desenvolvermos o novo aplicativo.

O problema que encontro é que não sei como lidar com processos que precisam de interações do usuário. Por exemplo:

Na validação de um pedido de venda, o processo de validação verifica todos os produtos nele contidos, verificando se há estoque disponível e, em seguida, executando operações diferentes. Se não houver estoque disponível, o usuário é perguntado se deseja cancelar o pedido, remover este produto ou selecionar outro equivalente. Funciona como um Javascript alert ou confirm : atual "thread" (ou seja, processo de validação) está em espera, aguardando a interação do usuário. Após a escolha do usuário, ele acaba lidando com o produto atual e depois valida o próximo, e assim por diante.

Como lidar com esse tipo de processo com um aplicativo da web? Existe algum framework, padrão de design ou algo mais que permita escrever esse tipo de processo de negócios, capaz de iniciar e manter assim?

Uma solução pode ser dividir esses processos de negócios em processos menores. Para o meu exemplo, teríamos dois subprocessos: o primeiro verifica todos os produtos e sinaliza os problemáticos. Em seguida, o usuário tem uma tela para decidir o que fazer em produtos sinalizados e valida. Neste momento, temos certeza de que todos os produtos estão OK, podemos iniciar o segundo subprocesso para realizar as outras operações.

O problema é que mesmo que seja simples neste exemplo, pode ser muito mais complicado. Algum processo tem muitas interações de usuários como este, e então pode ser dividido em 10 subpartes. Como eu disse anteriormente, não queremos modificar ou repensar o processo de negócios, para ter certeza de que não perderemos nada ou introduziremos novos bugs nos negócios.

Alguém tem uma experiência sobre isso? Você conhece alguma maneira de lidar com esse tipo de desenvolvimento de desktop para a web?

EDIT 15/07/14

Houve algum mal-entendido sobre este post, certamente relacionado à minha pobre expressão e vocabulário em inglês.

Para resumir o problema:

Eu tenho um monte de fluxos de trabalho de negócios descritos em diagramas UML. Eles vêm de um enorme CAMM de 30 anos de idade (ERP de gerenciamento de produção). O projeto é redesenvolver este aplicativo em ambiente web Java . O ponto principal é que alguns desses fluxos de trabalho são dependentes do usuário, já que, no meio do processamento, eles precisam de uma interação com o usuário. Como os aplicativos da web são baseados em uma arquitetura cliente-servidor, não sei como portá-los. Retrabalhar / repensar esses fluxos de trabalho não é uma opção, porque seria muito demorado. Eu preciso de uma maneira de simular um aplicativo de desktop em um aplicativo da web, como Wt , mas para Java (não estou falando sobre a interface do usuário mas sobre como desenvolver fluxos de trabalho) ou definir regras para tornar esses fluxos de trabalho dependentes do usuário compatíveis com a Web.

    
por OlivierH 10.07.2014 / 17:10
fonte

6 respostas

8

Suas principais dificuldades são que você tem uma incompatibilidade entre um fluxo de trabalho muito linear e personalizado em um aplicativo antigo que não coincide com os fluxos de trabalho de interação do usuário comuns na Web.

Aplicativos da Web que interagem com um aplicativo de servidor que contém a lógica de negócios se comunicam em um estilo de mensagens de Solicitação / Resposta. O navegador do cliente e o servidor que executa um aplicativo que possui a lógica de negócios são processos separados. O cliente solicita um recurso (página html, imagem jpg, dados JSON, etc ...) e o servidor fornece esse recurso de forma inerentemente stateless . Este é um paradigma muito diferente do seu aplicativo de área de trabalho independente que tem um conceito de estado global para uma sessão de usuários. A sessão de usuários em um aplicativo de desktop vive e morre pelo processo em execução na estação de trabalho.

Então, basicamente, há duas maneiras de lidar com a manutenção do estado em um aplicativo da Web que sempre tem um relacionamento cliente / servidor.

Centralizado no servidor

Um aplicativo da Web centralizado no servidor manterá informações com estado para uma sessão de usuário individual. Eles fazem isso normalmente servindo um cookie de sessão quando o usuário é autenticado. O aplicativo cliente (navegador) incluirá seu token de sessão exclusivo com cada solicitação, permitindo que o servidor recupere informações com estado sobre o estado do cliente desde a última vez que recebeu uma solicitação para esse cliente.

Além disso, o servidor conterá a maioria, se não toda a lógica de negócios, por trás da execução de ações que o usuário de negócios típico desejará alcançar, ações que tenham valor comercial real. Isto não deve ser confundido com a lógica de apresentação que é a maior parte do código do lado do cliente (ex. Javascript) que realiza interação na interface do usuário, como esconder um menu particular em um formulário se uma caixa de seleção específica estiver marcada. p>

centralizado no cliente

Embora você possa ter um servidor para manter a autenticação de um usuário e manter uma sessão ativa, é possível usar uma estrutura de script do lado do cliente (por exemplo, estrutura JavaScript como AngularJS para executar a maioria, se não todas as operações de lógica de negócios e operações de lógica de apresentação. As vantagens desse modelo são que você pode programar seu aplicativo da Web da mesma maneira como se poderia programar um aplicativo de desktop. viver e morrer pela navegação do navegador para a página atual da mesma maneira que ele vai viver e morrer no processo de execução de um aplicativo de desktop.Para comunicação com um banco de dados, você pode expor serviços web sem estado no servidor que pode fazer proxy para um banco de dados .

Algumas considerações importantes com essa abordagem são que os usuários nos navegadores clientes têm a capacidade de modificar ou alterar o comportamento do Javascript, o que pode ser potencialmente perigoso e introduzir casos de exceções desconhecidos em seu aplicativo. É altamente recomendável que se essa abordagem for tomada, muito cuidado deve ser tomado nas interações com os servidores para higienizar insumos e validar todos os dados indo e vindo.

Resumo

Em resumo, o aplicativo que você especificou é muito antigo. Parece que você está fazendo a escolha certa ao capturar os fluxos de trabalho atuais e tentar avaliar o que o usuário precisa. O próximo passo seria tentar seguir os princípios do Agile e capturar o valor do negócio nas histórias dos usuários. Eu começaria em um ambiente limpo e tentaria descobrir outros meios e fluxos de trabalho que também pudessem atingir o mesmo valor comercial capturado nas histórias do usuário. Esse aplicativo é tão antigo que, provavelmente, foi limitado pela tecnologia de sua época, onde as restrições técnicas influenciaram os fluxos de trabalho do usuário de maneira negativa ou arcaica. Basicamente, provavelmente existem maneiras melhores, fluxos de trabalho mais intuitivos e interfaces de usuário que a empresa pode usar e que também atingirão as mesmas metas finais.

    
por 11.07.2014 / 18:54
fonte
1

Leia sobre programação assíncrona

Parece que seu aplicativo de desktop original estava strongmente acoplado à GUI, com funções que não continuavam até que o usuário escolhesse as decisões dos pop-ups.

A web e muitas estruturas de GUI simplesmente não funcionam assim - todas as operações que requerem entrada do usuário precisam fornecer um delegado / retorno de chamada para que o processamento possa continuar.

Não é tão ruim assim, mas uma grande mudança em relação ao seu design atual. IMO vale a pena dividir seu design atual para suportar a programação assíncrona, independentemente do kit de ferramentas da Web ou GUI.

    
por 17.07.2014 / 01:03
fonte
1

Este link parece relevante. Isso também parece próximo do link . Eu acho que seu antigo código de "camada de negócios" é escrito com ferramentas da Borland, C ++ ou Delphi?

Há uma década atrás eu portava muitos códigos legados de DOS (Turbo Pascal) de 16 bits para DPMI (Borland Pascal) de 16 bits e para Windows de 32 bits (Borland Delphi). Para portar a parte do DOS como está sem quebrar nada (reescrever o código não era uma opção, apenas pequenas refatorações) a primeira coisa que tive que fazer foi criar um "emulador de terminal do DOS" colocado como um componente dentro de uma GUI do Windows com 32 bits API Win32 e novos componentes do Windows etc. Embora pareça diferente, a forma como o aplicativo DOS trabalha com a entrada do usuário através de diálogos modais etc. é totalmente diferente de como as filas de eventos do Windows funcionam. O emulador organizava as coisas executando o emulador do DOS em um thread separado - todas as funções de E / S do usuário eram redirecionadas para a camada de emulação que, por sua vez, suspendia o thread do DOS ao aguardar um evento do Windows. O código do DOS e sua lógica não foram alterados (quebrados).

No seu caso, você também pode sair elegantemente criando primeiro (usando) um emulador como JSC C # → JavaScript link . Uma vez que você pode executar seu aplicativo "no navegador", você pode adicionar as vantagens necessárias (".. mobilidade, possibilidade de vender versões SaaS, aparência moderna e componentes ...") um por um

Não sei qual tecnologia seria mais adequada para sua linguagem herdada do lado do servidor (a camada de negócios dependente da GUI). Mas a execução na tecnologia do navegador já está aqui, com base no asm.js como o processador da web, consulte, por exemplo, link ou uma lista bastante longa de ferramentas que podem ser usadas para converter código legado para ser executado no navegador em link

    
por 21.07.2014 / 18:53
fonte
0

Aviso de isenção: não sou um desenvolvedor da Web super experiente.

Acredito que o javascript / o lado do cliente de aplicativos da web não são geralmente escritos dessa forma, como não importa o quê, na maioria dos navegadores todo o código js é executado em um thread. No entanto, você pode simular esse comportamento, com algo como este (eu nunca usei, é só o que eu encontrei) , para pausar um thread (pseudocódigo):

var stuffIsDone = false

doInAnotherThread(function () {
    // blah blah blah, do stuff, load purchase, talk to server, whatever

    // ...
    stuffIsDone = true
})

// DO NOT PUT THE BLOCKING WHILE LOOP IN THE MAIN THREAD, IT WILL FREEZE THE INTERFACE
doInAnotherThread(function () {
    while (!stuffIsDone) {} // Do nothing until stuff is done

    // stuff has been done, do whatever
})
    
por 17.07.2014 / 00:22
fonte
0
  > Reworking/rethinking these workflows is not an option

Infelizmente, você precisa adicionar mais estados ao seu fluxo de trabalho, sempre que o fluxo de trabalho antigo solicitar uma decisão do usuário sem alterar o fluxo de trabalho básico.

exemplo no sistema antigo:

customer adds products to basket
...
checkout: customer decides to buy the content of the basket
system does the verifification
    order article is out of stock
        messagebox: "do you want to (a) cancel the order, (b) remove this product or (c) select another one equivalent"?
            (a) ...
            (b) ...
            (c) ...

assim, em vez de mostrar a caixa de mensagem, o estado do fluxo de trabalho intermediário: "Um ou mais artigos esgotados foram atingidos".

Como alternativa, você pode introduzir o estado do fluxo de trabalho intermediário "a ordem não pode ser processada" com informações adicionais sobre os itens que apresentam problemas.

em um aplicativo da web clássico, o cliente é redirecionado para a página de visão geral do carrinho, na qual as mensagens de erro são exibidas ao lado do item de pedido com problemas.

    
por 17.07.2014 / 10:28
fonte
0

@JBRWilkinson está certo, basicamente.

Ter um front-end de cliente da Web e um back-end de servidor da Web é uma coisa altamente assíncrona por definição. Especialmente quando os callbacks entram em ação para carregar dinamicamente dados ou verificar coisas, etc.

Mas você não precisa reescrever o aplicativo inteiro. Você não precisa reescrever o fluxo de trabalho também. Você "apenas" tem que trabalhar nas partes que lidam com a interface do usuário de qualquer forma. Eu escrevo "apenas", porque isso pode ser doloroso o suficiente, especialmente quando toda a lógica está ligada à GUI formulários. Estive lá, fiz isso.

Nós fizemos boas experiências através deste processo, retirando o código da interface do usuário em partes do código compartilhado, abstraindo a interface do usuário. Essas partes de código são usadas a partir da GUI do Desktop e do backend da web. Enquanto a GUI ainda usa controles, etc., como de costume, o back-end da Web renderiza páginas dinamicamente ou entrega JSON ao cliente com base nessas informações. O cliente consiste em uma boa parte do código de script para controlar a interface do usuário da web.

Foi um pouco trabalhoso e fiz algumas refatorações sérias para fazer essa transição, mas valeu a pena. E você aprende muito sobre design de software bom e ruim ao longo do caminho, eu posso te dizer isso.

    
por 17.07.2014 / 10:40
fonte