Objetivo del documento
El objetivo de este documento es definir las características operativas de una dependencia y la casa central para que puedan trabajar con el software de Gestión de EEESS.
Siendo hoy que la mayoría de las dependencias tienen una versión del software ACA 2000, lo que aquí se plantea es la MIGRACION hacia el nuevo modelo.
Esta migración se expresa en las consideraciones de topología, arquitectura, comunicación, hardware, base de datos, transferencia mediante archivos y contingencias para operar con el nuevo software

Alcance:
Este documento aplica al Proyecto del SGEESS y define a los efectos de operar con el Sistema de Gestión de EESS, las características de:

A) La topología lógica y física de toda la red de nodos
B) La operatoria de trabajo (Generación, Transferencia y Captura)
C) La topología lógica y física de una EESS.
D) El modo lógico de vinculación entre el nodo central y los nodos de las dependencias.
E) La elección de SQL Server Express 2008 como “piso” de las instalaciones
F) Las características y cantidad de las bases de datos en las dependencias
G) Las estrategias de respaldo y recupero de la información.(Backup y Restore)
H) La operación en modos de contingencia.


Referencias:
Documentos de discusión de arquitectura catalogados para el proyecto como “Serie de discusiones técnicas sobre la arquitectura”:

Especificación de Arquitectura: ACA-Especificación Arquitectura SGEESS v1-0

Objetivos del negocio, Contexto, Hipótesis y Supuestos
El Automóvil Club Argentino (al que llamaremos con el acrónimo que se conoce en el mercado A.C.A.), cuenta con una línea de negocios que es la venta minorista (retail) en estaciones de servicio. Estas estaciones de servicio provén combustibles y lubricantes de la línea YPF, ofrecen productos de utilidad para el viajante, repuestos para el automotor,servicios al socio y servicios adicionales como lavado, engrase, mecánica menor, gomería y estacionamiento.-
La atención de este modelo de negocios se basa en dos modalidades: explotación directa o por concesión. Es decir existe un área física donde el negocio se produce y a la que llamaremos ESTACION DE SERVICIO o DEPENDENCIA.
En la DEPENDENCIA se prestan los SERVICIOS de:
Venta de combustibles y lubricantes de la línea YPF
Venta de productos comprados por el ACA a terceros y comercializados en forma minorista
Servicios de mini-mercado, desayuno y comidas rápidas
Servicios adicionales como gomería, lavado, engrase, estacionamiento, etc.
Estos SERVICIOS, desde el punto de vista del negocio del A.C.A. son la composición de prestaciones que brindan uno o más CONCESIONARIOS del SERVICIO en la DEPENDENCIA o el ACA en forma directa.
Los CONCESIONARIOS o el ACA en forma directa operan el negocio en la DEPENDENCIA en todas o algunas de estas modalidades según se detalla:

Vendiendo los productos que entrega el ACA (PRODUCTOS CONSIGNADOS o CONSIGNADOS sencillamente) (Ambos)
Vendiendo el combustible y lubricante para automotores, que provee YPF en acuerdo con el ACA (Ambos)
Prestan los SERVICIOS ADICIONALES al automotor (gomería, engrase,…) (Ambos)
Venden los productos no consignados por el ACA (PRODUCTOS PROPIOS o PROPIOS sencillamente) (concesionario)
Prestan SERVICIOS ADICIONALES al viajante como mini mercado y comida rápida con productos PROPIOS o CONSIGNADOS (Ambos)
Servicios varios de cobranzas y pagos (ACA)

En esta operación del negocio existen entonces las siguientes figuras:

EL A.C.A. (representado por un JEFE de DEPENDENCIA y su equipo) son los administradores de la dependencia y quienes controlan la operación y los intereses del A.C.A. en el negocio.

El CONCESIONARIO, que actúa en la dependencia prestando un SERVICIO. Observar que habiendo varios servicios en la dependencia, existirá la posibilidad de que exista mas de un concesionario en la misma

YPF. Que es el proveedor de combustibles y lubricantes y de la tecnología de administración e interfaz de los aforadores y tanques

EL CLIENTE que es cualquier persona física que consume productos, servicios, combustibles o lubricantes.

