> For the complete documentation index, see [llms.txt](https://kb.stoque.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kb.stoque.com.br/migre-para-zeev/perguntas-frequentes.md). # Perguntas frequentes ### 1 - Após migrar para o Zeev, eu sou obrigado a migrar todos os meus processos do Modo de Execução 1.0 para Modo de Execução 2.0? **NÃO.** Não há nada que obrigue o cliente a migrar seus processos que estão funcionando para o ME 2.0. O suporte ao ME 1.0, por enquanto, é indefinido. ### 2 - Eu sou obrigado a reescrever todos os meus códigos Javascripts desenvolvidos no BPMS3 para usar o Zeev (Bpms4)? **NÃO.** O modo de execução 1.0 permite que seus scripts continuem funcionando normalmente. Você pode, inclusive, criar novos processos usando o modo de execução 1.0, e reutilizar bibliotecas e códigos já existentes. ### 3 - Eu sou obrigado a reescrever todos os meus códigos Javascripts se eu migrar meu processo do ME 1.0 para o ME 2.0? **DEPENDE.** O DOM (Document Object Model) da página mudou. Seu código Javascript filtra elementos do DOM? Seu código Javascript instancia objetos usando seletores? Exemplos: ``` document.querySelector(".col-8 .span .div") document.getElementById("containerMessages") $(".box-user").closest("div") $("#hidUserId") ``` Então sim, provavelmente terá que reescrever, se quiser migrar. ### 4 - Ter que reescrever códigos para poder migrar processos do ME 1.0 para o ME 2.0 é muito ruim. Migrar tecnologias e reescrever ou refatorar códigos faz parte de qualquer projeto de TI e dia a dia de equipes técnicas. É benéfico pois permite manter o produto atualizado com as tecnologias mais emergentes e modernas. Isso permite ter mais mão de obra qualificada disponível para poder dar manutenção. Reescrever ou refatorar é que nem ir no médico esporadicamente; é manter sua saúde em dia. ### 5 - Processos no ME 1.0 não irão funcionar no novo aplicativo mobile? Todos os processos, no ME 1.0 ou ME 2.0, devem funcionar no novo aplicativo mobile ### 6 - Eu posso continuar usando jQuery no Zeev? **SIM.** O Modo de Execução 1.0 vem com essa biblioteca por padrão. ### 7 - Eu não posso usar jQuery no Modo de Execução 2.0? **SIM.** Adicione a biblioteca que você quiser no campo "Cabeçalho" do formulário. ### 9 - Eu posso continuar a usar comandos SQL no Zeev? **DEPENDE.** Os recursos continuam habilitados normalmente em clientes **on premises** e **cloud privado**. Porém, quanto mais você usar, mais dificil será uma futura migração para o cloud compartilhada, a opção mais eficiente economicamente de hosting do sistema. No cloud compartilhado, você poderá continuar usando os recursos já existentes, mas não poderá criar novos. ### 10 - Se eu for para o Zeev no cloud compartilhado meus processos com comandos SQL vão quebrar? **NÃO.** O que já existe de comando SQL Criado, como fontes de dados/integrações, ou tarefas de scripts, continuará funcionando. ### 11 - Se eu for para o Zeev no cloud compartilhado terei que trocar todos os meus comandos SQL existentes por chamadas de APIs? **NÃO.** Continue usando fontes de dados/integrações ou tarefas de scripts já existentes sem problemas. Não é preciso trocar nada. ### 12 - Se eu for para o Zeev no cloud compartilhado eu conseguirei criar NOVAS fontes de dados/integrações que envolvam comandos SQL ou tarefas de scripts? **NÃO.** O sistema irá bloquear a criação de novos registros. ### 13 - Se eu for para o Zeev no cloud compartilhado eu conseguirei REUSAR fontes de dados/integrações com comandos SQL já existentes? **SIM.** As fontes de dados/integrações já existentes, com comandos SQL, continuarão a funcionar, e podem ser reutilizadas mesmo em novos processos. ### 14 - Se eu for para o Zeev no cloud compartilhado não conseguirei VERSIONAR um processo que use comandos SQL e promover melhorias no processo. **DEPENDE**. Ao versionar o processo, mesmo que ele possua fontes de dados/integrações ou tarefas de scripts com comandos SQL, essas continuarão funcionando normalmente. Você pode promover melhorias no processo, criar novas tarefas, modificar o processo a vontade e publicá-lo novamente. Você não poderá modificar o comando SQL das fontes de dados/integrações ou tarefas de scripts existentes. ### 15 - Criar comandos SQL é não é muito mais fácil do que conexões a APIs REST? **DEPENDE.** É claro que isso depende de desenvolvedor para desenvolvedor, mas é inegável que nos dias atuais desenvolvedores cada vez menos manipulam comandos SQL (usam componentes de mapeamento objeto-relacional como Entity Framework e outros) e saber conectar e usar APIs REST é quase uma obrigação e uma das fundações da tecnologia WEB para qualquer DEV. ### 16 - As APIs REST existentes no produto permitem fazer tudo o que eu poderia fazer com SQL? **PROVAVELMENTE NÃO.** E provavelmente será assim para sempre, pois o comando SQL permite acesso total e irrestrito a todo e qualquer dado do sistema (residindo ai um de seus problemas de segurança) e as APIs REST somente o que foi pré-definido pelo produto. Mas nossa camada de APIs tem crescido todos os meses, é parte fundamental da estratégia do produto e estamos abertos a sempre ouvir e atender novos pedidos de APIs. ### 17 - Estou na versão BPMS3 e quero ir para o BPMS4/Zeev. Minha instalação é on premises. Sou obrigado a ir para o cloud da Zeev? **NÃO.** Novos clientes obrigatoriamente vão para nuvem compartilhada ou privada, pois atualmente só compartilhamentos ambientes na nuvem. Clientes já existentes on premises podem continuar on premises, normalmente. ### 18 - Estou usando a versão 4.X (exemplo, 4.10) do BPMS4 no cloud compartilhado. Se eu "migrar para Zeev" ou fizer atualização de versão (exemplo, 4.30), vou perder os comandos SQL? **NÃO.** Não existe absolutamente nenhuma relação entre entre upgrade de versão de produto e disponibilidade ou não de recursos SQL. O produto deve ser sempre atualizado, sempre para a última versão, pois é mais seguro, estável e tem melhorias. A disponibilidade ou não dos recursos SQL é ligada ou desligada a qualquer momento, exclusivamente pela nossa área de infraestrutura, de acordo com cronograma e planejamento combinado entre a área de infraestrutura e o cliente. ##