Skip to main content

Proyecto3_Documentación

Page 1

Universidad de San Carlos de Guatemala Escuela de Ingeniería en Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026

SISTEMA SAT: INTEGRACIÓN DE API, FRAMEWORK Y HTTP

202504833 – Schneyder Anderson Emmanuel Esquit Xico Resumen

Abstract

Este documento presenta el diseño e implementación de un simulador de facturación electrónica (DTE) basado en la web. Construido sobre una arquitectura cliente-servidor desacoplada usando C# y .NET Core, el sistema comprende un backend de ASP.NET Web API y un frontend de Razor Pages. Además, la plataforma incorpora endpoints analíticos de reportes, visualización gráfica y capacidades completas de reinicio del sistema, demostrando una solución robusta, mantenible y desacoplada de ingeniería de software orientada a objetos.

This document presents the design and implementation of a web-based e-invoicing simulator (DTE). Built on a decoupled client-server architecture using C# and .NET Core, the system comprises a Web API ASP.NET backend and a Razor Pages frontend. In addition, the platform incorporates reporting analytics endpoints, graphical visualization, and full system reboot capabilities, demonstrating a robust, maintainable, and decoupled object-oriented software engineering solution. Keywords

Palabras clave 1. 2. 3. 4. 5.

API Persistencia de datos Colecciones nativas Cliente-Servidor Modularidad

1. 2. 3. 4. 5.

API Data persistence Native Collections Client-Server Modularity


Universidad de San Carlos de Guatemala Escuela de Ingeniería en Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026

Introducción

2. JSON

El presente proyecto aborda el diseño e implementación de un simulador para la autorización y auditoría de documentos electrónicos bajo la supervisión de la SAT.

JSON (JavaScript Object Notation) es un formato de datos basado en texto que sigue la sintaxis de objetos de JavaScript. Esto lo hace de manera sencilla y que es fácil de procesar para una computadora y legible para una persona. Se suele utilizar para comunicar aplicaciones cliente-servidor y en servicios web y APIs. (MDN. 2026)

Esto, mediante la adopción Programación Orientada a Objetos (POO) en lenguaje C# y una arquitectura cliente-servidor desacoplada (Frontend en Razor Pages y Backend en ASP.NET Core Web API), se aborda una solución modular capaz de validar identificadores, emitir códigos de autorización diarios, generar resúmenes estadísticos y persistir información de forma transparente en archivos estructurados. 1. Arquitectura Cliente – Servidor Es un modelo de programación y diseño de sistemas distribuidos en el que un cliente solicita un servicio y un servidor lo procesa y devuelve una respuesta, generalmente a través de una red. (IBM, 2026)

Este formato puede ser usado en distintos lenguajes, por ejemplo, en este proyecto se usó C# en su mayoría, por lo que se pudo convivir mediante librerías para manejar la sintaxis de JSON. 3. API Una API (Application Programming Interface) es un conjunto de reglas, métodos y definiciones que permite que dos aplicaciones o componentes de software se comuniquen entre sí e intercambien datos o funcionalidades. (Goodwin, 2026) Una API solo muestra las funciones o datos necesarios para una tarea, no muestra detalles que puedan ser sensibles.

En este modelo, el cliente es quien inicia la comunicación, mientras que el servidor ofrece Servicios como datos, archivos, acceso a base datos, entre otros.

La relación entre la API y la arquitectura clienteservidor usada en ese proyecto se describe así:

Este tipo de arquitectura se suele dividir en: Cliente, Servidor, Red y Protocolo.

• •

Para el desarrollo de este proyecto se usa el modelo Cliente-Servidor Desacoplado. Puesto que se dividieron en Backend y Frontend, el Backend no le concierne quien y que hace el backend, puede ser consumido por la aplicación Razor Pages o por clientes de prueba como Postman.

• •

El cliente envía una solicitud a un Endpoint La API lo recibe y valida, reenvía la solicitud al servicio correspondiente El servicio procesa la petición, consulta los datos y devuelve una respuesta, si fuera necesario El Cliente recibe y usa la respuesta, usualmente en JSON


Universidad de San Carlos de Guatemala Escuela de Ingeniería en Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026

recursos como páginas HTML, imágenes, videos, archivos y datos de APIs. (IBM, 2021) Este protocolo, en el modelo cliente-servidor, funciona cuando el cliente envía una petición, el servidor procesa y devuelve una respuesta. Esto se hace, aunque fue creado para transferir documentos de hipertexto, para comunicar aplicaciones, consumir APIs y enviar formularios. 5.1 Códigos de estado HTTP

