Tarefa | Responsável | Breve orientação | Lição aprendida |
---|
T1.01 - Instalar/Atualizar versão do Hotel | Cliente | - Essa integração está disponível a partir das versões v12.1.2210.08.
| Essa atividade deve ser executada com pelo menos 4 dias antes da migração do VHF API para o BT VHF. No piloto, deixamos de atualizar previamente a versão, e no terceiro dia, tivemos inconsistência nos check-outs, e o BT VHF lançou em contas encerradas.
|
T1.02 - Mapear os pontos de atenção existentes na operação do hotel, referente a integração entre o POS x VHF API x VHF. | Cliente TOTVS | - Atividade relevante para identificarmos particularidades na operação do cliente, e medir, se a versão do BTVHF atenderá toda a integração.
- Os pontos identificados, devem ser reforçados com testes após a mudança do VHF API para BT VHF.
| Apesar da operação simplificada do hotel piloto, identificamos durante a migração, que o piloto não utilizava conta pendente.
Este comportamento "quebrou" a atualização das contas de check-in para check-out, e, toda vez que o hotel liberava um quarto para pendente, antes do check-out, as contas não eram "retiradas" do POS. Pontos que sugiram durante a entrevista dessa atividade: - Cliente utilizava desconto em contrato por tipo de débito e crédito.
- BT VHF atendia essa rotina.
- Contas eventos que não migravam no VHF API, e para isso, era utilizada conta avulsa.
- BT VHF atendia essa rotina.
|
T1.03 - Hotel liberar acesso ao servidor de API. | Cliente TOTVS | - Atividade necessária para testar a conexão ao servidor em que será feito o pré-setup do projeto.
- Recomenda-se utilizar ferramentas oficiais da TOTVS para realizar conexão no servidor de API do cliente.
- A execução dessa atividade será premissa para a validação e instalação do ambiente.
| - Para o piloto, foi disponibilizado um hardware com os requisitos abaixo:
- Processador i5 / 16GB de memoria / Wind10 Pro
- Neste servidor o VHF API estava em execução antes de receber a instalação do BT VHF.
- Durante a execução do projeto, migramos 1 hotel. Para depois migrarmos outros 2.
- Este recurso é fundamental para que o time de implantação do BT VHF possa realizar o pré-setup antes da chegada no cliente.
IMPORTANTE: - BT VHF ficou em execução, simultânea, com o VHF API durante 12 dias.
- Sem perda de performance. E;
- Não houve perda de consumo, travamento e/ou outras crises.
|
T1.04 - Validar ambiente do Servidor de API para instalação do BT VHF. | TOTVS | - Atividade necessária para garantir a estrutura de pastas padrão da TOTVS para funcionamento da integração.
- O BT VHF deve ser instalado na pasta hotéis.
- Não existe conflito entre BT VHF e VHF API.
- Recomenda-se que não existe exista mais de uma pasta ..\TOTVS\HOTEIS.
- Toda reestruturação de pastas não deve ser realizada antes durante da virada.
- Qualquer ação neste sentido, recomenda-se fazer após 4 dias antes ou depois, da virada. Motivo: Evitar crises durante os primeiros dias da migração, e com isso, mitigar ruídos.
| - Para o piloto, tentamos unificar a estrutura da pasta TOTVS em uma só, porque o servidor de API do cliente tinha mais de uma pasta Hotéis.
- Tentamos realizar esta atividade no segundo dia da virada. E, o resultado não foi positivo. Em um determinado momento, o VHF API não consegui mais abrir, e tivemos que retornar toda a estrutura de pastas.
- Esta ação gerou gasta de tempo do time sem necessidade para estabilizar um cenário que estava estável.
|
T1.05 - Instalar do BT VHF no Servidor de API e os demais serviços.
| TOTVS | Pacote - Worker / Robot (Hotal Monitor) / Plugins
- A instalação dos serviços/plugins acima, será premissa para o Go-Live do projeto. Sem essa atividade, os pontos de entrada e conexão entre POS x BT VHF não acontecerão.
- Worker - Serviço que será responsável pela integração dos consumos e interação com a fila do POS.
- Hotal Monitor - Serviço que fará o monitoramento do Worker, e será responsável por reiniciar o serviço Worker, caso ele trave ou caia.
- Plug-ins - jornadas responsáveis por realizar a integração dos quartos, contas, dados dos hóspedes, empresa e validação de mesa/consumos que estão em aberto no POS.
| - Em Bases/clientes que possuem mais de um hotel, não podemos excluir a pasta …\TOTVS\HOTEIS, onde o VHF API está estiver instalado.
- Caso exista mais de uma pasta ..\TOTVS2\HOTEIS, ..\TOTVS\HOTEIS2, ..\TOTVS\HOTEIS61131, e outras.
- Não executar o instalador da versão v12.1.2210.07 08 na pasta em que o VHF API estiver em execução.
- Neste cenário, crie uma pasta ..\TOTVS\HOTEIS_BT, para receber a instalação da release nova e o BT VHF.
- Durante o piloto identificamos que existe uma bpl que causa conflito entre o VHF, o VHF API e o BT VHF.
- Esta ação não subscreverá o VHF API, evitando que pare/trave para os demais hotéis.
|
T1.06 - Solicitar a criação da Fila de consumos na AWS | TOTVS | - Todo projeto de integração POS x BT VHF x VHF precisará de uma fila “on-line” para que o POS gere os consumos e o BT VHF leia e integre com o VHF.
- Essa atividade prevê a abertura de issue para o time de CLOUD.
- Para abertura da issue, faz-se necessário solicitar ao time do POS a fila do cliente que será implantado, para que essa informação seja incluída na issue.
- A informação enviada pelo time do POS será parametrizada no BT VHF.
IMPORTANTE: - Atentar-se para o SLA.
- Precisa ser criada com antecedência a data em que acontecerá o Go-Live.
Exemplo da fila: A fila abaixo é um exemplo e não funciona. Será essa chave que será incluída no parâmetro do BT VHF de acordo com TDN. btvhf-invoice-integration-XbeRd999-4XEd-40ba-9WE7-0c42bOIn8be4-filaW |
|