Apéndice de convenios

Lista de regla

sfConvenioAdmBase.class.php

Una acción del usuario que está sujeta a políticas que se gestionan sobre el motor de convenios de suap pasa por las siguientes instancias.

• 1. Click
• 2. si es sfProcesadorOrdenManager
  • 1. sfprocesadorOrdenManager → sfComportamientoManager
    • 1. sfComportamientoManager → intenta con suapComportamientoManager
      • 1. suapComportamientoManager intenta con datos extra, sino puede devuelve null
    • 2. si no resulta suapComportamientoManager, sigue la política mediante yml
  • 2. el sfProcesadorManager devuelve un suapProcesadorOrden[COMPORTAMIENTO] o un sfProcesadorOrden[COMPORTAMIENTO]. En este orden estricto, intenta siempre lo nuevo, sino puede sigue con lo viejo.
• 3. si es sfConectorManager
  • 1. sfConectorManager → sfComportamientoManager
    • 1. sfComportamientoManager → intenta con suapComportamientoManager
      • 1. suapComportamientoManager intenta con datos extra, sino puede devuelve null
    • 2. si no resulta suapComportamientoManager, sigue la política mediante yml
  • 2. el sfConectorManager devuelve un suapConvenioInterfaz[COMPORTAMIENTO] o un sfConectorExterno[COMPORTAMIENTO]. En este orden estricto, intenta siempre lo nuevo, sino puede sigue con lo viejo.

Aquí vemos que hay dos grandes grupos de acciones que gestiona el convenio. Por un lado tenemos las clases sfProcesadorOrden[COMPORTAMIENTO] y la suapProcesadorOrden[COMPORTAMIENTO] que son las que aplican el convenio según los diferentes requerimientos del usuario, pero en una orden ya creada en suap. Es deseable que la tecnología que se utilice sea suapProcesadorOrden[COMPORTAMIENTO].

Por otro lado está sfConectorExterno[COMPORTAMIENTO] y suapConvenioInterfaz[COMPORTAMIENTO]. La idea original era que sfConectorExterno[COMPORTAMIENTO] fuera solamente utilizada por el sfProcesadorOrden[COMPORTAMIENTO] para realizar la interfaz entre suap y el convenio. Pero a la hora de definir el afiliado se optó, hace tiempo, por tomar acciones desde la api del smartForm directamente sobre el conector. Y es necesario que dicho conector tenga dos metodos, que son: testearAfiliado() y arbrirConexión(). Para sostener esta situación y hacer una transición ordenada se optó por crear una suapConvenioInterfaz[COMPORTAMIENTO] que es eso, una interfaz entre suap y el convenio. Esta clase nueva tiene los métodos testearAfiliado() y abrirConexión() para que sea compatible con la api del smartForm, pero no las resuelve directamente mediante el conector, lo hace mediante el convenio.

Veamos los detalles en cada caso.

En el caso de

A diferencia de sfConectorEsterno[CONVENIO] está totalmente desacoplada del modelo de suap y de la interacción de soportes de almacenamiento. Por ejemplo, los parámetros de la conexión se pasan como parámetros y no son tomados de la DB o de archivos de configuración (yml). Por otra parte está mucho mas acoplada a las funcionalidades del convenio en si.

Estas clases extienden la suapConectorExternoBase. Esta clase abstracta impone algunos metodos mínimos del tratamiento de errores y un método public abstracto que se invoca en el constructor. Este método setup()es el que realiza algunas configuraciones previas del conector real que se va a implementar.

También tiene los setters y getters de parametros del conector, afiliado externo a consultar, afiliado externo obtenido, orden externa a consultar, etc. Es decir, la vinculación del conector con el financiador no será mediante entidades del modelo de suap, solo serán mediante unas clases externas totalmente abstraidas y desvinculadas del modelo de suap.

Es una clase con setters y getters de datos de una orden. Es muy parecida a la orden de suap, pero por ejemplo tiene separado el efector del prestador. Es decir, por un lado tiene un efector con los datos del profesional en salud que realiza la practica y por otro lado tiene un prestador con los datos de la persona (fisica o jurídica) que va a facturar la prestación.