El PLAYERO que es quien despacha en las islas de carga de combustible despachando productos, servicios, combustibles o lubricantes y emite facturas por los servicios que se prestan y los productos que se venden.

El CAJERO que es quien despacha en el local/mini-shopping/minimercado y emite facturas por los servicios que se prestan y los productos que se venden tanto en el local como opcionalmente en la playa.

El CAJERO ACA que es quien despacha en el local y realiza cobranzas por los servicios que se prestan al socio y los productos que se venden en el local y pagos a proveedores del ACA

Topología lógica de la red de EESS: El modelo de trabajo
La operatoria de EESS independientes y una casa central participando de la red, nos lleva a un modelo en el que pensamos que todos ellos conforman una UNICA RED con una comunicación ASINCRONA, simulando el modelo conocido como Store & Forward. Donde el Forward se hará en el intervalo mas corto de tiempo técnicamente posible, existiendo asimismo un grupo de operaciones que necesitan un diálogo on line (ejemplo 5%)

En este modelo, cada nodo de la red opera independientemente. La sincronización de información entre los mismo se produce según el siguiente modelo:
A) El envío de información propia de cada EESS al nodo concentrador de la red (ubicado en el nodo central) al que llamado genéricamente Casa Central
B) Recibiendo de éste las novedades centralizadas (aquellas que se generan en el nodo central) y las novedades de otras Estaciones de Servicio que deban ser propagadas a otros nodos (algo que llamamos Propagación). Esto ítems a) y B) se hace mediante operaciones planificadas de recupero, compactación, envío y transacción de las novedades del origen al destino.
C) Consultando en línea datos de referencia de los SOCIOS en una operación ON-LINE pura implementada mediante Web Services
D) Entregando a través de mensajería de cola información de ventas de las EESS a la CC. Esta técnica de envío se realizara mediante WCF y servicios por tiempo que aseguren el menor tiempo posible de envío de la información a los receptores.

Este proceso de intercambio de información es una actividad de transferencia y servicios entre múltiple nodos de bases de datos NO REALIZADA por el motor de base de datos sino a través de lógica de la base, comandos Transact-SQL y scripts de comandos del sistema operativos.

EL gráfico nos da una idea de esta topología:


Digamos entonces que Store and forward es la técnica de envío de información a una estación intermedia de la red donde es almacenada para finalmente ser distribuida a su destino final (otro nodo de la red). En nuestro modelo esta estación intermedia es el NODO de INTERCAMBIO, que cuenta con tareas de distribución de la información que recibe y sistema de tracking (Tablero de Alarma) que realiza algunos chequeos simples de la generación y captura de la información entre los nodos.

Este no es un chequeo de integridad sino un control de que hayan sido realizados, tanto la serie de nodos que deben realizar transmisiones (generación) así como las capturas (transferencia y carga), en las etapas del día donde esto debía generarse.

Esta técnica se utiliza ya que la naturaleza de la conexión entre los nodos debe considerarse como intermitente y existe la posibilidad de demoras en la transmisión, además de errores en la misma.

Esta información compartida es variada y explica la lógica compartida del modelo. Veamos algunos casos a modo de ejemplo:

1. Clientes dados de alta en Casa Central que deben replicarse en las EESS.
2. Clientes de alta en una EESS que deben replicarse a Casa Central y propagarse a otras EESS.
3. Promociones de artículos dados de alta en Casa Central que deben replicarse en las EESS.
4. Políticas de precios y modificaciones de precios de artículos dados de alta en Casa Central (en adelante CC) que deben replicarse en las EESS.
5. Ventas de combustibles, lubricantes y productos producidas en la operatoria de la EESS que deben enviarse a CC para su registro contable, estadístico, de inteligencia de negocios, de fidelización, etc.

Operatoria de trabajo
Para la transferencia de la información se utilizan procesos planificados corriendo como servicios del sistema operativo que disparan procesos escritos en el lenguaje de comandos del servidor de base de datos SQL Server: Transact SQL

La operatoria de trabajo se divide en:

