First Commit - Source Code from Reply
This commit is contained in:
vincenzofariello
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientIBAsincSender ATTIVAZIONE 1 PRP TISC WIND NO_ACCODATA NULL NULL NULL SI N N NULL N NULL 362 SI SI
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientIBAsincSender ATTIVAZIONE 1 PRP TISC WIND ACCODATA NULL NULL NULL SI N N NULL N NULL 362 SI SI
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientIBAsincSender ATTIVAZIONE 1 PRP TISC WIND NO_ACCODATA NULL NULL NULL SI Y N NULL N NULL 362 SI SI
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 5 6 NO_PROGETTI_HOC
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMSender NULL 5
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 2 0 0
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 2 1 1_2
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMSender NULL 2
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientIBAsincSender RISP_ATTIVAZIONE 001 R
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 6 4 R
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMSender NULL 6
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientFlatGenerator NULL 14 RECIPIENT I TIM NULL
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientFlatSender NULL 14 15
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 10 WIND 10.00 N
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 10 WIND 710.00 N
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 10 WIND 110.00 Y
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMSender NULL 10
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 12 WIND 710.00 N
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMSender NULL 12
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMGenerator NULL 11 WIND 110.00 N
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,4 @@
|
||||
SETLOCAL
|
||||
CALL ..\init.cmd
|
||||
%JAVA_HOME%\bin\java -classpath %CPATH% %JVM_ARGS% client.ClientAOMSender NULL 11
|
||||
ENDLOCAL
|
||||
@@ -0,0 +1,104 @@
|
||||
ESECUZIONE TEST RECIPIENT STANDARD:
|
||||
|
||||
NOTA: i passaggi di stato delle richieste avvengono a valle dello scodamento dei messaggi dalle
|
||||
code JMS. Per questo motivo non è raro che ci voglia un pò di tempo affinchè essi risultino
|
||||
sul database. Per qualsiasi dubbio, nella cartella dei log applicativi dovrebbero essere presenti
|
||||
i vari log dei vari sistemi coinvolti nel processo, dai quali si può evincere l'esito di ogni
|
||||
particolare azione simulata.
|
||||
|
||||
1a: ACQUISIZIONE RICHIESTA DA MSP PER SIMULAZIONE FLUSSO PRINCIPALE:
|
||||
Per simulare una richiesta proveniente da un MVNO si può utilizzare lo script '01a_START_RECMVNO_NO_ACC.cmd'.
|
||||
La richiesta generata conterrà una Data di Cut Over per la quale, a valle del controllo di
|
||||
lavorabilità, essa passi nello stato LAVORABILE.
|
||||
Per verificare l'esito del test, si può interrogare la tabella 'MNP_GESTIONE_RICHIESTA_REC' filtrando
|
||||
le richieste che abbiano DATARICEZIONERICHIESTA = TRUNC(SYSDATE) e verificando che la richiesta generata
|
||||
abbia STATO = 2 (ACQUISITA). Si noti come a valle di questa fase, le richieste generata abbiano il campo DA_INVIARE
|
||||
impostato a -1.
|
||||
|
||||
1b: ACQUISIZIONE RICHIESTA DA MSP ACCODAMENTO RICHIESTA:
|
||||
Per simulare una richiesta proveniente da MSP che debba andare, a valle del controllo di inviabilità, in stato
|
||||
ACCODATA, si può utilizzare lo script ''01b_START_RECMVNO_ACC.cmd'.
|
||||
Per verificare l'esito del test, si può interrogare la tabella 'MNP_GESTIONE_RICHIESTA_REC' filtrando
|
||||
le richieste che abbiano DATARICEZIONERICHIESTA = TRUNC(SYSDATE) e verificando che la richiesta generata
|
||||
abbia STATO = 2. Si noti come a valle di questa fase, le richieste generata abbiano il campo DA_INVIARE
|
||||
impostato a -1 ed una data di cut over successiva alla data odierna.
|
||||
|
||||
2: CONTROLLO DI INVIABILITA':
|
||||
Al fine di eseguire il passaggio di stato in INVIATA (o in ACCODATA, se si sta seguendo il flusso cominciato con lo script
|
||||
descritto in 1b) bisogna eseguire il task 'task_attiv', il quale dovrebbe porre il campo DA_INVIARE al valore 1.
|
||||
Successivamente la richiesta passerà automaticamente in stato 04:INVIATA, senza bisogno di sollecitazione esterne (anche se ci mette un pò).
|
||||
|
||||
3: RICEZIONE FILE XML DI PRESA IN CARICO:
|
||||
Per l'invio a DBC dei file XML di Presa in Carico, si possono utilizzare lo script '02_GENERAZIONE_XML_PRESAINCARICO.cmd',
|
||||
e successivamente lo '03_INVIO_XML_PRESAINCARICO.cmd'.
|
||||
Verificare che le richieste nella tabella 'MNP_GEST_RICHIESTA_REC' abbiano a questo punto stato = PRESAINCARICO(6).
|
||||
|
||||
4: RICEZIONE FILE XML DI VALIDAZIONE - NOTA:
|
||||
Al fine di far avanzare le richieste inviate in stato VALIDATA, DBC deve ricevere dei file XML di validazione dagli altri AOM.
|
||||
In questa fase, però, bisogna porre però particolare attenzione al fatto che la ricezione di tali file da parte di DBC è
|
||||
vincolata al loro arriva all'interno di alcune finestre temporali: nel caso in cui, infatti, si riscontrasse un mancato aggiornamento
|
||||
dello stato delle richieste nello stato VALIDATA, si può andare a controllare sul log applicativo 'XMLControllerAAAAMMGG.log'
|
||||
se le richieste inviate sono state scartate per arriva fuori da tali finestre (basta controllare che non siano presenti
|
||||
righe nel log contenenti la dicitura 'DEBUG__FUORI DALLA FINESTRA TEMPORALE...'). In tal caso, dunque, al fine di portare avanti
|
||||
il test anche al di fuori di tale finestre, si può procedere alla loro modifica, nel seguente modo:
|
||||
|
||||
- Effettuando un update sulla tabella MNP_ANAG_FINESTRE_TEMPORALI, cambiando i valori di T_INIZIALE e T_FINALE
|
||||
della riga avente: TIPO_FILE = 2, DESC_FILE = VALIDAZIONE, TIPO_OPERATORE = AOM
|
||||
|
||||
- Modificando il file di properties GestioneXML.xml ( situato in ..../properties/crontab/ ), modificando il tag
|
||||
WindowsTime della seguente sezione:
|
||||
|
||||
<InfoFile fileID="2" name="VALIDAZIONE" desc="VALIDAZIONE">
|
||||
<ListOperatore>
|
||||
<InfoOperatore operatoreID="2" name="H3G" enabled="true" desc_olo="H3GI"/>
|
||||
<InfoOperatore operatoreID="4" name="VODAFONE" enabled="true" desc_olo="OPIV"/>
|
||||
<InfoOperatore operatoreID="7" name="WIND" enabled="true" desc_olo="WIND"/>
|
||||
<InfoOperatore operatoreID="9" name="NOVA" enabled="true" desc_olo="NOVA"/>
|
||||
</ListOperatore>
|
||||
<Schedulation>
|
||||
<WindowsTime start-at="04:00:00" last-start="10:00:00" idRule="0"/>
|
||||
</Schedulation>
|
||||
<Priority>
|
||||
<ProcessType processID="D" processName="Donor" valuePriority="4"/>
|
||||
</Priority>
|
||||
<PriorityIn>
|
||||
<ProcessType processID="R" processName="Recipient" valuePriority="4"/>
|
||||
</PriorityIn>
|
||||
</InfoFile>
|
||||
|
||||
UNA VOLTA EFFETTUATE TALI MODIFICHE, SARA' NECESSARIO RIAVVIARE L'APPLICAZIONE DA WEBLOGIC!!!!!!!
|
||||
|
||||
4a: RICEZIONE FILE XML DI VALIDAZIONE - CASO ACCETTATA:
|
||||
Per la parte relativa al file di validazione che DBC deve ricevere, bisogna utilizzare i seguenti due script per la generazione
|
||||
ed il successivo invio dei file XML di validazione:
|
||||
'04a_GENERAZIONE_XML_VALIDAZIONE_ACCETTATA.cmd'
|
||||
'05_INVIO_XML_VALIDAZIONE.cmd'
|
||||
Una volta avviati i due script, si potrà verificare come le richieste passino in stato VALIDATA(8). Il successivo passaggio di
|
||||
stato ( VALIDATA -> ACCETTATA ), essendo vincolato solo all'invio da parte di DBC di file XML di porting, dovrebbe essere
|
||||
gratuito dal punto di vista dei simulatori: dopo un pò di tempo, dunque, le richieste dovrebbero passare in stato ACCETTATA(10).
|
||||
|
||||
4b: RICEZIONE FILE XML DI VALIDAZIONE - CASO RIFIUTATA:
|
||||
Per la parte relativa al file di validazione che DBC deve ricevere, bisogna utilizzare i seguenti due script per la generazione
|
||||
ed il successivo invio dei file XML di validazione:
|
||||
'04b_GENERAZIONE_XML_VALIDAZIONE_RIFIUTATA.cmd'
|
||||
'05_INVIO_XML_VALIDAZIONE.cmd'
|
||||
Dopo l'esecuzione di tali script, le richieste dovrebbe andare in stato RIFIUTATA.
|
||||
|
||||
5: INVIO RICHIESTA ATTIVAZIONE GISP:
|
||||
Per ottenere il passaggio di stato da 10:ACCETTATA ad 11:ATTESAEVASIONE, bisogna eseguire il task 'task_cess_att_mvno':
|
||||
Tale task controlla che il campo DATA_RICHIESTA_INVIO della tabella MNP_GISP_ATT_OUT per il quale campo TID
|
||||
ha il valore dell'ID_RICHIESTA in elaborazione, sia minore o uguale della data odierna. Per tale motivo,
|
||||
per far proseguire il test, basta fare un update di tale valore della richiesta, impostando
|
||||
DATA_RICHIESTA_INVIO = SYSDATE, e successivamente lanciare il task.
|
||||
Come risultato atteso, ci aspettiamo che la richiesta passi nello stato 11:ATTESAEVASIONE.
|
||||
|
||||
6. RICEZIONE RISPOSTA ATTIVAZIONE DA GISP
|
||||
Per simulare la risposta alla richiesta del p. precedente, eseguire lo script 06_RICEZIONE_RISPOSTA_ATT_GISP.cmd
|
||||
|
||||
7: GENERAZIONE ED INVIO FILE ESPLETAMENTO DONATING E TERZE PARTI:
|
||||
eseguire gli script '07_GENERAZIONE_ESPLETAMENTO_TERZE_PARTI.cmd' e '08_INVIO_ESPLETAMENTO_TERZE_PARTI.cmd'
|
||||
|
||||
8: GENERAZIONE ED INVIO ATTIVAZIONE MSS:
|
||||
eseguire lo script '09_GENERAZIONE_ATTIVAZIONE_MSS.cmd' per la generazione dei file flat di MSS.
|
||||
Per il loro invio utilizzare '10_INVIO_ATTIVAZIONE_MSS.cmd'.
|
||||
Alla fine di elaborazione del
|
||||
@@ -0,0 +1,131 @@
|
||||
ESECUZIONE TEST RECIPIENT STANDARD:
|
||||
|
||||
NOTA: i passaggi di stato delle richieste avvengono a valle dello scodamento dei messaggi dalle
|
||||
code JMS. Per questo motivo non è raro che ci voglia un pò di tempo affinchè essi risultino
|
||||
sul database. Per qualsiasi dubbio, nella cartella dei log applicativi dovrebbero essere presenti
|
||||
i vari log dei vari sistemi coinvolti nel processo, dai quali si può evincere l'esito di ogni
|
||||
particolare azione simulata.
|
||||
|
||||
1a: ACQUISIZIONE RICHIESTA DA MSP PER SIMULAZIONE FLUSSO PRINCIPALE:
|
||||
Per simulare una richiesta proveniente da un MVNO si può utilizzare lo script '01a_START_RECMVNO_NO_ACC.cmd'.
|
||||
La richiesta generata conterrà una Data di Cut Over per la quale, a valle del controllo di
|
||||
lavorabilità, essa passi nello stato LAVORABILE.
|
||||
Per verificare l'esito del test, si può interrogare la tabella 'MNP_GESTIONE_RICHIESTA_REC' filtrando
|
||||
le richieste che abbiano DATARICEZIONERICHIESTA = TRUNC(SYSDATE) e verificando che la richiesta generata
|
||||
abbia STATO = 2. Si noti come a valle di questa fase, le richieste generata abbiano il campo DA_INVIARE
|
||||
impostato a -1.
|
||||
|
||||
1b: ACQUISIZIONE RICHIESTA DA MSP ACCODAMENTO RICHIESTA:
|
||||
Per simulare una richiesta proveniente da MSP che debba andare, a valle del controllo di inviabilità, in stato
|
||||
ACCODATA, si può utilizzare lo script ''01b_START_RECMVNO_ACC.cmd'.
|
||||
Per verificare l'esito del test, si può interrogare la tabella 'MNP_GESTIONE_RICHIESTA_REC' filtrando
|
||||
le richieste che abbiano DATARICEZIONERICHIESTA = TRUNC(SYSDATE) e verificando che la richiesta generata
|
||||
abbia STATO = 2. Si noti come a valle di questa fase, le richieste generata abbiano il campo DA_INVIARE
|
||||
impostato a -1 ed una data di cut over successiva alla data odierna.
|
||||
|
||||
1c: ACQUISIZIONE RICHIESTA DA MSP PER SIMULAZIONE FLUSSO PRINCIPALE CON TRASFERIMENTO CREDITO:
|
||||
Per simulare una richiesta proveniente da un MVNO si può utilizzare lo script '01c_START_RECMVNO_NO_ACC_TrasferimentoCredito.cmd'.
|
||||
La richiesta generata conterrà una Data di Cut Over per la quale, a valle del controllo di
|
||||
lavorabilità, essa passi nello stato LAVORABILE.
|
||||
Per verificare l'esito del test, si può interrogare la tabella 'MNP_GESTIONE_RICHIESTA_REC' filtrando
|
||||
le richieste che abbiano DATARICEZIONERICHIESTA = TRUNC(SYSDATE) e verificando che la richiesta generata
|
||||
abbia STATO = 2. Si noti come a valle di questa fase, le richieste generata abbiano il campo DA_INVIARE
|
||||
impostato a -1.
|
||||
|
||||
|
||||
2: CONTROLLO DI INVIABILITA':
|
||||
Al fine di eseguire il passaggio di stato in INVIATA (o in ACCODATA, se si sta seguendo il flusso cominciato con lo script
|
||||
descritto in 1b) bisogna eseguire il task 'task_attiv', il quale dovrebbe porre il campo DA_INVIARE al valore 1.
|
||||
Successivamente la richiesta passerà automaticamente in stato INVIATA, senza bisogno di sollecitazione esterne (anche se ci mette un pò).
|
||||
|
||||
3: RICEZIONE FILE XML DI PRESA IN CARICO:
|
||||
Per l'invio a DBC dei file XML di Presa in Carico, si possono utilizzare lo script '02_GENERAZIONE_XML_PRESAINCARICO.cmd',
|
||||
e successivamente lo '03_INVIO_XML_PRESAINCARICO.cmd'.
|
||||
Verificare che le richieste nella tabella 'MNP_GEST_RICHIESTA_REC' abbiano a questo punto stato = PRESAINCARICO(6).
|
||||
|
||||
4: RICEZIONE FILE XML DI VALIDAZIONE - NOTA:
|
||||
Al fine di far avanzare le richieste inviate in stato VALIDATA, DBC deve ricevere dei file XML di validazione dagli altri AOM.
|
||||
In questa fase, però, bisogna porre però particolare attenzione al fatto che la ricezione di tali file da parte di DBC è
|
||||
vincolata al loro arriva all'interno di alcune finestre temporali: nel caso in cui, infatti, si riscontrasse un mancato aggiornamento
|
||||
dello stato delle richieste nello stato VALIDATA, si può andare a controllare sul log applicativo 'XMLControllerAAAAMMGG.log'
|
||||
se le richieste inviate sono state scartate per arriva fuori da tali finestre (basta controllare che non siano presenti
|
||||
righe nel log contenenti la dicitura 'DEBUG__FUORI DALLA FINESTRA TEMPORALE...'). In tal caso, dunque, al fine di portare avanti
|
||||
il test anche al di fuori di tale finestre, si può procedere alla loro modifica, nel seguente modo:
|
||||
|
||||
- Effettuando un update sulla tabella MNP_ANAG_FINESTRE_TEMPORALI, cambiando i valori di T_INIZIALE e T_FINALE
|
||||
della riga avente: TIPO_FILE = 2, DESC_FILE = VALIDAZIONE, TIPO_OPERATORE = AOM
|
||||
|
||||
- Modificando il file di properties GestioneXML.xml ( situato in ..../properties/crontab/ ), modificando il tag
|
||||
WindowsTime della seguente sezione:
|
||||
|
||||
<InfoFile fileID="2" name="VALIDAZIONE" desc="VALIDAZIONE">
|
||||
<ListOperatore>
|
||||
<InfoOperatore operatoreID="2" name="H3G" enabled="true" desc_olo="H3GI"/>
|
||||
<InfoOperatore operatoreID="4" name="VODAFONE" enabled="true" desc_olo="OPIV"/>
|
||||
<InfoOperatore operatoreID="7" name="WIND" enabled="true" desc_olo="WIND"/>
|
||||
<InfoOperatore operatoreID="9" name="NOVA" enabled="true" desc_olo="NOVA"/>
|
||||
</ListOperatore>
|
||||
<Schedulation>
|
||||
<WindowsTime start-at="04:00:00" last-start="10:00:00" idRule="0"/>
|
||||
</Schedulation>
|
||||
<Priority>
|
||||
<ProcessType processID="D" processName="Donor" valuePriority="4"/>
|
||||
</Priority>
|
||||
<PriorityIn>
|
||||
<ProcessType processID="R" processName="Recipient" valuePriority="4"/>
|
||||
</PriorityIn>
|
||||
</InfoFile>
|
||||
|
||||
UNA VOLTA EFFETTUATE TALI MODIFICHE, SARA' NECESSARIO RIAVVIARE L'APPLICAZIONE DA WEBLOGIC!!!!!!!
|
||||
|
||||
4a: RICEZIONE FILE XML DI VALIDAZIONE - CASO ACCETTATA:
|
||||
Per la parte relativa al file di validazione che DBC deve ricevere, bisogna utilizzare i seguenti due script per la generazione
|
||||
ed il successivo invio dei file XML di validazione:
|
||||
'04a_GENERAZIONE_XML_VALIDAZIONE_ACCETTATA.cmd'
|
||||
'05_INVIO_XML_VALIDAZIONE.cmd'
|
||||
Una volta avviati i due script, si potrà verificare come le richieste passino in stato VALIDATA(8). Il successivo passaggio di
|
||||
stato ( VALIDATA -> ACCETTATA ), essendo vincolato solo all'invio da parte di DBC di file XML di porting, dovrebbe essere
|
||||
gratuito dal punto di vista dei simulatori: dopo un pò di tempo, dunque, le richieste dovrebbero passare in stato ACCETTATA(10).
|
||||
|
||||
4b: RICEZIONE FILE XML DI VALIDAZIONE - CASO RIFIUTATA:
|
||||
Per la parte relativa al file di validazione che DBC deve ricevere, bisogna utilizzare i seguenti due script per la generazione
|
||||
ed il successivo invio dei file XML di validazione:
|
||||
'04b_GENERAZIONE_XML_VALIDAZIONE_RIFIUTATA.cmd'
|
||||
'05_INVIO_XML_VALIDAZIONE.cmd'
|
||||
Dopo l'esecuzione di tali script, le richieste dovrebbe andare in stato RIFIUTATA.
|
||||
|
||||
5: INVIO RICHIESTA ATTIVAZIONE GISP:
|
||||
Per ottenere il passaggio di stato da ACCETTATA ad ATTESAEVASIONE, bisogno eseguire task 'task_cess_att_mvno':
|
||||
tale task, però, controlla che il campo DATA_RICHIESTA_INVIO della tabella MNP_GISP_ATT_OUT un quale campo TID
|
||||
ha il valore dell ID_RICHIESTA in elaborazione sia minore o uguale della data odierna. Per tale motivo,
|
||||
per far proseguire il test, basta fare un update di tale valore della richiesta, impostando
|
||||
DATA_RICHIESTA_INVIO = SYSDATE, e successivamente lanciare il task.
|
||||
Come risultato atteso, ci aspettiamo che la richiesta passi nello stato ATTESAEVASIONE.
|
||||
|
||||
6. RICEZIONE RISPOSTA ATTIVAZIONE DA GISP
|
||||
Per simulare la risposta alla richiesta del p. precedente, eseguire lo script 06_RICEZIONE_RISPOSTA_ATT_GISP.cmd
|
||||
|
||||
7: GENERAZIONE ED INVIO FILE ESPLETAMENTO DONATING E TERZE PARTI:
|
||||
eseguire gli script '07_GENERAZIONE_ESPLETAMENTO_TERZE_PARTI.cmd' e '08_INVIO_ESPLETAMENTO_TERZE_PARTI.cmd'
|
||||
|
||||
8: GENERAZIONE ED INVIO ATTIVAZIONE MSS:
|
||||
eseguire lo script '09_GENERAZIONE_ATTIVAZIONE_MSS.cmd' per la generazione dei file flat di MSS.
|
||||
Per il loro invio utilizzare '10_INVIO_ATTIVAZIONE_MSS.cmd'.
|
||||
|
||||
|
||||
9: RICEZIONE FILE XML DI TRASFERIMENTO CREDITO:
|
||||
Per l'invio a DBC dei file XML di Trasferimento del credito, si possono utilizzare lo script '10a_GENERAZIONE_XML_TRASFERIMENTO_CREDITO_MIN_SOGLIA.cmd' o
|
||||
'10b_GENERAZIONE_XML_TRASFERIMENTO_CREDITO_MAG_SOGLIA.cmd' oppure '10c_GENERAZIONE_XML_TRASFERIMENTO_CREDITO_ANOMALO.cmd'
|
||||
e successivamente lo '11_INVIO_XML_TRASFERIMENTO_CREDITO.cmd'.
|
||||
Verificare che le richieste siano presenti nella tabella 'MNP_GEST_RICH_REC_TC' abbiano a stato = 7 per lo script 10a_GENERAZIONE_XML_TRASFERIMENTO_CREDITO_MIN_SOGLIA.cmd
|
||||
oppure stato = 2 per 10b_GENERAZIONE_XML_TRASFERIMENTO_CREDITO_MAG_SOGLIA.cmd oppure stato = 3 per 10c_GENERAZIONE_XML_TRASFERIMENTO_CREDITO_ANOMALO.cmd.
|
||||
Verificare inoltre sul DB di DBCGO la presenza dell'ID_RICHIESTA DBCGO_GESTIONE_RICHIESTA_R_TC
|
||||
(il valore dello stato = 1 indica il termine del processo di trasferimento)
|
||||
|
||||
|
||||
OBBLIGATORIO NEL CASO IN CUI AL PASSO 8 SI SIA USATO LO SCRIPT 10b o 10c
|
||||
10:RICEZIONE FILE XML DI SBLOCCO IMPORTO
|
||||
Se al passo 9 è stato lanciato lo script '10b_GENERAZIONE_XML_TRASFERIMENTO_CREDITO_MAG_SOGLIA.cmd',
|
||||
lanciare lo script '12a_GENERAZIONE_XML_SBLOCCO_CREDITO.cmd' e successivamente lo script 13_INVIO_XML_SBLOCCO_CREDITO.cmd
|
||||
Se al passo 9 è stato lanciato lo script '14a_GENERAZIONE_XML_CREDITO_ANOMALO.cmd',
|
||||
lanciare lo script '12a_GENERAZIONE_XML_SBLOCCO_CREDITO.cmd' e successivamente lo script 15_INVIO_XML_CREDITO_ANOMALO.cmd
|
||||
Reference in New Issue
Block a user