1) sotto C:\Users\AOM\Desktop\Sviluppo\TIM\DBCFX\dbcfx\FE\gnpdev\sim\script\win si trova il file per acquisire nuove richieste ./Rientro_NPg35_B_con_invio.cmd se si vuole generare una richiesta con più dn in ingresso it.valueteam.gnpsim.client.ClientIBGenerator 1 2 1 NPg35 RIENTRO B ABA 1 005 1 NULL diventa it.valueteam.gnpsim.client.ClientIBGenerator 1 2 1 NPg35 RIENTRO B ABA 2 005 1 NULL Se invece si vuole inviare un file custom creato da noi si può lanciare ad esempio InvioDaIB_B.cmd prima però bisognera creare il file in questione e posizionarlo sotto il path C:\gnpapp92\simulatore\IB\CRMB un esempio di file xml lo si trova in questa cartella 2) Generati i file si dovrà lanciare il batch che genera il file xml da inviare a fenp. Prima di fare questo però si deve configurare il simulatore in modo che simuli la risposta (ack) da FENP. Si deve quindi andare al seguente indirizzo: http://10.166.18.15:11101/SimOLO/ E incollare un xml come questo:
TLC N N_NP_TLC_I1J_20200427_10003.xml
00 File trasferito correttamente e valido
Salvare. Fatto questo quando si invierà il file verso FENP (OloControllerFenp -> processaFileFenpOut) verrà generata in automatico una risposta adeguata che permette di proseguire nel processo. File batch per portare ed inviare a FENP le richieste NPG35 acquisite in precedenza: Invia_Verifica_Fenp_NPg35.sh (npg35 classiche) Invia_Verifica_Fenp_Del35_MultiD.sh (multidonor npg35) Invia_Verifica_Fenp_Del35_MultiD_OloNative.sh (multidonor olo35) 3) A questo punto bisogna simulare la risposta per l'olo della presa in carico. Richiamare la pagina http://10.166.18.15:11101/SimOLO/sendRispostaOlo.jsp inserendo i valori richiesti per l'invio file da FENP (tipo R, tipo_comunicazione=2) Il primo passo da fare è creare il file di risposta da Fenp. Esempi di file creati si trovano qua: C:\Users\AOM\Desktop\Sviluppo\TIM\DBCFX\dbcfx\FE\gnpdev\sim\script\doc\NPG35 Si può prendere il file R_NP_codiceOloDonor_TLC_yyyyMMdd_progressivo.xml come esempio. Si può quindi creare una copia di questo file ( da modificare) cambiando il nome con gli attributi giusti: Nome File = R_NP_codiceOloDonor_TLC_yyyyMMdd_progressivo.xml con codiceOloDonor = KEA se nativo TELECOM, oppure il donor in caso di NATIVI OLO Quindi ad esempio in questo modo: R_NP_KEA_TLC_20200422_00001.xml Il file creato deve essere modificato in questo modo: Nel file CodiceOrdine = GNP_FENP_RICHIESTE_OUT.CODICE_ORDINE, IdentificativoOperatoreDonor = TLC se nativo TELECOM, oppure GNP_FENP_RICHIESTE_OUT.COD_OP_DONATING nel caso di NATIVI_OLO, DirectoryNumber = GNP_FENP_RICHIESTE_OUT.DN (TipoComunicazione è settato a 2, poi lo si può cambiare in base al test che si vuole fare) Fatto questo si può passare alla valorizzazione dell'interfaccia della jsp: simulatoreGNP.properties lato server = /gnpapp/simOLO/simulatoreGNP.properties OLO Mittente = KEA (credo dipende come nome file se si tratta di nativo telcom o no) Tipo File = R Nome file = quello appena creato File = selezionare il file creato Una volta inviato viene richiamato il metodo acquisisciFileOloIn della classe OloControllerFenp. La richiesta di business passa in stato 03:VERIFICATA_FENP (su GNP_RICHIESTE_NPG35) ed inviata a CRMB la notifica della presa in carico. Esempio tracciato Invio notifica a CRMB di validazione olo (presa in carico) 1-5S6OBY4 1-5SRBEBY OK NPg35 VALIDAZIONE_OLO DMS 12-05-2020 22-04-2020 12:28:17 22-04-2020 12:28:17 084 1-5SRDTMP N Nota qui c'è lo split si dovranno testare i vari casi, i vari tipi di comunicazione. FENP KO ecc. 5) A questo punto bisognera far passare la richiest in ACCETTATA ed INVIATA CRM. Per farlo non c'è una notifica CRM in questo caso, non so perchè ma sull'accettata c'è un if sul tipo di richiesta e quelle NPG35 non passeranno in accettata tramite notifica di CRM, ma bensi tramite scadenza silenzio assenso. [ In caso di tipo comunicazione 6: if (0 == fenpRichiestaIn.getEsito().intValue() && (ProcessMapper.proc_RIENTRO_NATIVIOLO.equals(processo) || ProcessMapper.proc_RIENTRO_NATIVIOLOGNR.equals(processo))) { log.write("9999", methSig + methSigTail + "avanza stato a ACCETTATA"); RequestManagerNPg35.avanzaStatoInAccettata(fenpRichiestaIn.getDataRicezione(),richNpg35, log); } else { log.write("9999", methSig + methSigTail + "avanza stato a RIFIUTATA_FENP"); RequestManagerNPg35.avanzaStatoInRifiutata_fenp(richNpg35, log, fenpRichiestaIn); } ] - Impostare la DATA_SILENZIO_ASSENSO delle richieste di business (su GNP_RICHIESTE_NPG35) al valore sysdate-1 - Lanciare lo script sul server ./Check_Silenzio_Assenso.sh nella directory /gnpapp/script La richiesta principale passa in stato 05:ACCETTATA e successivamente. Ed automaticamente partirà il processo di presa in carico della richiesta secondaria, dato che il processo parte in automatico, prima di startare il checksilenzioassenso bisogna simulare la risposta per il dn2 di fenp, come spiegato in precedenza tramite: http://10.166.18.15:11101/SimOLO/ Completato questo avremmo le richieste in stato , Inviata Fenp. Bisogna quindi ripartire dal passo 3 ed effettuare l'iter per il secondo dn. Completato l'iter della seconda richiesta ci troveremo la richiesta in stato 06:INVIATA_CRM. Nota le richieste associate della tabella gnp_richieste_del35_multid si fermano qui con gli stati, allo stato 5. Perchè fino a questo punto la richiesta risultava sdoppiata a questo punto si procede come una singola richiesta, cioè quella della gnp_richieste_npg35. in maniera automatica allo stato 06:INVIATA_CRM