Operación de Transferencia de archivos: GENERACION
Operación de Réplica de archivos: TRANSFERENCIA
Operación de Réplica de archivos: CAPTURA
Operación de Replica de archivos: ALARMAS y CONTROL DE ESTADOS
Operación On Line: CONSULTA A CASA CENTRAL
Operación ASAP: ENVIO A CASA CENTRAL

Operación de Transferencia de archivos: Generación
Estos procesos planificados disparan a determinadas horas del día y consultan sobre novedades que se han producido en las tablas que forman parte del modelo de transferencias.
De este modo este proceso genera las novedades que se emiten como datos planos de registros de las tablas en cuestión.
La información de los registros, con novedades de cada tabla, se compacta en formatos ZIP, guardándose con esa información, datos de redundancia cíclica a los efectos de la integridad de lo enviado. En el caso que la información generada tuviese algún tipo de inconveniente las acciones de alarma y la revisión con el tablero de control podrán efectuar acciones de recupero. Ver apartado Operación de Transferencia de archivos: MONITOREO, ALARMAS y CONTROL DE ESTADOS


Se prepara además información propia de las tablas que han generado información y del orden de carga de la misma en el nodo de destino de modo de asegurar la integridad referencial entre las tablas.

La operación tiene detalles técnicos que se expresarán en documentos específicos como “ACA _ Cómo funciona la réplica ?.doc” que serán entregados con la iteración correspondiente.



Operación de réplica de archivos: Transferencia

La transferencia de archivos es una operación que se realiza entre los nodos de las dependencias y la casa central. Esta operación es iniciada a través de un proceso en casa central que trabaja en una doble dirección:

1) Revisa las generaciones de cada nodo (dependencia) y las lleva al nodo concentrador.
2) Toma las generaciones realizadas en el nodo concentrador y las distribuye a cada dependencia objetivo.

Estos procesos utilizaran el vínculo de comunicación disponible (V_SAT de 64K en el peor escenario) para transportar los archivos generados durante la operación de generación.

La técnica de transmisión se terminará de definir en una etapa posterior a la de la primera versión de este documento. Pero las alternativas previstas para la transferencia de archivos son las siguientes, todas implementables a través de desarrollos de M3:

A través de web services. Esta técnica tiene la ventaja de ser un protocolo que asegura el delivery de lo que se transporta. Si el único “publicador” fuese CC entonces un único IIS en CC podría atender los pedidos de envío de archivos de cada EESS. En las EESS correría un software escrito en C# sobre Microsoft Framework 3.5 y estos consumirían el Web Service publicado en CC para el delivery de archivos. Pero siendo también las EESS “publicadoras” de información este esquema centralizado requeriría de un IIS en cada EESS.
La opción queda abierta en tanto se modifique el concepto de operatoria de transferencia centralizada y se asuma que el envío de cada EESS es una maniobra INDEPENDIENTE.


A) A través de WCF (Windows Communication Foundation). Esta técnica es la que tiene menos requerimientos de servicios instalados (sólo el Framework .NET 3.5 de Microsoft) y requeriría de desarrollos de M3 para los servicios de cliente y servidor de este esquema de comunicación y transferencia.

Al momento de escribir esta versión del documento no se ha definido cual es la opción elegida.

Sea como fuera la capa de transferencia, el sistema prevé que los archivos generados serán transferidos entre nodos de la red con un sistema de marcas que indicarán:

• Nodo generador y nro de envío
• Registro de transferencia exitosa (un sistema de alarmas se encargar de reportar las fallidas)
• Registro de reintentos



Operación de Transferencia de archivos: Carga

La carga es el último de esta triada de procesos que componen la parte central de la réplica mediante archivos.

Una vez recibidos los archivos a través del proceso de transferencia, estos con capturados por procesos planificados que descompactan la información recibida y leen el archivo de meta data que informa de qué modo se ha generado la información en el origen y la transacción contra cada tabla comprometida, en el orden que la integridad referencial lo requiera.

