10.2REQUERIMENTS PER A LA INTEGRACIO
10.2.1Requeriments d’infraestructura
Donat que la integració es basa en la transferència de fitxers, serà necessari sol·licitar al CPD un usuari d'sFTP en el servidor d’aplicacions de l'aplicació TG. Aquesta petició a CPD l’executarà l’equip del Tramitador Genèric en base a la petició realitzada per la unitat gestora que desitja integrar-se.
Cada Unitat Gestora integrada tindrà un usuari d’sFTP amb l'estructura de directoris que es defineixen a continuació on deixaran els fitxers que corresponents als expedients que es vulguin enviar al TG.
10.2.2Sol·licitud d’alta d’usuari sFTP
El procediment per a sol·licitar l’alta d’un usuari sFTP està detallat a l’apartat anterior d’aquest manual, anomenat: PROCEDIMENT D’ALTA D’USUARI sFTP PER UNITAT GESTORA
10.2.3Estructura de directoris del sFTP
Quan la unitat gestora es connecti a l’sFTP amb l’usuari assignat pel CPD veurà la següent estructura de carpetes:
/
/in
/.done
/.fail
/.res
/out
in : Directori d’entrada
En aquest directori és on es deixaran els fitxers a carregar.
.done: Directori fitxers carregats
Quan un fitxer s’ha carregat amb èxit a l'aplicació TG, es mou de in a .done
.fail: Directori fitxers carregats
Quan un fitxer no s’ha pogut carregar a l'aplicació TG, es mou de in a .fail
.res Directori de informes
Es deixa un llistat amb el resultat del processament de la carrega amb el mateix nom del fitxer zip de la tramesa i l’extensió .ok
Quan es produeixen errors en processar una tramesa, es deixa el llistat de errors en aquest directori amb el mateix nom del fitxer zip de la tramesa i l’extensió .err
out: Directori de sortida
TG deixarà el resultat de les exportacions de dades.
10.2.4Estructura dels fitxers ZIP de les trameses
La comunicació d'expedients a integrar en l’aplicació del Tramitador Genèric es realitza per lots d’expedients als quals anomenem trameses d’expedients.
Cada tramesa consisteix d’un o més documents XML, un per cada expedient que es vulgui integrar amb el TG.
Físicament els documents XML d’una tramesa s’agruparan en un fitxer amb format comprimit (.zip) que ha de seguir les normes que es detallen a continuació.
10.2.4.1Nom del fitxer zip de la tramesa.
És molt important que cadascú dels fitxers zip es pugui identificar de forma unívoca.
Es recomana que els fitxers zip tinguin la següent codificació:
EXP_OOO_TTTTTT_MMMM_yyyymmdd_hhmmss.zip
EXP: És un literal fix que identifica el tipus de fitxer (n’és un fitxer de càrrega d’expedients)
OOOOOO: És un acrònim que identifica la Unitat Gestora (p. ex. SOC, JUS)
TTTTTT: Codi de tràmit.
MMMM: Codi de modalitat.
yyyymmdd_hhmmss : Data i hora de generació del fitxer zip.
L’objectiu d’aquesta codificació recomanada és garantir la unicitat de noms de fitxer dins del sFTP de la unitat gestora i garantir l'ordenació cronològica.
Els fitxers es processaran en ordre de nom, això vol dir per data i hora.
10.2.4.2Estructura del fitxer zip de la tramesa
Els expedients de cada tramesa s’envien al sFTP dins d’un fitxer comprimit .zip amb el nom de fitxer indicat en l'apartat Nom del fitxer zip de la tramesa.
Internament el fitxer zip ha de tenir la següent estructura:
/
.lot
/dades
Fitxer1.XML
Fitxer2.XML
...
FixterN.XML
/annexos
/Fitxer1
Doc1.pdf
Doc2.pdf
/Fitxer2
Doc3.XML
Doc4.docx
Doc5.md5
.lot
És un fitxer de meta informació de la tramesa, el contingut es descriu a continuació.
/dades
És el directori on s’han d'incloure els fitxers XML dels expedients que s'envien al TG en aquesta tramesa
/annexos
És el directori on s’han d'incloure els documents annexos referenciats en els XML.
Crearem un subdirectori per cada document XML de la carpeta dades que tingui documents. El nom del subdirectori ha de ser el mateix del document a qui pertanyen els documents annexos sense l’extensió XML.
Els documents annexos han d'estar referenciats dins del document XML en el tag de l’element , només caldrà indicar el nom i extensió del fitxer adjunt.
10.2.4.2.1Dades del fitxer .lot
El fitxer .lot és un fitxer de text amb l'estructura típica d'un fitxer de propietats: clau=valor
El fitxer .lot ha de contenir la següent informació:
UnitatGestora=SOC
CodiTramit=BGP001
CodiModalitat=SOLC
DataTramesa=yyyymmdd hhmmss
NombreExpedients=nnnnn
10.2.4.2.2Format del nom dels fitxers XML.
El format del nom dels fitxers XML és lliure, encara que es recomana la següent estructura:
_yyyymmdd_hhmmss.XML
CODIORIGEN: És el codi que identifica unívocament l’expedient en l'aplicació d’origen
yyyymmdd_hhmmss : Data i hora de generació del fitxer XML.
Dins del zip, el codi d’origen de l’expedient ja identifica unívocament el document. La data i hora és interessant quan es torna a generar el mateix fitxer en una segona tramesa, normalment per a la correcció d’errors.
Els documents es presentaran per defecte per ordre de codi d’origen encara que l’usuari podrà ordenar per altres criteris.
10.2.4.2.3Format del nom dels fitxers annexes
El format del nom dels fitxers annexos és lliure donat que es troben dins una carpeta amb el nom del document a qui pertanyen i per tant no poden haver-hi noms duplicats.
10.2.5Requeriments d’aplicació
Per poder fer la integració d’expedients amb el Tramitador Genèric, primer serà necessari definir dins l’aplicació:
-
La unitat Gestora
-
Els tràmits i modalitats dels tipus d’expedient que s’enviaran
-
Els usuaris de l’aplicació amb els seus rols
-
Els tràmits i modalitats autoritzades a aquests usuaris
Tots aquests requeriments són executats i satisfets per l’equip del Tramitador Genèric juntament amb l’àrea de Solucions Transversals del CTTI, només correspon a l’Administrador de Tràmits completar la configuració dels tràmits-modalitats i crear la resta d’usuaris atorgant-los els drets d’accés..
10.2.5.1Creació de la Unitat Gestora
Es definirà la unitat gestora amb el seu nom i codi o acrònim.
Aquest mateix codi es fa servir per crear la carpeta sFTP de cada unitat gestora.
La definició d’aquesta informació al Tramitador Genèric pot fer-se en el moment inicial de l’alta del tràmit o posteriorment assignant aquest atribut a la unitat gestora propietària del tràmit. En qualsevol cas és una tasca que executarà l’equip del Tramitador Genèric juntament amb l’àrea de Solucions Transversals del CTTI quan es té confirmació que la unitat gestora propietària del tràmit té habilitat l’usuari sFTP per a la càrrega massiva d’expedients.
10.2.5.2Definició de tràmits i modalitats
L’equip de Solucions transversals del CTTi haurà de donar d’alta a l’aplicació el tràmit i almenys una modalitat d’aquest tràmit.
Un tràmit s'assigna a una unitat gestora en el moment de creació del tràmit. És molt important tenir en compte que tot el procés de càrrega massiva està totalment relacionat amb la Unitat Gestora, ja que l'acrònim d'aquesta és la carpeta sFTP on es realitzarà la transferència de fitxers.
Això implica que a la carpeta sFTP es trobaran els diversos fitxers que puguin haver-hi de tots el tràmit/modalitat, amb el procés de càrrega massiva activat, que comparteixin la unitat gestora.
Els codis de tràmit i modalitat els necessiteu perquè els haureu d’incloure al fitxer .lot del zip de cada tramesa, veure el punt Dades del fitxer .lot. i també perquè s’han d’incloure al document XML de cada expedient als tags i de l’element
Heu de recordar que tots els expedients d'una tramesa (tots el que van en el mateix zip) han de ser del mateix tipus i per tant tindran el mateix codi de tràmit i modalitat.
La versió de negoci tot i ser obligatòria no es valida en el canal de càrrega massiva (propietat heretada del GRO de GSIT). Es recomana posar el valor 201701, és a dir, l’any d’entrada del tràmit/modalitat i el mes 01.
10.2.5.3Definició d’usuaris de l’aplicació amb els seus rols
S’hauran de donar d’alta a l’aplicació els usuaris amb els rols d’Administrador de Tràmit, Gestor d’Unitat i Usuari Tramitador.
L’Administrador de Tràmit serà l’encarregat de:
-
Configurar el tràmit/modalitat.
-
Crear la resta d’usuaris i atorgar-los els drets d’accés als tràmits/modalitats que hagin de gestionar.
-
Consultar l’estat de les càrregues.
10.2.5.4Autoritzar els usuaris als tràmits-modalitat
Cada gestor d’unitat haurà de atorgar drets d'operació als usuaris tramitadors (gestors) que consideri per tramitar els expedients del tràmits-modalitat de la seva competència.
10.3FORMAT D’INTERCANVI DE L’EXPEDIENT
10.3.1Presentació
En aquest apartat es defineix el format del document XML que accepta l'aplicació TG per importar els expedients de l'aplicació d’origen.
El document d'intercanvi és un fitxer XML amb codificació UTF-8 compatible amb el format del servei de GESTIÓ DE RESPOSTES ONLINE de la PICA conegut per les seves sigles GRO.
S’ha triat el format GRO per ser un format estàndard que ja admet actualment l’aplicació TG per altres canals d'integració com l’OVT o el Canal Empresa.
El format GRO és molt ampli i hi ha molts elements de dades opcionals que no farem servir. Per tal de facilitar la integració s’ha definit un esquema xsd que serà el subconjunt de GRO utilitzat en aquesta integració i que és compatible amb el format GRO original.
El format complet del GRO es pot consultar al document P070085-OTPICA-PD3-GU-Guiad'us del servei GRO.pdf i els esquemes al fitxer xsd_GRO_v6.1.zip. Es poden descarregar des de la següent URL http://ipae.intranet.gencat.cat/index.php?page=GRO de la intranet del CTTI.
10.3.2Esquema GROTGLite
S’ha dissenyat un esquema xsd que anomenem GROTGLite que és un subconjunt de l’esquema PICA_GRO_BO_Sol-licitud que al seu torn està basat en l’esquema GSIT_PICA_GRO_Sol-licitud de la PICA.
L’esquema GROTGLite és totalment compatible amb els documents XML GRO.
L’esquema GROTGLite està format pel document GROTGLite.xsd i un seguit de documents xsd complementaris que defineixen tipus de dades del document principal.
Els document auxiliars són els mateixos (sense cap canvi) que els definits a l'esquema del GRO original. Aquests són els documents xsd complementaris:
-
MIS-V31-CodiLlistaIdiomasISO639-1.xsd
-
MIS-V31-CodiLlistaPaisosISO3166-1.xsd
-
MIS-V31-CodiLlistaTipologiesDocumentals.xsd
-
PicaAvis.xsd
-
PicaError.xsd
-
TipusBasics_V165.xsd
10.3.2.1Comparació amb l’esquema original -
El nom de l’element arrel s’ha canviat de PICA_GRO_BO_SOLLICITUD a TG_GROLITE_SOLLICITUD.
-
S’han tret els elements opcionals que no són necessaris.
El següent document xsd mostra comentats amb @REMOVE els tags que s’han eliminat.
-
Bloc especial a dades particulars.
L'element de dades particulars segueix essent del tipus xs:anyType, però el sistema validarà l’existència de l’element CodiExpedientOrigen ubicat en el path XML:
/DadesParticulars/DadesTramitadorGeneric/ExpedientOrigen/CodiExpedientOrigen
De manera opcional, en aquest bloc especial anomenat DadesTramitadorGeneric dins de les dades particulars es podran informar dos opcions més:
-
URL de l’expedient d’origen (UrlExpedientOrigen).
Es podrà informar de la URL del sistema d’informació on es visualitza o relaciona l’expedient d’origen
-
Etiquetes de l’expedient
Es podran informar, separades per coma, les etiquetes que es volen assignar a l’expedient de manera automàtica en donar-se d’alta al Tramitador Genèric.
Han de ser etiquetes existents per al tràmit-modalitat configurat a nivell d’administració de l’aplicació.
10.3.2.1.1DadesParticulars/DadesTramitadorGeneric
Actualment s’ha definit les següents dades a l’element especial DadesTramitadorGeneric descrit abans:
-
CodiExpedientOrigen
-
UrlExpedientOrigen
-
Etiquetes
Ubicació
|
Nom
|
Tipus
|
Req
|
Descripció
|
DadesTramitadorGeneric
|
ExpedientOrigen
|
-
|
Si
|
Dades identificació expedient d’origen
|
ExpedientOrigen
|
./CodiExpedientOrigen
|
string(100)
|
Sí
|
Codi obligatori de l’expedient a l’aplicació d’origen
|
ExpedientOrigen
|
./ UrlExpedientOrigen
|
string(100)
|
No
|
URL per accedir a l’expedient en l’aplicació de origen amb el navegador des de el Tramitador genèric
|
DadesTramitadorGeneric
|
Etiquetes
|
string(100)
|
No
|
Cada etiqueta que es vol afegir a l’expedient separada per coma
|
CodiExpedientOrigen>SOCSANC2017100001
http://sistematercer.gencat.cat/codiexpedientSOCSANC2017100001
Etiqueta,Etiqueta2,Etiqueta3
<... a partir d’aquí les dades particulars reals de l’expedient... >
10.3.2.2Exemple de document XML GROTGLite
S’adjunta a continuació una instància d’exemple d’un GROTGLite
10.3.2.3Exemple de tramesa ZIP
S’adjunta a continuació un ZIP de tramesa
10.3.3Fitxers de resultats 10.3.3.1Format del fitxer d’errors
Per cada tramesa processada, el sistema deixa al directori .res de l’sFTP un fitxer de text amb els errors que hagi trobat amb el següent format. El nom del fitxer es el mateix del zip amb la extensió .err.
Registres processats: nnnnnnn
Registres amb error: nnnnnnn
Detall dels errors:
# #
# #
....
# #
Si no hi ha errors, el fitxer es genera igualment amb les dues línies de capçalera.
10.3.3.2Format del fitxer de resultat de processament
Per cada tramesa processada, el sistema deixarà al directori .res de l’sFTP un fitxer de text amb els expedients processats correctament amb el següent format. El nom del fitxer es el mateix del zip amb la extensió .ok.
Registres processats: nnnnnnn
Registres carregats: nnnnnnn
Detall dels expedients generats:
# #
# #
....
# #
Si no hi ha errors, el fitxer es genera igualment amb les dues línies de capçalera.
10.4CONSIDERACIONS SOBRE LES APLICACIONS D’ORIGEN
L’objectiu de la integració amb el canal de càrrega massiva d’expedients és disposar d’un nou servei d’entrada d’expedients provinents d’altres sistemes d’informació departamentals. Cada aplicació des del sistema d’informació d’origen de cada Unitat Gestora pot assolir els requeriments de la integració de forma diferent que sigui adient a les seves característiques, no obstant això, totes hauran de plantejar-se les consideracions que es relacionen a continuació:
-
Determinació del codi d’origen de l’expedient.
-
Extracció d’expedients a enviar en una tramesa
-
Constància de la transferència finalitzada de la tramesa
-
Constància de la integració (processament) de la tramesa.
-
Correcció d’errors i reenvio d’expedients no processats per error.
-
Reenvio d’una tramesa sencera.
10.4.1Determinació del codi d’origen
El Tramitador genèric assigna un codi d’expedient a cada expedient que li arriba, no obstant això, és necessari tenir un codi que unívocament identifiqui a l'expedient en origen per poder establir la correspondència entre expedient TG i expedient origen.
Aquest codi ha d'incloure el tipus d'expedient i no només el nom. Per exemple, si a origen tenim un procediment sancionador SAN1 i un procediment sancionador SAN2 i cadascú numera per any/seqüència, El codi d’origen ha de ser SANx-any/seqüència.
10.4.2Selecció d'expedients a enviar en una tramesa
El primer problema és determinar quins expedients enviar al Tramitador, com generar les trameses assegurant que s’envien els expedients que s’han d'enviar i no ens deixem cap o no enviem el mateix expedient dues vegades en diferents trameses.
10.4.3Constància de la integració de la tramesa
La revisió dels directoris sFTP de .fail i .done i del contingut del fitxer de resultats en el directori .res proporcionarà la informació per verificar el processament d'una tramesa. En un futur es planteja la creació d'un nou perfil d'usuari de tipus tècnic que pugui gestionar l'estat de les trameses des d'una pantalla de l'aplicació.
10.4.4Correcció d’errors i reenvio d’expedients no processats per error
Inevitablement es produiran errors en el processament d’expedients al TG que rebutjarà el document XML. S’ha previst el mecanisme per corregir els documents o les dades dels documents a origen i tornar a enviar els documents rebutjats en una tramesa d’erronis o en una tramesa que els inclogui.
Nota: Els errors que no depenen de les dades d’origen se solucionen re processant el document original a TG, no cal tornar-ho a enviar.
. 06/08/2018
Dostları ilə paylaş: |