|
Secretaría de la Función Pública
Estándar para el intercambio de Sistemas Automatizados de Control de Gestión
Fecha: 12 de noviembre 2018
1
|
Secretaría de la Función Pública
Formato G10-F01 Especificación Técnica
Contenido
1. Objetivo del documento
2. Descripción del estándar de oficio electrónico
3. Descripción de los Códigos generales de error que se presentarán en los diversos escenarios de Interoperabilidad
4. Descripción de los Códigos de error que se presentarán en los diversos escenarios de Interoperabilidad
5. Servicios de Interoperabilidad
6. Operaciones de Interoperabilidad
7. Seguridad y conectividad
Objetivo del documento El presente documento tiene por objeto definir, conforme a lo establecido en el artículo décimo tercero del Acuerdo por el que se establece el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal, publicado en el Diario Oficial de la Federación el 6 de septiembre de 2011, las especificaciones técnicas básicas que las Instituciones de la Administración Pública Federal, así como la Procuraduría General de la República, deberán observar para garantizar el intercambio de información en sus sistemas automatizados de control de gestión.
2
|
Secretaría de la Función Pública
Antecedente El Acuerdo Secretarial por el que se establece el Esquema de Interoperabilidad y de Datos Abiertos de la Administración Pública Federal (EIDA), publicado en el Diario Oficial de la Federación (DOF), el 6 de septiembre de 2011, es la base que integra las operaciones de la Administración Pública Federal (APF), con el fin de ofrecer mejores servicios públicos, ejerciendo un gobierno más eficiente, así como apoyando la construcción, protección y mejora del acceso a los bienes públicos de información. La Ley de Firma Electrónica Avanzada publicada en el DOF el 11 de enero de 2012 y su Reglamento, tienen el objeto de regular el uso de la firma digital y de los medios electrónicos en los actos jurídicos, de comunicaciones, procedimientos administrativos, trámites y prestación de servicios que realicen los servidores públicos de la APF en el ámbito de sus atribuciones, entre sí y con los particulares. El 28 de mayo de 2012, la Unidad de Gobierno Digital da a conocer la primer versión del Documento Técnico de Interoperabilidad de los Sistemas Automatizados de Control de Gestión (DTISACG) mismo que sienta las bases para el modelo de interoperabilidad del gobierno mexicano alineado al EIDA. Las Dependencias y Entidades de la APF, así como la Procuraduría General de la República (PGR) deberán apegarse al EIDA para la integración de los sistemas automatizados de control de gestión con que operan y el 21 de noviembre de 2012 publicó una versión actualizada. El 3 de julio de 2015, la Secretaría de Gobernación mediante el Archivo General de la Nación, publicó los Lineamientos para la creación y uso de Sistemas Automatizados de Gestión y Control de Documentos que tiene por objeto establecer las bases para la creación y uso de sistemas automatizados de gestión y control de documentos. El 12 de noviembre de 2018, se publica en las wikiguías de gobmx el Estándar para el intercambio de Sistemas Automatizados de Control de Gestión, de esta manera se establece las especificaciones técnicas que permitan el intercambio de información con independencia del aplicativo o herramienta que cada Dependencia de gobierno determine utilizar, se describe la estructura del documento y las especificaciones a nivel de campo. El presente estándar actualiza lo establecido en el documento técnico para la interoperabilidad de los sistemas automatizados de control de gestión, dado a conocer por la Unidad de Gobierno Digital de la Secretaría de la Función Pública con fecha 21 de noviembre de 2012.
3
|
Secretaría de la Función Pública
1. Descripción del estándar de oficio electrónico
4
|
Secretaría de la Función Pública
5
|
Secretaría de la Función Pública
3
6
|
Secretaría de la Función Pública
7
|
Secretaría de la Función Pública
Atributos
Name Type Use Descripción
FolioOficio xs:string requerido Folio del Oficio electrónico
NumeroOficioElectronico xs:string opcional -
Confidencialidad TipoConfencialida requerido Tipo de confidencialidad del Oficio Electrónico.
Elemento: Diagrama
8
|
Secretaría de la Función Pública
Elemento: TipoOficios
Name Type Use Descripción
TipoOficio TipoOficioElectronico requerido Especifica si el oficio es una Solicitud o una Respuesta a una Solicitud
EnReferenciaAFolio xs:string opcional Folio de Oficio electrónico al que este oficio hace referencia (o da alcance)
EnRespuestaDe xs:string opcional Para oficio de Tipo Respuesta; contiene el Folio de la Solicitud al que se responde
Confidencialidad TipoConfidencialidad requerido Tipo de confidencialidad del Oficio Electrónico.
Diagrama
9
|
Secretaría de la Función Pública
Elemento: Fechas
Name Type Use Descripción
FechaElaboracion xs:dateTime requerido Fecha de elaboración del oficio
EstampadoTiempo EstampillaDeTiempo requerido Nodos que mostraran el estampado del tiempo en TSA
FechaEstampado xs:dateTime requerido
TokenTSA Token requerido
Hash Hash requerido
NoCertificadoTSA Certificado requerido
Diagrama
10
|
Secretaría de la Función Pública
Elemento: AsuntoInstruccion
Name Type Use Descripción
AsuntoInstruccion xs:string requerido Elemento cuyo valor es el texto plano del asunto o instrucción.
Diagrama
Elemento: TrasnformacionImpresa
Name Type Use Descripción
TransformacionImpresa TransformacionOficioElectronico opcional Elemento opcional que permitiría realizar una transformación del Oficio Electrónico para generar su representación impresa.
Diagrama
11
|
Secretaría de la Función Pública
Elemento: Remitente
Name Type Use Descripción
Institucion xs:string requerido Nombre de la institución de Remitente
UnidadOrganizacional xs:string requerido Nombre de la Unidad Organizacional perteneciente
Prsona xs:string requerido Datos personales del remitente
Elemento: Atributos Persona
nombre xs:string requerido -
primerApellido xs:string requerido -
segundoApellido xs:string requerido -
Curp xs:string requerido -
idCargo xs:int requerido -
cargo xs:string requerido -
abrTitulo xs:string requerido -
Diagrama
12
|
Secretaría de la Función Pública
Elemento: Destinatarios/Destinatario
Name Type Use Descripción
Institucion xs:string requerido Nombre de la institución del destinatario
UnidadOrganizacional xs:string requerido Nombre de la Unidad Organizacional perteneciente
Prsona xs:string requerido Datos personales del destinatario
13
|
Secretaría de la Función Pública
Atributos Persona
nombre xs:string requerido -
primerApellido xs:string requerido -
segundoApellido xs:string requerido -
Curp xs:string requerido -
idCargo xs:int requerido -
cargo xs:string requerido -
abrTitulo xs:string requerido -
Diagrama
14
|
Secretaría de la Función Pública
Elemento: Copias/Copia
Name Type Use Descripción
Institucion xs:string requerido Nombre de la institución del copiado
UnidadOrganizacional xs:string requerido Nombre de la Unidad Organizacional perteneciente
Persona xs:string requerido Datos personales del copiado
Atributos Persona
nombre xs:string requerido -
primerApellido xs:string requerido -
segundoApellido xs:string requerido -
Curp xs:string requerido -
idCargo xs:int requerido -
cargo xs:string requerido -
abrTitulo xs:string requerido -
Diagrama
15
|
Secretaría de la Función Pública
Elemento: Anexos
Name Type Use Descripción
Anexo Anexo opcional -
Atributos: Anexos
tipoDeFormato tipoDeFormato opcional Archivos abiertos: PDF, CSV, JSON, XML, ODT.
Diagrama
16
|
Secretaría de la Función Pública
Elemento: Addenda
Name Type Use Descripción
Addenda Addenda opcional Nodo opcional para recibir las extensiones al presente esquema que sean de utilidad al emisor o receptor del Oficio Electrónico. Este elemento posibilita extender la integración entre los SACG, al permitir agregar información que pueda ser procesada de forma automática. Como regla, los elementos aquí agregados al XML del Oficio Electrónico, deberán mantener al Oficio y al Mensaje de Interoperabilidad que se utilice para él envió de este Oficio, como XML válidos. La estructura de dicha información debería ser especificada por la instancia y reforzada su validación mediante la publicación de un esquema de XML como el presente XSD.
Diagrama
17
|
Secretaría de la Función Pública
Elemento: FirmasElectronicas
Name Type Use Descripción
FirmaElectronica FirmaElectronicaOficio requerido En el intercambio de Oficios entre Instancias (escenario de Interoperabilidad entre SACG) se espera que el Oficio contenga la Firma de Autor, sin embargo, para permitir la adopción o uso del Oficio Electrónico al interior de las Instituciones (escenario sin Interoperabilidad entre SACG), se especifica el elemento FirmaElectronica de Autor como opcional. Las instancias (SACG) que reciban un Oficio Electrónico de otra Instancia, deberán validar que el Oficio si contenga la Firma Electrónica de Autor y esta sea válida. El elemento que contiene la información de firma del autor del Oficio Electrónico. Como Propósito de la Firma, se sugiere utilizar alguna descripción como: "Autoría", "Integridad y No repudio" o similar. Para mayor información sobre las características del elemento hijo 'Signature', ver documentación del Tipo Complejo FirmaElectronicaOficio.
Atributos FirmaElectronica
certificadoFirmante xs:base64 requerido -
noCertificadoFirmante xs:int requerido -
18
|
Secretaría de la Función Pública
sello xs: base64 requerido -
Diagrama
Elemento: Archivos
Name Type Use Descripción
ContenidoBase64 xs:base64 Opcional Contenido en base64 de los archivos
ReferenciasURI xs:URI Opcional Información para la descarga URI
DireccionURI xs:URI Opcional
Anotacion xs:string Opcional
Atributos Archivo
identificador xs:int Opcional -
Diagrama
19
|
Secretaría de la Función Pública
Acuse
Atributos
Name Type Use Descripción
folioOficio xs:string requerido Folio del Oficio electrónico
numeroOficioElectronio xs:string opcional -
versionEsquema xs:string requerido Versión del Esquema del oficio electrónico
Nodos
Name Type Use Descripción
IdentificadorDelAcuse xs:string requerido Identificador único del acuse
TipoAcuse xs:string requerido Tipo de Acuse electrónico al que este oficio hace referencia
EnReferenciaAFolio xs:string requerido Para oficio de Tipo Respuesta; contiene el Folio de la Solicitud al que se responde
20
|
Secretaría de la Función Pública
Confidencialidad TipoConfidencialidad requerido Tipo de confidencialidad del
Oficio Electrónico.
FechaEstampado EstampillaDeTiempo requerido Nodo que mostrará el estampado del tiempo en TSA
Diagram
21
|
Secretaría de la Función Pública
2. Descripción de los Códigos de generales de error que se presentarán en los diversos escenarios de Interoperabilidad
Código de Error Descripción
400 BAD REQUEST La solicitud no fue válida. Este código se devuelve cuando el servidor ha intentado procesar la solicitud, pero algún aspecto de la solicitud no es válido; por ejemplo, un recurso formateado de forma incorrecta o un intento de despliegue de un proyecto de sucesos no válido en el tiempo de ejecución de sucesos. La información acerca de la solicitud se proporciona en el cuerpo de la respuesta e incluye un código de error y un mensaje de error.
401 UNAUTHORIZED El servidor de aplicaciones devuelve este código de respuesta cuando está habilitada la seguridad y faltaba la información de autorización en la solicitud.
403 FORBIDDEN Indica que el cliente ha intentado acceder a un recurso al que no tiene acceso. Podría producirse si el usuario que accede al recurso remoto no tiene privilegios suficientes. Los usuarios que intenten acceder a proyectos de sucesos privados que son propiedad de otros podrían recibir también este error.
404 NOT FOUND Indica que el recurso de destino no existe. Esto podría deberse a que el URI no está bien formado o a que se ha suprimido el recurso.
405 METHOD NOT ALLOWED Se produce cuando el recurso de destino no admite el método HTTP solicitado; por ejemplo, el recurso de funciones solo permite operaciones GET.
406 NOT ACCEPTABLE El recurso de destino no admite el formato de datos solicitado en la cabecera de Accept o el parámetro accept. Es decir, el cliente ha solicitado la devolución de los datos en un determinado formato, pero el servidor no puede devolver datos en ese formato.
22
|
Secretaría de la Función Pública
409 CONFLICT Indica que se ha detectado un cambio conflictivo durante un intento de modificación de un recurso. El cuerpo de la respuesta contiene más información.
415 UNSUPPORTED MEDIA TYPE El recurso de destino no admite el formato de datos del cuerpo de la solicitud especificado en la cabecera de Content-Type.
500 INTERNAL SERVER ERROR Se ha producido un error interno en el servidor. Esto podría indicar un problema con la solicitud o un problema en el código del lado del servidor. Se puede encontrar información
3. Descripción de los Códigos de error que se presentarán en los diversos escenarios de
Interoperabilidad
Código de Error Descripción
400 BAD REQUEST La solicitud no fue válida. Este código se devuelve cuando el servidor ha intentado procesar la solicitud, pero algún aspecto de la solicitud no es válido; por ejemplo, un recurso formateado de forma incorrecta o un intento de despliegue de un proyecto de sucesos no válido en el tiempo de ejecución de sucesos. La información acerca de la solicitud se proporciona en el cuerpo de la respuesta e incluye un código de error y un mensaje de error.
401 UNAUTHORIZED El servidor de aplicaciones devuelve este código de respuesta cuando está habilitada la seguridad y faltaba la información de autorización en la solicitud.
403 FORBIDDEN Indica que el cliente ha intentado acceder a un recurso al que no tiene acceso. Podría producirse si el usuario que accede al recurso remoto no tiene privilegios suficientes. Los usuarios que intenten acceder a proyectos de sucesos privados que son propiedad de otros podrían recibir también este error.
23
|
Secretaría de la Función Pública
404 NOT FOUND Indica que el recurso de destino no existe. Esto podría deberse a que el URI no está bien formado o a que se ha suprimido el recurso.
405 METHOD NOT ALLOWED Se produce cuando el recurso de destino no admite el método HTTP solicitado; por ejemplo, el recurso de funciones solo permite operaciones GET.
406 NOT ACCEPTABLE El recurso de destino no admite el formato de datos solicitado en la cabecera de Accept o el parámetro accept. Es decir, el cliente ha solicitado la devolución de los datos en un determinado formato, pero el servidor no puede devolver datos en ese formato.
409 CONFLICT Indica que se ha detectado un cambio conflictivo durante un intento de modificación de un recurso. El cuerpo de la respuesta contiene más información.
415 UNSUPPORTED MEDIA TYPE El recurso de destino no admite el formato de datos del cuerpo de la solicitud especificado en la cabecera de Content-Type.
500 INTERNAL SERVER ERROR Se ha producido un error interno en el servidor. Esto podría indicar un problema con la solicitud o un problema en el código del lado del servidor. Se puede encontrar información
24
|
Secretaría de la Función Pública
4. Servicios de Interoperabilidad
Servicio de envío y recepción de oficios electrónicos Entrada (Literal): La entrada de esta operación es el elemento, el cual tiene la estructura descrita en la siguiente tabla:
Ítem Payload
Petición XML de envío
<?xml version="1.0" encoding="utf-8"?> <OficioElectronico xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" versionEsquema="" folioOficio="" numeroOficioElectronico=""> <TipoOficios> <TipoOficio>Respuesta</TipoOficio> <EnReferenciaAFolio></EnReferenciaAFolio> <EnRespuestaDe>SEP-23-00100000000000005</EnRespuestaDe> <Confidencialidad>Reservada</Confidencialidad> <IdentificadorDelOficio></IdentificadorDelOficio> </TipoOficios> <Fechas> <EstampadoTiempo> <FechaEstampado>2018-10-22T15:29:05.491-05:00</FechaEstampado> <TokenTSA>MIAGCSqGSJhbCBkZS.......FJyHRrxxW4MAAAAA</TokenTSA> <Hash>cMVr7hpCbRkcppJvM75sYD//Nto2qnoPwpnXnJKp4VA=</Hash> <NoCertificadoTSA>100584845342868</NoCertificadoTSA> </EstampadoTiempo> </Fechas> <AsuntoInstruccion>Aplicación de Gráfica Base</AsuntoInstruccion> <TransformacionImpresa>https://sectur.org/sectur-35-00987.pdf</TransformacionImpresa>
25
|
Secretaría de la Función Pública
<Remitente> <Institucion>Secretaria de la Funcion Publica</Institucion> <UnidadOrganizacional>Servicios Digitales y Ciudadanía Digital</UnidadOrganizacional>
<Persona nombre="Daniel Alberto" primerApellido="Hernandez" segundoApellido="Herrera" curp="" idCargo="03" cargo="Director General Adjunto" abrTitulo="Mtro."></Persona> </Remitente> <Destinatarios> <Destinatario> <Institucion>Fondo Nacional de Fomento al Turismo</Institucion> <UnidadOrganizacional>Comunicación Digital</UnidadOrganizacional> <Persona nombre="Rossella" primerApellido="Ciscomani" segundoApellido="Freaner" curp="" idCargo="06" cargo="Gerente y Enlace" abrTitulo="Lic."></Persona> </Destinatario> </Destinatarios> <Copias> <Copia> <Institucion>Secretaria de la Funcion Publica</Institucion> <UnidadOrganizacional>Unidad de Gobierno Digital</UnidadOrganizacional> <Persona nombre="Tania Paola" primerApellido="Cruz" segundoApellido="Romero" curp="" idCargo="02" cargo="Titular" abrTitulo="Mtra."></Persona> </Copia> <Copia> <Institucion>Secretaria de Turismo</Institucion> <UnidadOrganizacional>Estrategia Digital</UnidadOrganizacional> <Persona nombre="Diego" primerApellido="Rendon" segundoApellido="Elizondo" curp="" idCargo="08" cargo="Director" abrTitulo="Lic."></Persona> </Copia> </Copias> <Anexos></Anexos> <Addenda></Addenda>
26
|
Secretaría de la Función Pública
<FirmasElectronicas> <FirmaElectronica sello="VPmS+......pTZg==" certificadoFirmante="MIIAw.....oQmXQ==" noCertificadoFirmante="00001000000400032474"> </FirmaElectronica> </FirmasElectronicas> <Archivos identificador="sectur-35-00987"> <ContenidoBase64>PCFET0NUWVBFIGh0bWw+DQo....JvZHk+DQo8L2h0bWw+</ContenidoBase64> <ReferenciasURI > <DireccionURI>https://gob.mx/archivpenzip.zip</DireccionURI> <Anotacion>El archivo esta en formato zip, la contraseña es: UgD2018Final</Anotacion> </ReferenciasURI> </Archivos> </OficioElectronico>
Salida (Literal): La salida de esta operación es el elemento, el cual tiene la estructura descrita en la siguiente tabla:
Ítem Payload (json, xmlsoap)
Ejemplo de Respuesta JSON
Ejemplo de Respuesta XmlSOAP
27
|
Secretaría de la Función Pública
Operaciones de Interoperabilidad En este apartado se describen, mediante escenarios, las operaciones con las que se construye el flujo de Mensajes y se conforma el esquema de operación de la Plataforma, así como el detalle de la construcción de dichos Mensajes. La descripción detallada de los tipos de Mensajes utilizados en las operaciones a las que hace referencia este Documento Técnico, se encuentra en el archivo XSD 1. Creación, envío, acuse, respuesta y alcance del oficio electrónico.
Descripción: Implementar el estándar de intercambio de oficios electrónicos, entre entes o dependencias de la Administración Pública Federal (APF) utilizando el estándar de oficio electrónico para asegurar la comunicación entre las dependencias. Creación y envío del oficio electrónico de la dependencia A, a la dependencia B.
▪ Remitente Instancia A
Al ingresar tiene las bandejas de enviados y recibidos que le permiten consultar su historial de oficios enviados y recibidos.
➢ Selecciona elaboración de oficio nuevo: Ingresa a la plantilla de oficio Campos pre llenados del emisor:
● Dependencia (emisor) ● Unidad administrativa (emisor) ● Título ● Nombre del servidor público emisor ● Nombre del puesto (emisor) (ejemplo, si el usuario es la titular de la Unidad de Gobierno Digital se
pondrá Unidad de Gobierno Digital, si es el DGA de Servicios digitales sería Dirección General Adjunta de Servicios Digitales
● Leyenda oficial del Año. ● Número de oficio (emisor)
o En caso de no contar con sistema se deberá de utilizar el estándar que es: siglas de la unidad administrativa/ número de la UA/ en su caso siglas de siguiente nivel inferior jerárquico (De acuerdo a la estructura establecida por cada dependencia).
● Domicilio (Calle, Número exterior y Número interior Código Postal, Colonia, Estado, Municipio o Alcaldía) de procedencia o lugar en donde se emite el Oficio.
➢ Selecciona al destinatario considerando CURP o datos (dependencia, nombres, apellidos) del destinatario.
28
|
Secretaría de la Función Pública
Al seleccionar destinatario se pre llenan los campos de destinatario en la plantilla incluyendo:
● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa
➢ Selecciona a los usuarios a los que se enviará copia del oficio
Al seleccionar destinatarios de copia se auto llena la sección inferior de ccp; incluyendo el siguiente listado y la palabra
“Presente” el final de los datos de la persona. ● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa
➢ Selecciona el nivel de confidencialidad que puede ser:
● Confidencial ● Parcialmente Confidencial ● Reservada ● Parcialmente Reservada
➢ Se complementan los siguientes campos del oficio:
● Captura el campo de “Asunto” ● Opcional: Selecciona los archivos para adjuntar ● Captura de texto del oficio ● Firma del oficio: una vez terminado el llenado de campos, se procede a realizar el firmado del oficio
utilizando la efirma del remitente ● Sello digital de tiempo mediante el servicio de TSA de gobmx
➢ Seleccionar la opción de envío de oficio
▪ SACG Instancia A
● Genera XML acorde al estándar de Oficio electrónico propuesto ● Los archivos adjuntos se envían en formato MIME (Content-Transfer-Encoding: base64) ● El SACG envía el XML del oficio mediante web service tipo SOAP
▪ SACG Instancia B
● El SACG recibe por SOAP el XML enviado
29
|
Secretaría de la Función Pública
▪ Destinatario Instancia B
El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio.
➢ Representación en pdf El oficio en XML deberá tener una representación impresa en formato pdf. Para reducir el esfuerzo necesario para la POC se
puede utilizar la representación que actualmente genera los SACG.
30
|
Secretaría de la Función Pública
1. Creación y envío del acuse de recibido de la dependencia B a la dependencia A.
▪ SACG Instancia B
➢ Genera XML acorde al estándar de Oficio electrónico propuesto con los siguientes datos: ● Número de oficio (recibido) ● Folio (asignado) ● Sello digital de tiempo
El SACG envía el XML del oficio al Security server mediante web service tipo SOAP
▪ SACG Instancia A El SACG recibe por SOAP el XML enviado
▪ Destinatario Instancia A El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio en alcance.
➢ Representación en pdf El oficio en alcance en XML deberá tener una representación impresa en formato pdf.
31
|
Secretaría de la Función Pública
2. Respuesta del oficio de la dependencia B enviado por la dependencia A.
▪ Remitente Instancia B
Al ingresar tiene las bandejas de enviados y recibidos que le permiten consultar su historial de oficios enviados y recibidos.
➢ Selecciona elaboración de responder un oficio recibido: Ingresa a la plantilla de oficio Campos pre llenados del emisor:
● Dependencia (emisor) ● Unidad administrativa (emisor) ● Título ● Nombre del servidor público emisor ● Nombre del puesto (emisor) (ejemplo, si el usuario es la titular de la Unidad de Gobierno Digital se
pondrá Unidad de Gobierno Digital, si es el DGA de Servicios digitales sería Dirección General Adjunta de Servicios Digitales
● Leyenda oficial del Año. ● Número de oficio (emisor)
o En caso de no contar con sistema se deberá de utilizar el estándar que es: siglas de la unidad administrativa/ número de la UA/ en su caso siglas de siguiente nivel inferior jerárquico (De acuerdo a la estructura establecida por cada dependencia).
● Domicilio (Calle, Número exterior y Número interior Código Postal, Colonia, Estado, Municipio o Alcaldía) de procedencia o lugar en donde se emite el Oficio.
32
|
Secretaría de la Función Pública
➢ Selecciona al destinatario considerando CURP o datos (dependencia, nombres, apellidos) del destinatario.
Al seleccionar destinatario se pre llenan los campos de destinatario en la plantilla incluyendo:
● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa
➢ Selecciona a los usuarios a los que se enviará copia del oficio
Al seleccionar destinatarios de copia se auto llena la sección inferior de ccp incluyendo el siguiente listado y la palabra
“Presente” el final de los datos de la persona. ● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa
➢ Selecciona el nivel de confidencialidad que puede ser: ● Confidencial ● Parcialmente Confidencial ● Reservada ● Parcialmente Reservada
➢ Se complementan los siguientes campos del oficio:
● Captura el campo de “Asunto” ● Opcional: Selecciona los archivos para adjuntar ● Captura de texto del oficio ● Firma del oficio: una vez terminado el llenado de campos, se procede a realizar el firmado del oficio
utilizando la efirma del remitente ● Sello digital de tiempo mediante el servicio de TSA de gobmx ● Número de oficio al que responde
➢ Seleccionar la opción de envío de oficio
▪ SACG Instancia B
● Genera XML acorde al estándar de Oficio electrónico propuesto ● Los archivos adjuntos se envían en formato MIME (Content-Transfer-Encoding: base64) ● El SACG envía el XML del oficio al Security server mediante web service tipo SOAP
▪ SACG Instancia A
33
|
Secretaría de la Función Pública
El SACG recibe por SOAP el XML enviado por X-ROAD
▪ Destinatario Instancia A El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio.
➢ Representación en pdf El oficio en XML deberá tener una representación impresa en formato pdf. Para reducir el esfuerzo necesario para la POC se
puede utilizar la representación que actualmente genera los SACG.
3. Opcional: Crear un alcance al oficio enviado de la dependencia A, a la dependencia B.
34
|
Secretaría de la Función Pública
▪ Remitente Instancia A Al ingresar tiene las bandejas de enviados y recibidos que le permiten consultar su historial de oficios enviados y recibidos.
➢ Selecciona elaboración de alcance a un oficio enviado previamente: Ingresa a la plantilla de oficio Campos pre llenados del emisor:
● Dependencia (emisor) ● Unidad administrativa (emisor) ● Título ● Nombre del servidor público emisor ● Nombre del puesto (emisor) (ejemplo, si el usuario es la titular de la Unidad de Gobierno Digital se
pondrá Unidad de Gobierno Digital, si es el DGA de Servicios digitales sería Dirección General Adjunta de Servicios Digitales
● Leyenda oficial del Año. ● Número de oficio (emisor)
o En caso de no contar con sistema se deberá de utilizar el estándar que es: siglas de la unidad administrativa/ número de la UA/ en su caso siglas de siguiente nivel inferior jerárquico (De acuerdo a la estructura establecida por cada dependencia).
● Domicilio (Calle, Número exterior y Número interior Código Postal, Colonia, Estado, Municipio o Alcaldía) de procedencia o lugar en donde se emite el Oficio.
➢ Selecciona al destinatario considerando CURP o datos (dependencia, nombres, apellidos) del destinatario.
Al seleccionar destinatario se pre llenan los campos de destinatario en la plantilla incluyendo:
● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia ● Unidad administrativa
➢ Selecciona a los usuarios a los que se enviará copia del oficio
Al seleccionar destinatarios de copia se auto llena la sección inferior de ccp incluyendo el siguiente listado y la palabra
“Presente” el final de los datos de la persona. ● Título ● Nombre (s) ● Primer apellido ● Segundo apellido ● Cargo ● Dependencia
35
|
Secretaría de la Función Pública
● Unidad administrativa
➢ Selecciona el nivel de confidencialidad que puede ser:
● Confidencial ● Parcialmente Confidencial ● Reservada ● Parcialmente Reservada
➢ Se complementan los siguientes campos del oficio:
● Número de oficio de alcance ● Captura el campo de “Asunto” ● Opcional: Selecciona los archivos para adjuntar ● Captura de texto del oficio ● Firma del oficio: una vez terminado el llenado de campos, se procede a realizar el firmado del oficio
utilizando la efirma del remitente ● Sello digital de tiempo mediante el servicio de TSA de gobmx
➢ Seleccionar la opción de envío de oficio
▪ SACG Instancia A
● Genera XML acorde al estándar de Oficio electrónico propuesto. ● Los archivos adjuntos se envían en formato MIME (Content-Transfer-Encoding: base64) ● El SACG envía el XML del oficio al Security server mediante web service tipo SOAP
▪ SACG Instancia B
El SACG recibe por SOAP el XML enviado por X-ROAD
▪ Destinatario Instancia B El destinatario ingresa al sistema de control de gestión y en su bandeja de entrada puede consultar el oficio.
➢ Representación en pdf El oficio en XML deberá tener una representación impresa en formato pdf. Para reducir el esfuerzo necesario para la POC se
puede utilizar la representación que actualmente genera los SACG.
36
|
Secretaría de la Función Pública
37
|
Secretaría de la Función Pública
Especificación de Escenarios Flujo normal de eventos: En el flujo normal de eventos se consideran los siguientes pasos:
38
|
Secretaría de la Función Pública
7. Seguridad y conectividad La utilización de los protocolos HTTPS, SSL y TLS con versiones seguras en la totalidad del aplicativo/sistema es de gran importancia ya que se asegura que la información que viaja entre los servidores y usuarios está encriptada a un nivel alto y aumenta la calidad de la seguridad y confidencialidad de los datos. En términos de la Ley General de Datos Personales en Posesión de los Sujetos Obligados, es responsabilidad de cada dependencia y entidad de la Administración Pública Federal, y empresa productiva del Estado (Institución), determinar el cumplimiento de las disposiciones previstas en la legislación vigente en materia de datos personales. Para efectos del “Acuerdo por el que se emite la guía para la estandarización y certificación de los trámites digitales con el Sello de Excelencia de Gobierno Digital”, esta unidad administrativa únicamente validará que se cumpla con la opinión correspondiente del área jurídica de cada Institución. La comunicación entre los puntos debe ser segura por medio del protocolo de seguridad HTTPS, a fín de garantizar la integridad y la confidencialidad durante la trasmisión. Los servicios de interoperabilidad que se implementen deben hacer uso de servicios web basados en estándares abiertos, con formato de mensajes SOAP/XML sobre protocolo HTTPS. Bajo este esquema se debe integrar el uso de WS-Security (Web Services Security), que cumpla con el estándar de la versión 1.1, específicamente la implementación de la especificación XML-SIGnature, de tal forma que el mensaje SOAP-XML sea firmado electrónicamente antes de enviarlo a la instancia destino, para que garantice la autenticidad, integridad y no repudio de los mismos. Para que las instancias puedan usar la Firma Electrónica Avanzada (efirma) en los Oficios Electrónicos, deberá integrarse un componente en los SACG. El firmado electrónico que efectúan las instancias asegura la auditoría de los oficios generados por las mismas, permite mantener integra la información. El firmado electrónico debe incluir todos los elementos XML del oficio. El XML contará con un estampado de tiempo que se utiliza para dar certidumbre de que los oficios existieron en un momento determinado. Los estampados de tiempo servirán como evidencia forense del envío y recepción de los oficios. El formato de fechas deberá expresarse en UTC (Universal Time Coordinated) y apegarse a la definición TSP (Time-Stamp Protocol) de PKI (Public Key Infrastructure).
39