El modo en el que la carga trabaja, hace que si llegase información redundante (es decir registros enviados anteriormente) el sistema no entre en error. De hecho lo primero que se intenta hacer es una actualización (UPDATE) buscando la identificación única de cada registro. En caso que esto no pueda ser realizado, una ronda siguiente intentará el INSERT.
Existiendo en el modelo tablas sobre las que se debe establecer auditoria, conservar su historia o ambas, se asegurara que la técnica genérica enunciada no entre en conflicto con esta regla de negocio.

Si hubiese registros que no pudiesen transaccionarse, el proceso logueará el error y dejará la información para que se pueda re-intentar la carga una vez corregido el error.




Operación de Transferencia de archivos: MONITOREO, ALARMAS y CONTROL DE ESTADOS

Todas las operaciones de generación, transferencia y carga dejan una traza que luego es capturada por un proceso monitor que registra estas actividades.

Las actividades son planificadas, de modo que el proceso sabe qué debe ocurrir con cualquiera de las operaciones y con qué frecuencia para el día que está analizando.

Hay motivos variados por los cuales los envíos pueden fallar. Algunos de ellos pueden ser:

No pudo ser enviado por caída del vínculo
Pudo ser enviada pero presenta inconsistencias de tipo físico (CRC fallido por ejemplo)
Pudo ser enviada, pudo ser descompactada y falla en el momento de transaccionar

Para todos esos casos un servicio de alarmas estará controlando el éxito de las operaciones.
Un servicio colector de estados registrará el log de cada operación en el tablero de control
En caso que así lo tenga configurado, la alarma alertara a un administrador
La alarma podrá, también en caso de configurarse solicitar al emisor de la información una retransmisión. Esta operación, la alarma la reintentara un número acordado de veces.
Algunas de las actividades de transferencia, además de planificadas, tendrán el atributo de envío critico Por ejemplo los cambios de precios,

En este caso lo que el sistema debe hacer es realizar el envío (transferencia) POR DEMANDA (es decir no será algo que este planificado) sino un pedido especifico.

Y considerara que el mismo es exitoso cuando se asegure el resultado del delivery
De todos modos este y otros casos pueden requerir de reglas de negocios particulares que exceden el marco de esta discusión de tecnología.
Lo importante es marcar que los componentes pensados pueden conducir las reglas de negocio que el sistema necesite en su implementación.

Además de detectar los errores, el proceso deja registro de los estados de operación de modo que una aplicación permita a los administradores ver y revisar los estados.
Existirá una aplicación de consulta que permitirá revisar los estados de operación por DEPENDENCIA.

Existirá asimismo la posibilidad de que la información sea vista por el emisor directo (como por ejemplo un responsable comercial en el caso de los cambios de precios). Nuevamente esta u otras menciones a aspectos específicos de negocio exceden el objetivo de este documento.


El objetivo general de la aplicación de monitoreo es revisar la conexión y los estados de generación, envío bidireccional y captura generando alarmas en caso de fallas.



La topología lógica de una EESS (Dependencia)

El gráfico muestra una distribución lógica de los puntos dentro de una EESS.

En el grafico se observa que todos forman parte de una red de área local y existen en la estación de servicio dos Servidores de Base de datos.

Esto no es aplicable a todos los modelos de estaciones de servicio en tanto existe un modelo de topología de la dependencia distinto según la categoría de la EESS.

Digamos que en general habrá dos modelos:


MODELO A: Dos servidores de bases de datos y utilización de mirroring y log shipping (BASES DE DATOS EN SISTEMAS DE DISCO INDEPENDIENTES)

MODELO B: Un servidor de base de datos.


Los modelos A, con dos servidores, tendrán versiones Estándar de SQL Server 2008 en las que se contara con estrategias de failover basadas en operaciones de mirroring y log shipping implementadas a través de funcionalidades del motor de SQL Server

Los modelos B, con un servidor, tendrán versión SQL Server 2008 Express y se construirán scripts en Transact SQL y servicios en C# para que determinadas acciones programadas realicen operación de backup incremental de las bases para casos de caída de la misma.

Todos los servidores de estas estaciones de servicio serán servidores de base de datos, de file system y de aplicaciones (contendrán esencialmente un servidor de aplicaciones IIS: Internet Information Server)
Tendrán discos en montaje RAID y en los mismos se colocaran adecuadamente distribuidos en particiones los archivos de datos y de log de la base de datos.