Es una clase con setters y getters de datos de afiliados. No es parte del modelo, es una clase adaptadora entre datos del mundo exterior y lo interno de suap. Por ejemplo

Es una colección de suapPracticaExterna. Tiene implementadas las interface arrayAccess, iterable y countable. Pero con la particularidad de que se pueden incorporar suapPracticaExterna como en cualquier arreglo y luego iterar o acceder mediante codigos del financiador, o de suap o por cantidad etc. Por ejemplo

Dentro de una ráfaga de ejecución de un convenio existen una serie de variables que se pueden inyectar de forma previa a la ejecución, otras que se van creando en forma interna para “comunicarle” cosas a las reglas posteriores y finalmente aquellas que nos devuelven información de la ejecución luego de que finalice el llamado de convenio ($convenio→apply())

Las variables se pueden inyectar antes del punto de ejecución con:

$convenio = sfConvenioAdmBase::create (…);
$convenio→entorno→setToVariables(‘idUser’, $idUser );
/ / Mas variables
$convenio→fetchConvenio ()
→createRulesBlocksSetByMatchBlocks ()
→hydrateRulesSet();
…
$convenio→apply();

Es muy importante que se entienda que las variables deben inyectarse ANTES del fetchConvenio(). Esto es porque el createRulesBlocksSetByMatchBlocks puede utilizar esas variables como parte de condición de match. Si se hacen luego de esto y antes del apply van a estar para la ejecución, pero no van a estar para la selección de bloques de ejecución. Tener esto en consideración. Se recomienda siempre antes del fetchConvenio.

Las variables se pueden obtener desde el punto de llamado con:

$convenio = sfConvenioAdmBase::create(…);
…
$convenio→apply();
$error = $convenio→entorno→getFromVariables(‘lastError’);

En el ejemplo se puede ver que luego de una ejecución se obtiene el ultimo error. Que es una variable que se debió configurar en alguna regla. Las variables que se utilizan para inyectar contexto (previo a la ejecución), unir reglas (durante la ejecución) y devolver información (al finalizar la ejecución) son:

• · ‘idUser’: Es el id del usuario que está llevando a cabo la acción (sf_guard_user→getId())
• · ‘suapCfg_entorno_tipo’: es el tipo de entorno, proviene del yml suapCfg.yml. Indica si está en producción o testing dicha instalación. Estaría bueno que deje de provenir del yml.

• · ‘afiliadoExterno’: es un objeto de clase suapAfiliadoExterno. Sirve para inyectar datos de un afiliado que se va a buscar en el WS de un financiador. Es el primer frente de unificación, tiene setters y getters de cada dato

• · ‘parametrosConector’: Contiene los datos necesarios para realizar la conexión con el WS del financiador. Es probable que exista sfRegla_[convenio]_setup que configura estos datos.
• · ‘afiliadoObtenido’: Es un suapAfiliadoExterno que contiene los datos que se obtuvieron desde el ws del financiador. Está en abstracto y no está en la DB de suap.
• · ‘ordenExterna’: es un objeto de clase suapOrdenExterna. Hay una serie de reglas que construyen a partir de una orden real de suap estos objetos. Sirven para vincular los conectores con las reglas, son una abstracción genérica de lo que es una orden. En general las reglas de tipo sfReglaOrdenExternaBuild_M# son las que tomando una orden del modelo crean una ordenExterna.
• · ‘transaccionExterna’: Es la transacció externa con el ws del financiador.

• · ‘lastError’: Es el último error registrado, es texto, suele ser utilizado en la interfaz con el usuario

• · ‘datosRender’: es una variable que se crea en el ámbito RENDER. Es donde se indican cosas que se exige mostrar de una entidad. Por ejemplo la parte variable según convenio de un show de orden.
• 'nombreConector' (opcional): es una variable que genera el convenio en cualquier ambito, opcional, que sobreescribe el conector que tradicionalmente se usa. Sigue la misma logica que los datos en el yml clasico. Ejemplo nombreConector=OSDELoco conector instanciado sfConectorExternoOSDELoco
• 'comportamiento' (opcional): permite forzar un comportamiento particular para, por ejemplo, acceder a una seccion especial del yml
• 'return': si esta definido y es 1 se termina el proceso al finalizar el ambito que la ejecuto. Sirve para que condiciones externas puedan impedir un proceso (por ejemplo actualizar)
• 'mensajeUsuario': en esta variable las reglas pueden inyectar mensajes al usuario. Se ponen concatenados