Figura 1. Diagrama de flujo de una API Fuente: elaboración propia

Cada respuesta incluye un código de estado que indica el resultado de la solicitud del cliente: Códigos de solicitudes HTTP

4. ENDPOINT También como punto de conexión, es la URL que se específica para que una aplicación cliente pueda acceder a un recurso o realizar una operación a través de una API. (Google Cloud, 2026) En una API, el Endpoint está formado por una URL y un método HTTP, la URL identifica donde se encuentra y a quien pedirle el recurso y el método indica la acción que se desea realizar. Separar y etiquetar correctamente los Endpoints asegura que el proyecto sea ordenado y que no exista confusión entre distintos servicios.

Código

Significado

200 OK

La solicitud se procesó correctamente.

201 Created

Se creó un nuevo recurso correctamente.

400 Bad Request

La solicitud tiene un error de formato o parámetros inválidos.

401 Unauthorized

Falta autenticación o las credenciales no son válidas.

403 Forbidden

El servidor entiende la solicitud, pero no autoriza el acceso.

404 Not Found

El recurso solicitado no existe.

500 Internal Server Error

Ocurrió un error interno en el servidor.

Tabla1 Fuente: Elaboración propia

5. HTTP 6. Servicios Por sus siglas en inglés, HyperText Transfer Protocol, es un protocolo de la capa de aplicación que define como se comunican los clientes y los servidores en la Web. Permite solicitar y transferir

Son componentes de software que realizan una función en específico, pueden ser usados por otras aplicaciones a través de una interfaz definida, generalmente, una red. Cuando un servicio se


Universidad de San Carlos de Guatemala Escuela de Ingeniería en Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026

expone y consume mediante tecnologías web, se denomina servicio web. (IBM, 2026) Un servicio debe realizar una tarea en específico, ya sea buscar productos, consultar datos u otro. No deben de “mezclarse” servicios, puesto que podría ocasionar, en el mejor caso, confusión sobre donde se encuentra. El flujo es el siguiente: 1. Una aplicación manda una solicitud al servicio 2. La solicitud llega a un endpoint 3. El servicio procesa la petición 4. El servicio devuelve una respuesta con un resultado 7. Postman Es una plataforma de desarrollo y pruebas de APIs que permite crear, enviar, organizar, documentar y automatizar solicitudes HTTP hacia endpoints de servicios web. Es muy utilizada para probar APIs antes o durante el desarrollo de una aplicación. (IBM. 2026) Es decir, actúa como un cliente HTTP sin necesidad de tener una interfaz web construida (Frontend), se puede usar desde su extensión en IDEs (VS Code) o su versión de escritorio. Durante la realización de este proyecto, se usó postman como cliente para poder verificar el correcto funcionamiento del Backend, esto, antes de crear el Frontend. 8. DTO Por sus siglas en inglés, Data Transfer Object, es un objeto simple cuyo único propósito es el de transportar datos entre capas de una aplicación o

entre un cliente y un servidor, por ejemplo, a través de una API. No contiene lógica de negocio, solo define propiedades que se enviarán o recibirán. (Rick-Anderson, 2026). Como caso de ejemplo, en el desarrollo de este proyecto se usaron DTO’s para armar respuestas hacia Postman y el Frontend. Clases como RespuestasRtu solo contienen datos que son esenciales para que sean mostrados, como CONTRIBUYENTES_NUEVOS, CONTRIBUYENTES_ACTUALIZADOS y NITS_VALIDOS. Clases como Contribuyente contienen datos completos. Los DTOs, no, sino que contienen parte de estos objetos. 9. Persistencia de datos Esto hace referencia a la capacidad de una aplicación para guardar archivos, aunque el programa termine, se reinicie o, por alguna otra razón, el programa cierre. Esto se logra almacenando datos dentro de un disco no volátil. Durante ese proyecto, se usa la siguiente secuencia para guardar datos, sin necesidad de usar una DB: 1. El constructor GestorFacturación revisa si exista la carpeta ArchivosDatos y los archivos JSON. 2. Una vez comprobado, ArchivoServicios se encarga de leer el texto y ConversorJson lo desserializa como objeto a memoria de las listas correspondientes. 3. Todas las búsquedas se hacen sobre las listas, por lo que facilita el tiempo de búsqueda. 4. Al agregar datos, serializa automáticamente la lista completa y sobrescribe el archivo en disco.


Universidad de San Carlos de Guatemala Escuela de Ingeniería en Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026

10. Colecciones nativas