La operación de la dependencia responderá a un modelo CLIENTE SERVIDOR.

Esto implica que cada puesto de la red que participe del sistema deberá tener instalado el software cliente de la aplicación.

SI bien esto puede significar una carga extra en el momento del deploy de una nueva versión, es el modo de garantizar que cada puesto de venta opere independientemente en caso de caídas de los servidores.

Significa también el modo más simple de escalar ya que los requerimientos de hardware de un puesto de trabajo para ventas u operaciones generales no exceden los de un equipo desktop actual.





Dentro de cada dependencia habrá un SERVIDOR de base de datos. Este servidor deberá ser conforme se indica en la siguiente tabla para los casos de tener instalado una versión SQL Server 2008 express.

El servidor de base de datos primario de la dependencia

Hardware para el servidor SQL Server dedicado

Recurso Valor Recomendado Notas
RAM 2 GB (DDR2 533/667/800 MHz)
CPU Core 2 DUO 3.0 Ghz (1 Procs)
Disk Space
El sistema operativo y los binarios de SQL Server residirán en los discos internos de estos servidores. Es recomendable que la partición del sistema operativo tenga al menos 30 GB.
Con referencia a los datos es difícil calcular el crecimiento de la instalación, esto se hará durante el planeamiento pero consideremos un espacio de 100GB para prever futuro crecimiento.

Network 1 x 1Gb network interface cards
Operation System Windows Server 2008 STD
Software (según tipo
De EESS) Microsoft SQL Server 2008 express o Microsoft SQL Server 2008 Estandard

Los puntos de venta (POS)
Requerimientos de HW y SW de los POS




El modo lógico de vinculación entre el nodo central y los nodos de las dependencias

¿Por qué podemos decir que los nodos de las dependencias y el nodo de Casa Central mantienen una operación vinculada y unificada, siendo que trabajan independientes y desconectados la mayor parte del día y la operación?

La unidad de estos nodos está en el modelo y en el concepto de STORE & FORWARD:

A) el modelo de datos, es único para todos los nodos de la red.
B) el modelo de datos se alimenta a través de operaciones de ABM que se hacen en cada nodo y los datos que llegan A TRAVES DE LA REPLICA MEDIANTE archivos.

Aun cuando existe una operatoria prevista de consulta ON LINE (sólo para limitados datos de los socios del ACA), la réplica mediante archivos permite que, en caso que esta operación ON LINE no sea posible (caída del vinculo, time-out, etc.), la consulta de esta información se realice contra la base de datos local.

La elección de SQL Server 2008 Express como “piso” de las instalaciones

La elección de SQL Server 2008 Express como modelo base del servidor, quita algunas de las funcionalidades de los administradores de base de datos y deben ser reemplazadas por comandos TRANSACT-SQL para llevar adelante dichas acciones.

De todos modos la prestación que este servidor de base de datos brinda al sistema cubre la operación deseada.

El diseño del sistema que hace Millennium3, ha considerado estos trade-offs en los que la guía principal ha sido preservar la economía del ACA de un modo integral.

El nulo costo de licenciamiento de las versiones de SQL Server 2008 Express hace que la aplicación de gestión pueda utilizarse en todas las categorías de Dependencias que el ACA posee.

Por otro lado la posibilidad que brinda SQL Server Express 2008 de utilizar todos los comandos de TRANSACT-SQL ha hecho que Millennium3 centre todas las estrategias de administración, backup y recupero en desarrollos ad-hoc basados en esta tecnología.

De todos modos habrá Dependencias que por su volumen de actividad y atención tendrán instaladas versiones superiores de SQL Server (Estándar). Para estos no se perderá ninguna funcionalidad del producto, en tanto todas las tareas de DBA que en las estaciones con SQL Server Express 2008 se realizan mediante scripts, en las estaciones con versiones más avanzadas se utilizaran las herramientas estándar del producto.

Asimismo en las Dependencias donde existan servidores SQL Server 2008 Estandar será posible desarrollar estrategias de mirroring y log shipping a los efectos de levantar los servidores de Fall-Back.