Un ámbito de ejecución es una especie de punto embebido, una forma de indicar que se van a aplicar las reglas en determinado momento de la ráfaga de interacción entre suap y el usuario por ejemplo. Es decir, imaginemos el proceso de “Autorizar” una orden, el momento en que el usuario presiona el botón “Enviar definitivamente”. Ese procedimiento es algo que ocurre en el ámbito “Autorizar” de una entidad de tipo “Orden”.

Este ámbito es el modo en que se incorpora información a la entidad para ser presentada a un usuario. El usuario puede ser un ser humano o un sistema. Por ejemplo, aquí se anexan los datos de bono y numeros de chequera y etc particulares del convenio.

Se pasa una entidad y solamente se crea una variable que se puede recuperar. No se afecta NADA, solo se construye esa variable/arreglo en el entorno para poder ser obtenida luego de la ejecución del convenio en este ámbito. La variable esa es datosRender.

Aquí se encuentran todas las reglas que se pueden utilizar en convenio. Están separadas según el tipo de función que realizan sobre el convenio. Todas las reglas extienden la clase sfReglaBase o sfReglaPrimitivaBase.

Es una clase abstracta que da origen a todas las reglas que interactúan con entidades. Por ejemplo las que modifican ordenes o afiliados. Nunca una regla tiene o requiere una entidad como parámetro, se limita a obtener dicha entidad del entorno.

Es una clase abstracta que da origen a reglas primitivas o que tienen acciones como comandos del lenguajes de convenios, por decirlo de algún modo. Por ejemplo AddAmbito permite la introducción de un ámbito en la lista de ejecución de un bloque de convenio.

Son las reglas que realizan el uso de conectores para interactuar con el sistema del financiador. La regla de nombre es

sfReglaConector_ + ‘convenio’ + _ [ + ‘carrier’ + _ ] + ‘acción’

Por ejemplo sfReglaConector_OSDE_ITC_setup.

Si bien el carrier es opcional conviene poner algo siempre, por ejemplo si es directo al sistema del financiador, se podría poner DIRECTO.

Hay una serie de reglas de conector que en gral deben estar y son:

Esta regla sirve básicamente para contener y configurar los parámetros. Prácticamente lo único que hace es poner en el entorno dichos parámetros. Lo hace debajo de la clave “parametrosConector”. Ejemplo de implementación:

$parametrosConector = $this→parametrosArr;
– codigo de control o reporte de errores si fuera menester –
$this→entorno→setToVariables(‘parametrosConector’, $parametrosConector);

Esta regla obtiene desde el financiador un afiliado. Los datos que va a utilizar los obtiene de la variable de entorno afiliadoExterno. Debe devolver un suapAfiliadoExterno en la variable de entorno afiliadoObtenido. En caso de no poder porque dio error el conector debe poner un error en el entorno con $this→entorno→addError(‘El conector dio error coso’); Además debe reportar el ultimo error en la variable de entorno lastError

Dentro de las reglas de conector hay unas que no son particulares de un financiador, que intentan ser genéricas. Son:

Esta regla construye una ordenExterna para que el conector pueda enviar al sistema del financiador. La M1 es por “Metodo 1”. Es decir, no se bien como nombrar las posibles opciones para armar ordenExterna. La problemática que resuelve esta regla es obtener parámetros laterales que no están en la orden en si misma. Como por ejemplo sucursales, tipo de matrícula del efector, tipo de matrícula del efector. Toda información que suele estar dispersa en datos extra, o en arreglos de datos extra.

Este Metodo1 es muy practico para obtener datos compatibles con la filosofía ITC, el carrier de OSDE.

Volver