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