Siendo que la asignación de cuáles serán las Dependencias que utilizan SQL Server Express 2008 o SQL Server Estandar 2008 dependerá de una evaluación de costo de licenciamiento versus volumen de operación, esto tendrá una implicancia práctica directa:

La cantidad de POS (puntos de venta) que pueden operar con una instalación SQL Server Express 2008.

Al efecto, los Arquitectos, Ingenieros y Tecnólogos del ACA y de M3, realizarán pruebas de laboratorio en las que se simulará una carga de operación para verificar las respuestas de un servidor SQL Server Express 2008, LO QUE DETERMINARÁ EN LOS HECHOS, cual es la máxima cantidad de puestos de operación simultánea que puede tener una Dependencia.

Estrategias de respaldo y recupero de la información (backup y restore)
Las estrategias de backup y restore están pensadas para cumplir con los siguientes supuestos, algunos de los cuales son restricciones de diseño:

A) No existirán en todas las bases operativas de las EESS de la red del ACA versiones corporativas o estándar del producto SQL Server 2008. Lo que implica que no podrán realizarse en todas ellas tareas basadas en Mirroring o Log Shipping.

B) La mayoría de las bases de datos de las EESS de la red del ACA serán del tipo SQL server 2008 Express. Lo que implica que no existirá un Agent de operación y por lo tanto no existirá la posibilidad de JOBS planificados como actividad de la base.

C) En aquellos sitios (EESS) en los que se cuente con SQL Server Express las tareas de backup y restore serán realizadas por procesos planificados a nivel del sistema operativo, disparados dentro de servicios desarrollados por M3 que invocarán a través de la utilidad de comandos del SQL SERVER (sqlcmd) a scripts escritos en Transact SQL que ejecutarán las tareas de backup . En aquellas instalaciones que admitan el uso de JOBS (es decir las que tengan versiones Estándar o Enterprise)esta tarea se verá simplificada al poder incluir estas actividades en el scheduler de JOBS de SQL Server

D) En las estaciones de servicios con la instalación de SQL Server 2008 Express, las tareas de backup serán realizadas de modo automatizado, requiriendo el restore la menor intervención manual posible que indiquen las buenas prácticas

E) Por definición del ACA en aquellos sitios (EESS) en los que se cuente con SQL Server Express no existirá un servidor secundario de base de datos. Por lo que la tarea de recupero en caso de caída de dicho servidor implicara una actividad de restore planificada.
Estados de operación
Estas actividades cubren lo necesario para estos estados de operación:

• Normal
• Entrada a Contingencia Stand alone
• Operación en contingencia Stand alone Recuperación

La operación del sistema dentro de una dependencia puede pasar por diferentes estados. El estado básico esperable es la Operatoria normal. Frente a una falla pasará a estado contingencia. En ese estado consultará para pasar al esquema de contingencia. En ese estado opera mientras se producen todas las acciones necesarias para la recuperación. Finalmente se vuelve a la operatoria normal.

Ante una contingencia que afecta la operatoria normal es necesario tomar una acción que nos permita seguir operando bajo el esquema de contingencia previsto.
Esta acción será automática por defecto con una previa autorización para pasar de estado

En cuanto se comienza a operar dentro de un esquema de contingencia, hay que comenzar a revisar el plan para la recuperación de la operatoria normal.

A diferencia del estado anterior, esta acción debe ser planificada en tanto los motivos de falla superan el dominio de acción del software de aplicación

Operación en modo reducido (PSAO)
La operación en modo reducido es un modelo de contingencia en el que se supone que los nodos han dejado de estar conectados entre sí por una caída del hardware que vincula a la red o por una falla en el Domain Controller.

La operación en modo reducido o PSAO (Point Of Sale in Stand Alone Operation) es un modo de contingencia en el que el Punto de Venta (POS) del sistema puede operar facturando sus despachos aun cuando el servidor primario y el secundario no estén accesibles.

La operación PSAO permite la captura de información y la consulta ON LINE a Casa central sobre la base de los siguientes supuestos que dependen de la infraestructura y la topología de conexiones de la DEPENDENCIA:


A) Que el Punto de venta que desea operar como PSAO tenga una conexión directa al servicio de Casa Central que retorna novedades sobre los socios.

B) Que el POS tiene conexión con el CF y sería deseable que mantenga conexión con el POSI

Limitaciones operativas en modo PSAO para la operatoria diaria

Por otro lado, la operación en Modo PSAO está fuertemente enfocada a la venta y emisión de tickets del punto de venta.

De allí que luego de emitido el ticket, el sistema guardará el registro de la operación de venta para que luego, al recuperarse la operación normal, estas transacciones sean integradas.

Esto significa que las actividades posteriores a estas tareas, que el sistema en operación normal realiza, NO SERÁN EFECTUADAS hasta que no se reponga la operación normal.

Una enumeración de las mismas:

• Descuento de las cantidades vendidas del stock
• Registro de venta para los cierres de playero
• Registro de venta para cierres diarios
• Carga de consumos actualizados de socios(solo en caso de no tener enlace con CC)
• Actualización de cuentas corrientes

Cuando la operación normal se reponga, será necesario mover la información de cada puesto de venta al servidor central de la EESS y allí ejecutar un procedimiento al efecto que comenzará a consolidar como transacciones las operaciones de venta realizadas durante el modo contingencia PSAO.

Costos operativos del modo PSAO para la venta

Referido a la operación de venta en modo PSAO se debe tener presente que deberá existir información en la base de datos para poder operar con elementos deseados y con elementos críticos.

Para enumerar los principales:

1. El tipo de documento que se puede emitir
2. Impuestos
3. Los códigos de productos y sus precios



Si no fuese posible contar con una base de datos, como surgió de las reuniones mantenidas al momento de escribir esta versión del documento, entonces algunas operaciones quedarán inhibidas y otras reducidas al extremo.





Sobre el deploy de la aplicación y cambios en la misma
La naturaleza del sistema previsto y cotizado es del tipo cliente servidor. Esto significa que hay un procesamiento distribuido entre actividades cliente (POS o puesto de administración) y servidor (servicio de base de datos).
Que el POS tenga la aplicación instalada, así como las bibliotecas de ejecución forma parte de su utilidad operativa.La distribución de la aplicación a todas las EESS esencialmente cuando la misma este operativa, y deban enviarse actualizaciones, presenta un desafío. No solamente deberá distribuirse a UN PUNTO de la EESS sino a cada puesto de venta y operación donde la aplicación este instalada.


Estrategias de deploy de cambios en la aplicación
El deploy de cambios de la aplicación puede realizarse a través de herramientas específicas de configuración (como SCCM), políticas del sistema operativo, lógica de la propia aplicación o combinaciones de las mismas.
Una vez distribuida la nueva versión de la aplicación en el servidor de cada EESS la llegada de la misma a cada puesto de la dependencia será realizada a través de herramientas de distribución o bien a través la copia a través de la WAN de todos los ejecutables, archivos de configuración y bibliotecas necesarias para la aplicación.

Estrategias de deploy de cambios en el modelo
La propia evolución del negocio requerirá no solo de cambios en la aplicación cuyo deploy fue comentado en el párrafo anterior, sino de cambios en el modelo.
La estrategia de cambios en el modelo excede las estrategias de cambios en la aplicación y difícilmente pueda pensarse que la misma se resolverá con distribución de software de infraestructura.
A los efectos la modificación del modelo de datos se debe prever que esta implementación de cambios no se hará como big-bang sino como una distribución incremental de dichos cambios.
La principal diferencia de los cambios en el modelo y en la aplicación están centrados en que el modelo debe considerar el esquema de REPLICA de archivos.
Es decir en el momento que los cambios se hagan incrementalmente en las EESS, el envío de la información de las mismas a la CC y desde la CC a las EESS deberá prever que existirá diferencia en el modelo entre las EESS que tienen el modelo “antiguo” (previo a los cambios en el modelo) y el “nuevo” (que ya contiene dichos cambios).
Esto será considerado como parte de la arquitectura del sistema para la réplica de archivos.

Last edited Jan 6, 2012 at 12:45 PM by eduardob, version 2

Comments

No comments yet.