Conclusiones

En C#, las colecciones nativas son clases de .NET que permiten agrupar, almacenar y manipular varios elementos de forma dinámica. Las más utilizadas son List<T> para secuencias ordenadas e indexadas, HashSet<T> para elementos únicos y Dictionary<TKey, TValue> para asociar claves con valores. (BillWagner, 2026)

1. Modularidad y separación: Se logró un desacoplamiento entre la interfaz de usuario (Frontend en Razor Pages) y el núcleo de procesamiento (Backend en ASP.NET Core Web API).

En este proyecto se usaron Colecciones Nativas Genéricas de C#. Algo destacable es que son gestionados por el Garbage Collector. Colecciones genéricas utilizadas List<T>

Lista Dinámica Genérica

Es equivalente a un arreglo dinámico en memoria List<Contribuyentes> List<Factura> List<ReporteAuditoriaFecha> List<DetalleAprobacion> Dictionary<Tkey, Tvalue>

Se usó debido a que no se requiere definir un tamaño fijo, a diferencia de las listas tradicionales

Tabla Hash, Diccionario de Mapeo

2. Eficiencia en gestión de datos: El uso de colecciones nativas de C#, listas, diccionarios y tablas hash, optimizó y simplificó el trabajo en memoria, recurriendo a recursos nativos de C#. Contribuyendo así a una parte necesaria del proyecto, como lo es el manejo de datos en JSON. 3. Conectividad entre recursos y servicios: Para el intercambio de información, usando APIs, funcionan al unísono mediante los endpoints y HTTP, mediante el cual se accede a los datos por medio de los servicios y las repuestas se dan en JSON. Cada parte tiene su lugar y cada uno cumple con su funcionalidad.

Estructura de datos asociativa basada en una tabla hash interna Dictionary<string, List<Factura>> Dictionary<string, decimal>

Se usó para evitar recorrer toda la lista de facturas, en el diccionario, comprueba si existe en tiempo de O(1)

Dictionary<string, decimal> HashSet<T>

Conjunto de Elementos Únicos

Basada en tablas de dispersión (hash) que solo almacena elementos sin duplicados. HashSet<string> Se usó para agregar varios datos en emisoresPorFecha "una sola pasada", además, la propiedad de .Count devuelve el número exacto de contribuyentes

Tabla2: Fuente: elaboración propia

4. Persistencia de datos: Las colecciones, además de gestionar datos, trabajan en conjunto con los servicios para que sea posible resguardar la información para evitar que se pierdan al cerrar el programa, guardando un archivo JSON, dependiendo de que dato sea, para poder acceder a estos luego de cerrar y abrir el programa.


Universidad de San Carlos de Guatemala Escuela de Ingeniería en Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026

Referencias bibliográficas Db2 12 - Introduction - Architectural characteristics of web-based applications | Db2 for z/OS 12.0.0. (2026, Febrero 3). https://www.ibm.com/docs/es/db2-forzos/12.0.0?topic=environmentarchitectural-characteristics-web-basedapplications Trabajar con JSON - Aprende desarrollo web | MDN. (2026, Octubre 12). https://developer.mozilla.org/es/docs/Learn _web_development/Core/Scripting/JSON Goodwin, M. (2026, Octubre 1). ¿Qué es una API (interfaz de programación de aplicaciones)? IBM. https://www.ibm.com/es-es/think/topics/api Desarrollo de APIs: una guía completa. (2026). Google Cloud. https://cloud.google.com/discover/what-isapi-development?hl=es post an http message | IBM Business Process Manager 8.6.0. (2021, Marzo 4). https://www.ibm.com/docs/es/bpm/8.6.0?to pic=http-binding-overview Integrating with Postman | IBM API Connect Cloud Service 12.1.1 (SaaS). (2026, Mayo 13). https://www.ibm.com/docs/es/apiconnect/cloud/12.1.1_saas?topic=catalogsintegrating-postman Rick-Anderson. (2026, Marzo 27). Crear objetos de transferencia de datos (DTO). Microsoft Learn. https://learn.microsoft.com/eses/aspnet/web-api/overview/data/usingweb-api-with-entity-framework/part-5 BillWagner. (2026, Enero 22). Colecciones - C# reference. Microsoft Learn. https://learn.microsoft.com/es-

es/dotnet/csharp/language-reference/builtintypes/collections Anexos

Figura 2. Diagrama de clases Fuente: elaboración propia


Turn static files into dynamic content formats.

Create a flipbook
Proyecto3_Documentación by Anderson - Issuu