Teoria Altamira Cics

8/11/2019 Teoria Altamira Cics

1/125

- 1 -


2/125

- 2 -

Casa abierta al tiempoes la frase que adoptada como lema institucional, expresa con profundosentido la visin y el espritu del proyecto acadmico de la Universidad Autnoma Metropolitana.

Convertida la frase el lema, apunta a los propsitos de la Universidad, que es Casa abierta altiempo portador de sentido, posibilidad de saber y de dilogo.


3/125

- 3 -

SICOTIP: Sistema de comunicacin para aplicaciones distribuidas(IG's) Cliente con comunicacin a un MainFrame-Host.

Resumen.

El presente trabajo describe la propuesta de desarrollo del sistema de comunicacin consockets TCP-IP, entre un sistema distribuido y un equipo central (Mainframe). Se pretende que elproyecto a desarrollar pueda usarse en alguna empresa financiera, donde los sistemas pequeostienen la necesidad de comunicarse con el equipo central o Mainframe.

El tipo de sistema distribuido al cual nos enfocaremos, sern los llamados Call Center, as como losequipos automticos de audio y respuesta los llamados IVRs. Estos son usados para la atencin

telefnica de clientes de una empresa bancaria. Este tipo de sistemas que tambin tiene lanecesidad de interactuar informacin con el equipo central, pero con la caracterstica adicional queel tpo de respuesta es un tema crtico, por lo que debe de ser rpido.

El mainframe es el encargado de almacenar y centralizar toda la informacin de la cartera declientes, en este tipo de empresas. Los equipos pequeos son los puntos donde se inician lassolicitudes o requerimientos de operaciones bancarias o de servicio, que necesitan los clientes, yestos equipos retransmiten, informan o solicitan la peticin al equipo central.

Con el desarrollo, se pretende mejorar los tiempos de respuesta que se tiene en la comunicacinentre los equipos pequeos (Call Centers e IVRs). Donde se ha encontrado que muchas empresasbancarias manejan protocolos de comunicacin ms lentos y arcaicos. Un ejemplo muy claro es eluso de sesiones de SNA, en el cual se necesitaba crear un GUI la cual interactuaba a una sesin

de SNA creando una emulacin 3270 y internamente la aplicacin GUI enviaba comandos a lasesin, tal como si se interaccionaba directamente sobre la emulacin. Por lo que la GUI soloservio para visualizar la informacin de manera grafica, a este proceso se de denomina screenscraping. Este proceso de programacin es muy lento y poco practico, debido a que se tienerealizar doble desarrollo, uno en la aplicacin distribuida, as como su contraparte en el sistemacentral, para la creacin de las pantallas que proporcionen la informacin.

Se pretende que el desarrollo tenga como beneficios: disminuir considerablemente el tiempo quetarda una llamada que realizan los clientes al Banco, por lo que esto se traducir en disminuircostos; aumento de la satisfaccin del cliente, as como mejorar la atencin del cliente; al contarcon una comunicacin mas rpida, da la oportunidad de ofrecerle mas productos y servicios a losclientes, los cuales usan el telfono como medio de interaccin con la empresa bancaria.

Otro aspecto a considerar, es cuando el banco realiza la subcontratacin de empresas(Outsourcing) de servicio de call centers, para que proporcionen parte del servicio de atencintelefnica. Por lo que parte de la propuesta, en el sistema a construir, es que incluya un servidorProxy. El cual servir de entidad intermediaria de conexin entre alguna empresa extrna y laempresa bancaria, la cual contrata sus servicios.

Tambin, se considera que el sistema cuente con un mdulo de encripcin. Donde se propone queeste mdulo sea implementado en el estndar TDES, con el objetivo de encriptar los datossensibles del mensaje que viaje entre la entidad externa y el banco, garantizando la


4/125

- 4 -

confidencialidad de la informacin del los clientes. Este mdulo ser configurable para poderseusar o no, en base a las necesidades del negocio.

El sistema a desarrollar constara de dos componentes principales, el mdulo cliente y el mduloservidor TCP-Proxy, los cuales estn fundamentados en el manejo sockets TCP del protocolo TCP-IP, garantizando un mejor enlace.

La construccin del proyecto estar basado en C++, para garantizar mayor performance, astambin nos permita poder tener la capacidad de realizar balanceo de cargas y tener la capacidadde transportabilidad en otras plataformas.

Es entonces, que el mdulo cliente permitir el envo y recepcin de mensajes en formato PS9(protocolo lgico de informacin estndar para comunicacin con el MainFrame), dando laposibilidad de usar o no encripcin.

La parte del modulo de servidor TCP-Proxy, tendr como funcin la retransmisin de mensajes quereciba del modulo cliente, para las empresas externas de call center. Este componente, contarcon la habilidad de ser multitarea (multithread), tambin se pretende que maneje la programacinparalela y poder aprovechar la infraestructura del servidor o equipo que lo aloje, ms si cuenta conprocesadores multicore y/o multiprocesador.


5/125

- 5 -

Agradecimientos.

Doy gracias a mis padres, por el apoyo incondicional que siempre me han dado y por que siempre

creyeron en m.

Rodolfo Rosas Rico y Lucia Daz Herrera.

Mi sincero agradecimiento hacia mis hermanos: Maria, Sergio, Rodolfo y Vernica.

Por su apoyo y motivacin en mis estudios.

Agradezco el gran apoyo del Maestro Omar Lucio Cabrera como mi asesor

de proyecto.

Mi reconocimiento y agradecimiento a la Universidad Autnoma Metropolitana, por ser la

institucin de excelencia para la formacin de profesionistas e investigadores de excelencia y de la

cual estoy orgulloso de haber egresado.

Dedicatoria;

Dedico la presente obra a mi hermosa familia: mi esposa Celia, a mi nenita Lilian y al bebe

que estamos esperando.


6/125

- 6 -

Contenido1 Introduccin.

2 Sistemas de Atencin Telefnica.

2.1 Introduccin.

2.2 Arquitectura base. PBX, IVR's y CTI.

3 MainFrame (Host).

3.1 Introduccin.

3.2 Arquitectura sobre Host MainFrame.

3.3 Cics Bridge TCP-IP.

3.4 Protocolo PS-9.

4 Programacin concurrente y paralela.

4.1 Introduccin.

4.2 Programacin Multihilo.

4.3 Modelos y herramientas de programacin paralela.

4.4 Modelo y herramientas usados en el proyecto.

5 Criptografa.

5.1 Introduccin

5.2 TDES y base 64, para el manejado en el proyecto.

6 Sistema de comunicacin TCP-IP para aplicaciones cliente a Mainframe-Host (SICOTIP).

6.1 Requerimientos.

6.2 Anlisis.

6.3 Diseo.

6.4 Construccin.

6.5 Conclusiones y resultados.

7 Referencias

Anexo A. Cdigo fuente.


7/125

- 7 -

SICOTIP: Sistema de comunicacin para aplicaciones distribuidas(IG's) Cliente con comunicacin a un MainFrame-Host.

1 Introduccin.

El presente trabajo describe el desarrollo para la solucin de comunicacin de aplicacionesdistribuidas de atencin telefnica en la industria bancaria por sockets de TCP-IP, hacia el sistemacentral (Host OS-390). Esto en base la necesidad de contar de un medio de transmisin seguro deinformacin y as como un medio mucho ms rpido en tiempo de respuesta. Con el objeto deminimizar el tiempo de las llamadas que realiza los clientes al servicio de atencin telefnica. Esteservicio se proporciona con infraestructura de equipos de audio-respuesta automtico IVR's y/oatencin por asesores llamados Call Centers.

Muchas empresas que ofrecen de estos servicios, para no invertir en infraestructura de este tipo, otener que mejorarla constantemente. Recurren en la subcontratacin de empresas externas(llamadas Outsourcing), las cuales dan el servicio de call centers. Con esto las empresasoutsourcing pueden proporcionar parte o todo del servicio de atencin telefnica a nombre del laempresa que contrata.Para que la empresa financiera pueda operar de manera adecuada con estas empresas sepropone como parte de la solucin el manejo de un Proxy (intermediario o sustituto), vindose parael banco como un solo punto o nodo, el cual por razones de seguridad ser solo uno punto aautorizado por el firewall del banco. Esta configuracin permitir que N cantidad de maquinascliente se comuniquen con el Proxy y este retransmita el mensaje de manera segura al Banco yretorne la respuesta al nodo cliente que realizo la peticin original.

Tambin, se contara con un modulo de encripcin en TDES (estndar en muchas de estas

empresas) para encriptar los datos sensibles del mensaje, el cual ser configurable para usarse ono, en base a las necesidades del negocio.

El sistema desarrollado consta de dos componentes principales, el modulo cliente y el moduloservidor TCP-Proxy basados en manejo sockets TCP de TCP-IP garantizando un mejor enlace.Todo el desarrollo se construyo en C++ para garantizar mayor performance, balanceo de cargas ytransportabilidad en diferentes plataformas.

Por lo que, el modulo cliente permitir el envo-recepcin de mensajes en formato PS9 (protocololgico de informacin estndar para comunicacin con el MainFrame) con y sin encripcin.

La parte de mdulo de servidor Proxy TCP, tendr como funcin la de retransmitir los mensajesque reciba de la aplicacin cliente que provengan de empresas externas que den el servicio de Call

Center. En donde este componente tendr la capacidad de ser multihilo (multithread), as comoampliando la capacidad de usar las ventajas de la programacin en paralelo. Pudiendo explotar lasventajas de contar con un servidor que tenga una arquitectura de procesadores multicore y/omultiprocesador.

Es entonces que el mdulo cliente permitir el envo-recepcin de mensajes en formato PS9(protocolo lgico de informacin estndar para comunicacin con el MainFrame) con y sinencripcin.


8/125

- 8 -

La parte del modulo de servidor TCP-Proxy, tendr como funcin la retransmisin de mensajes quereciba del mdulo cliente, para las empresas externas de call center. Este componente contara conla habilidad de ser multitarea (multithread), as como la posibilidad de usar programacin paralela,teniendo la posibilidad de aprovechar la existencia de algn servidor con procesadores multicorey/o multiprocesador.

2 Sistemas de Atencin Telefnica.

2.1 Introduccin.

En cualquier institucin financiera o Banco, es comn que se cuente diferentes medios deinteraccin y atencin de los clientes, por los cuales se ofrecen los servicios de la empresa. Estosmedios pueden ser por ejemplo: el ms comn son las sucursales, el segundo mas comn es portelfono o denominado como atencin telefnica (que proporcionan el servicio por medio deequipos automticos llamados IVRs y los llamados Call Centers, los cuales dan la atencinpersonalizada por medio de asesores telefnicos). Tambin estn los portales de serviciofinanciero, que es un sitio Web el cual se accesa va Internet. Esta tambin los cajeros o ATMs, loscuales dan muy comnmente el servicio de retiros de dinero y consulta de saldo, a un que masrecientemente ya dan servicio de depsitos de efectivo, entre otros mas servicios. El serviciobancario mvil, es un medio que tiene poco tiempo que ha surgido en Mxico, el cual es por mediode acceso a la banca a travs de un celular o un smartphone, por medio del cual se realizan lasoperaciones con el banco. Otro medio es el Kiosco, el cual principalmente sirven para realizarconsultas de saldos y de sus ltimos movimientos en su cuenta, estos dispositivos normalmente seles ubica en plazas comerciales. Estos son algunos de los ms principales, pero existen cada vezmas una gama de medios de interaccin del cliente (llmese persona fsica o moral).

Un canal de comunicacin, es una manera de denominar a cada una de las vas por las que la

institucin bancaria ofrece sus servicios financieros a sus clientes e incluso a sus no clientes. Parael presente trabajo, el sistema a desarrollar surgir como una solucin para la comunicacin msrpida, para el canal de comunicacin de atencin telefnica. La atencin telefnica de clientes yno clientes de algn Banco que requieran una ayuda y/o atencin de cualquiera de los productosy/o servicios que ofrezca la institucin financiera.

El enfoque estar dado para que los servicio sean proporcionados a nivel nacional por un o variosCall Center internos y por un o varios Call Center Externos.

Elementos que interviene en un servicio telefnico bancario:

Sistema CTI. Su funcin

Integracin del Programa Producto y desarrollos que permiten tener funciones de screen pop enlos equipos desktops de los asesores telefnicos, permite realizar retornos a puntos exactos en losIVRs, transferencia de llamadas con voz y datos entre alguno de los supuestos sites de un serviciotelefnico de tipo bancario y otros mas sites de origen externo. Adems permite a los asesoresrealizar las funciones telefnicas a travs del CTI integrado a los aplicativos de servicio, estopermite a su vez poder tener un registro a detalle de todas las acciones que toman los asesorescon los clientes, pudiendo entregar a la operacin y al staff de un servicio telefnico de la empresaBancaria los diversos tipos de reportes, que ayudan al monitoreo y el performance de la operacin.


9/125

- 9 -

Flujo inicial de la llamada en coordinacin de un CTI, con una infraestructura propuesta.

Continuacin del flujo de la llamada con coordinacin de un CTI.

Interaccin de un CTI en una propuesta de flujo de llamada

ClienteCliente

COMPAIA

AN

AN

La llamada llega aLa llamada llega aGrupo de

i i iGrupo de

i i inn

Se transfiere alISe transfiere alI

PBX informa a CTIPBX informa a CTIDe lallDe lall

SYMPOSIU

CTI

CTI InformaCTI Informa Inform

Inform

aaIVR Datos de lallIVR Datos de lall

AN

AN

IVR IniciaI iIVR IniciaI i

n con elli

n con elliY aplica Script Programado y valida si esY aplica Script Programado y valida si es

Llamada.Llamada.Convierte instrucciones delli

Convierte instrucciones delliEn Transacciones hacia elEn Transacciones hacia el

WA

HOS

HOST

11

22

33

44

55

66

77

PBXPBX a llamadaa llamadaAlIAlI

Cliente MarcaCliente Marca

Compaa que proporcionael servicio Telefnico

WA

HOS

Clienteli i

Clienteli iTransferenciaTransferencia

UnUn

IVR Arma cadena con los datos delIVR Arma cadena con los datos delCliente yCliente y a solicitud de transferencia al CTIa solicitud de transferencia al CTI

CTI Recibe Sol..

CTI Recibe Sol..AsignaAsigna

i i

CTI

Symposiu

CTI RecibeCTI Recibei i

n den deiEn

En

a Datos de Transf. Ala Datos de Transf. Al

PBX TransfierellPBX TransfierellAl ID

i i lAl ID

i i l

Agente

Agente

Agente Servicio Tipo

Agente Servicio Tipo

ACD Phon

ACD Phon

Red

Voz

ne

as

Di

git

al

Red

Et

he

rn

ACD Phon

ACD Phon

88

99

1

10

114

1

13

113

El asesor recibe screen pop delEl asesor recibe screen pop delCliente y pasaCliente y pasa info

info

. A. A SDAT

1

15

Termina la llamadaTermina la llamadaO transfiere a otro grupo (repiteO transfiere a otro grupo (repite --15

15

1

16

TablaI

TablaITig045_CT

ITig045_CTI

Se guardai iSe guardai i

n deln delLlamada en

.Llamada en

.1

17

Solicita aSolicita a Symposiu

Symposiu

Real Time tiempos enl

Real Time tiempos enlEn

En

a tiempos de espera alIa tiempos de espera alI

1

11

Informa al cliente tiempos deInforma al cliente tiempos deSolicita

i iSolicita

i in de

in de

i

112

Realizai

Realizai

IV s

PB

Conmutador(es


10/125

- 10 -

I. Interfaces del CTI con otros elementos de la atencin telefnica.

I.I Interfase con aplicaciones de Interfaz Grafica.Esta interfase integra el CTI con la aplicacin desktop de tipo GUI (Interfaz grafica de

usuario, el cual puede ser desarrollada bajo Java, .Net, etc.), la cual utilizaran los asesores paraatender todos los servicios que proporcionan en el centro de atencin telefnico. As como derealizar todas las funciones de telefona desde la aplicacin de CTI (transferencia, conferencias,llamadas de salida).

I.II Interfase con ConmutadorEstas interfases con el conmutador permiten al CTI hacer 4 funciones:

a) DDR: Interfase entre CTI-PBX-IVR encargada de analizar las llamadas que solicitan un

asesor en los IVR para transferirla de manera inteligente, segn el tipo de cliente, serviciosolicitado, antigedad, zona regional, etc. para que se atienda con la prioridad y al grupode asesores mejor capacitados segn cada llamada.Tambin es la encargada de pasar la informacin al los IVR para informarles a los clientestiempos aproximados de atencin

b) RolingDnis: Interfase con diferentes conmutadores encargada de pasar las llamadas convoz y datos entre los diferentes conmutadores.

c) CDN Abandono: Interfase contra el conmutador encargada de almacenar los datostelefnicos y as como de los datos de los clientes de las llamadas abandonadas, para suposterior marcacin.

d) CDN Monitor: Interfase contra el conmutador encargada de identificar y poner etiquetas alas llamadas que no pasan por IVR.


11/125

- 11 -

I.III Interfase con el sistema de grabacin

Esta interfase permite pasar los calificadores de login (clave de firmado del agente en el

conmutador) al sistema de grabacin para que se puedan realizar bsquedas de llamadas poreste valor.

2.2 Arquitectura base. PBX, IVR's y CTI.

Infraestructura Aplicacin IVR de atencin telefnica de algn banco.

En un centro telefnico propuesto se puede contar con ms de 1600 puertos de IVRdistribuidos en 3 sites con cobertura nacional. Bajo este esquema, se podrn recibir en promedio 5millones de llamadas mensuales, de las cuales se transferir slo el 15% para su atencin conalgn asesor telefnico. Los IVRs sern manejados completamente en tonos.

La comunicacin al Host-MainFrame de una institucin bancaria se propone sea a travsde sockets de TCP/IP con el protocolo de formato de tramas PS-9. Los IVRs contaran conlicencias de TTS (Text to speech) para la conversin de texto a voz de los nick names que losclientes le asignan a cada una de sus cuentas de terceros para los traspasos y pagos en el servicio

Interfases de componentes de un CTI.

CT

GUI

-App Distri.

Interfase

Conmutador!

DD

"ollin

CD#$onitoCD#Col%ad

Interfase CTI-Des&to

Interfase

'istema de

Graacn

IV

s

Sistem

de Grabacion

Conmutador(e )


12/125

- 12 -

avanzado. Se contara con una interaccin con CTI a travs de una dll para el manejo de socketsTCP de TCP/IP.

Configuracin propuesta de 3 sites, instalados en tres ciudades principales, que darn servicio atodo el pas.

Algunos de los servicios ofrecidos en el men de autoservicio de atencin telefnica quecomnmente se ofrecen en una institucin financiera.

Una aplicacin de atencin telefnica puede contar con servicios de nmeros telefnicos, como porejemplo: Nmeros locales para cada ciudad principal del pas, un servicio de 01-800 para el restodel pas.

Aunque existen diferentes nmeros telefnicos para los segmentos de clientes, tambin laaplicacin configura automticamente las opciones de servicios y productos a ofrecer en losdiferentes mens, los grupos de transferencia e incluso la voz de los mensajes en base a lainformacin del cliente obtenida a partir de su plstico de acceso.

El men principal de acceso telefnico, puede constar de de tres opciones principalmente: dereporte por robo extravo, men de transaccionalidad y men de servicios:


13/125

- 13 -

El men de robo extravotransfiere las llamadas de forma directa con los asesorespara el reporte de plsticos o cheques, que fueron extraviados o robados.

El men de transaccionalidad contiene la mayor parte de la aplicacin, en l sepueden encontrar diferentes opciones las cuales se presentan en base a los productosfinancieros que tenga contratados el cliente. Contamos con alrededor de 100

transacciones diferentes, las cuales se utilizan a travs de sockets de TCP/IP y tienenel formato PS9. Mensualmente se generan ms de 10 millones de transacciones. El men de servicios contiene la mayor parte de las opciones de transferencia.

Previo a la transferencia se realizan validaciones en los productos de los clientes, enalgunos casos se evita la transferencia informando al cliente, por ejemplo, el estatusde una aclaracin, el envo de un plstico a domicilio, entre otros.

Confi%uracin de ejemplo de un ser(icio telefnico ancario!

CENTRO1

CENTRO2 CONMUTADOR 1CONMUTADOR 2

CIA TEL

CIA TEL

CIA TEL

CIA TEL

')$P*'IU$

+I#,

'"VID*"

CTI

IV" '

')$P*'IU$

+I#,

'"VID*"

CTI

IV"' AGT'

'"VID*"

CTI

IV" '

CENTRO3

CALL CENTER

AGT'

81579111

36690229

9E1

52262663

27E1562411XX

6E1

CIA TEL

52262663

13E1

/

160CH/6E|

11E15E1

11E1

27E1

/

0/

')$P*'IU$

+I#,

'"VID*"

CTI

IV"'

')$P*'IU$

+I#,

012 PT'

/1 PT'033 PT'

350 AGTES

400 PT'

CALL CENTER

3E1

03 AGT'


14/125

- 14 -

3 MainFrame (Host).

3.1 Introduccin.

Un mainframe es una computadora grande, con mucha capacidad, la cual es utilizadaprincipalmente en empresas que necesitan procesar gran cantidad de datos y/o soportar grancantidad de usuarios, muy comn en la industria bancaria. Un mainframe puede funcionar durantemuchos aos sin problemas, ni interrupciones o incluso puede repararse mientras estafuncionando.

Tambin puede simular el funcionamiento de cientos de computadoras personales (terminadoresvirtuales) dentro de una empresa. Un mainframe no es lo mismo que una supercomputadora.

Un mainframe es un repositorio de central de datos o un Hob, en una corporacin conprocesamiento central de datos. Este esta enlazado con los usuarios que cuentan con dispositivoscon menos poder, tales como terminales, estaciones de trabajo o equipos de escritorio. Lapresencia de un mainframe frecuentemente implica una forma centralizada de computacin, que eslo opuesto a una configuracin de computacin distribuida.

Los equipos pequeos distribuidos, han estado creciendo enormemente, tal es el caso que labrecha de distincin entre estos y un mainframe es cada vez ms confusa. Considerado esto, elnuevo enfoque de los mainframe, es ahora basado en su interaccin en combinacin de redes depequeos servidores (sistemas distribuidos) en una infinidad de configuraciones, en base a lasnecesidades de las empresas.

Los nuevos mainframes, deben de contar con una flexibilidad y evolucin natural, la cual subraya la

habilidad que tengan estos de reconfigurarse dinmicamente en aspectos de hardware y/osoftware (considerando procesamiento, memoria, disponibilidad de conexiones de dispositivos),esto mientras las aplicaciones continan ejecutndose simultnea o paralelamente.

El sistema operativo z/OS, es el S.O. usado principalmente en un mainframe. El sistema z/OS quese instala en un mainframe, esta diseado para ofrecer un estable, seguro, y una continuadisponibilidad de ambiente de aplicaciones en ejecucin. Hoy en da, el z/OS es el resultado dedcadas de avances tecnolgicos, el cual fue evolucionando de ser un S.O. que solo podaejecutar un simple programa a la vez, a un S.O. que puede manejar muchos de miles deprogramas a la vez y a su vez, proporcionar una interactiva concurrencia de usuarios.

El Cics, definido por Costumer Information Control System. Es un subsistema de procesamientotransaccional de propsito general, enfocado principalmente para el z/OS. Donde el Cics provee deservicios que pueden ser ejecutados en una aplicacin en lnea (en lnea significa, que el sistema

proporciona una interaccin y respuesta inmediata con el usuario), en base al requerimiento delusuario. Esto permite a muchos usuarios puedan realizar solicitudes de requerimientos al mismostiempo. Se cuenta con el enfoque interno de que se puede ejecutar la misma aplicacin, usandolos mismos archivos y programas (denominado cdigo reentrante).

El Cics permite manejar los recursos compartidos, as como la integridad de los datos y priorizacinde ejecucin, proporcionando una rpida respuesta. Tambin autoriza a los usuarios, alojar losrecursos (almacenamiento real y ciclos de ejecucin), as como, dar pasa a los requerimientos debase de datos, por la aplicacin, con el apropiado manejador de base de datos (tal como DB2).


15/125

- 15 -

Nosotros podemos decir que Cics acta como el z/OS y realiza muchas de las mismas operacionesque el z/OS sistema operativo.

Una aplicacin Cics, es una coleccin de programas relacionados, los cuales juntos realizan unaoperacin de negocio. Unos ejemplos pueden ser, el procesamiento de una solicitud de viaje o lapreparacin de una nmina de una empresa. Las aplicaciones de Cics, son ejecutadas bajo el

control de Cics, usando servicios de Cics y sus interfaces de acceso a programas y de archivos.Las transacciones de cics son normalmente realizadas por ejecucin de un requerimiento detransaccin. La transaccin ejecutada consiste en con correr una o mas programas de aplicacinque implementan la funcin requerida.

3.2 Arquitectura ASTA (Altamira).

La Arquitectura ALTAMIRA es un sistema altamente parametrizado montado sobre Cics. Enesta arquitectura es posible definir las entidades de trabajo, sus entornos y las caractersticasnecesarias para el funcionamiento de tipo on-line, as como del procesamiento en batch.

Una de las utilidades del Sistema de Arquitectura es la gestin de la paginacin de los listados porpantalla (scroll a izquierda, derecha, arriba, abajo) de manera transparente a las aplicaciones, detal manera que se simplifica notablemente el diseo y codificacin de las transacciones de listado.

Una convencin que se tiene entre las diferentes aplicaciones, es que se comunicaran o sehablarn con la Arquitectura, fundamentalmente a travs del rea de comunicacin CAA (un reade memoria estndar).

3.3 Cics Bridge TCP-IP.

El IBM CICS BRIDGE, es un conjunto de programas que forman parte de la interfase CICSSockets y que son instalados conjuntamente con los programas dedicados a tal fin en el CSD de laregin CICS.

El objetivo del CICSBRIDGE es permitir que una aplicacin transaccional sncrona distribuidapueda conseguir la ejecucin de un programa residente en una regin CICS OS/390 y obtener unarespuesta mediante el uso de MQ, Sockets, etc. sin necesidad de que el programa CICS tenga queser modificado para soportar dicha comunicacin.

Debido a las necesidades que se requieren en un banco determinado, es necesaria laimplementacin de una versin modificada de la versin original del Cics Bridge de IBM. En dondea continuacin se menciona una versin propuesta que se puede usar en una empresa bancaria.

A diferencia del monitor de IBM (Transaccin CSKL), la versin propuesta est orientada alaprovechamiento de las facilidades transaccionales sobre CICSPLEX, al distribuir la cargatransaccional en los AORes, evitando la concentracin de transacciones en el TOR y evitandoafinidades, y adicionando facilidades de sesiones y validaciones en RACF.


16/125

- 16 -

Componentes de una aplicacin donde participa cicsbridge.

En un escenario aplicativo donde participa CICS Bridge pueden identificarse:

1)UN COMPONENTE CLIENTE.Es el que posee la informacin que debe ser procesada. Al usar CICS BRIDGE,

necesariamente se considera un componente transaccional, es decir que entregar un mensaje yquedar en espera de la respuesta durante un tiempo preestablecido. El Cliente ser en muchosde los casos un Distribuido (NT, UNIX, etc.). Se debe tener en cuenta que el mensaje que envendebe estar en formato PS-9.

2)UN COMPONENTE SERVIDOR.Es el que puede llamar o efectuar un proceso sobre la informacin contenida en el

mensaje que el cliente enva. Este componente es ejecutado por CICS BRIDGE usando elcomando LINK, por lo que el contenido del mensaje es recibido en COMMAREA, siendo luegoreemplazado por la respuesta o resultado del proceso.

3)CICSBRIDGE.Son los componentes ARRANQUE, MONITOR, PROCESADOR y SALIDA los que

conforman el modelo de CICS Bridge. El ARRANQUE ejecuta la(s) Transaccin(es) MONITOR(es),que son las encargadas de recibir mensajes en cualquier momento, tomarlos y mandarlos aprocesar, el PROCESADOR identifica el mensaje y enviar hacia la arquitectura ASTA a ejecutarla transaccin requerida, al regreso de la arquitectura el procesador enva la respuesta alcomponente de SALIDA que es el que restablece la comunicacin con el distribuido y entrega larespuesta.

DDiiaaggrraammaaddeeFFlluujjooCCiiccssBBrriiddggeeTTCCPP//IIPPqquueeppuueeddeesseerruussaaddooeennuunn

AApplliiccaattiivvoo QPTPTCP/

IP

Servi

TCP/IP

Servi

TCP/IP

Serv

ARQUIT

ECTURA

APLICA

TIVO

S

QGPARTCP

CCIICCSS

CCIICCSS

CICSSockets

APIXYZ

QOxxDFHMIR

'TA"TU'"ID G#"IC*

'TA"TU'"ID G#"IC*

+I#, T"A#'ID

5CT+

QG1CS +I#,

QTxxQG1CSER

MQ

'TA"T


17/125


18/125

- 18 -

3.4 Protocolo PS-9.

El protocolo de comunicacin entre el distribuido y el host, esta dado por el Cics bridgeTCP debido a su desarrollo, aunque tiene un parmetro de protocolo que puede ser til en caso deno querer utilizar el protocolo definido.

Teniendo en cuenta que es un sistema de comunicaciones de un cliente ya sea un distribuido o unhost hacia el equipo host de BBVA, atendiendo requerimientos principalmente de aplicaciones quese encuentran bajo la arquitectura Altamira, el flujo comienza en con el cliente. Antes de comenzara describir el protocolo definiremos algunos de los formatos en los cuales se enviara la informacin.

) MESSAGE DESCRIPTOR DE TCP.Formato de informacin de 160 posiciones fijas, en elcual se incluyen parmetros y datos propios de la aplicacin y del operador, esteformato tendr que ser enviado siempre. Los campos contenidos en este formato

son:

Descripcin del Campo Tipo Valor Default posibles

TAG DE INICIO DEL MESSAGE DESCRIPTOR X(04)

LA VERSION DEL DISTRIBUIDO X(05) 1.0.0

LONGITUD MAXIMA DEL MENSAJE PS9 9(05) 32584

IDENTIFICACION DEL MENSAJE ENVIADO X(24) Valor que hace msg nico

TIEMPO PARA MONITOREO EN SEG. (WAITINTERVAL) 9(05) 00600

REQUERIMIENTO SOLICITADO de MD X(04) **** , LOGN, LOGF, VERY, LRSS,CHPW

TIPO DE USUARIO X(08) USERGENE, USERRACF,USER3270, USERDGPO

TIPO DE VALIDACION DEL USUARIO X(04) **** RACF

CORRESPONDE AL USERID FINAL X(08) USERID de 8 Posiciones

CORRESPONDE AL USERID DE GRUPO X(08) Usuario de grupo si es el caso

PASSWORD ENCRIPTADA (BASE 64) X(12) Password encriptada Base 64

PASSWORD NUEVA ENCRIPTADA (BASE 64) X(12) Nva Password encriptada B64

NUMERO DE SESION 9(08) 00000000 Nmero de sesin

FECHA DE ENVIO X(10) AAAA-MM-DD

HORA DE ENVIO X(08) HH:MM:SS

DISPONIBLE X(30) Espacios

TAG DE FIN DEL MESSAGE DESCRIPTOR X(05)

Los siguientes formatos son propios del PS-9 Protocolo Informacin.

) INPUT HEADER PS9. Header del Formato PS9 de 65 posiciones fijas. Este serinmediato al message descriptor de TCP.


TAG DE INICIO DEL INPUT HEADER X(04)

CODIGO DEL PROTOCOLO DE INFORMACION X(02) 26 para formato PS9


19/125

- 19 -

TERMINAL LOGICO X(08) Terminal lgicoalfanumrico

TERMINAL CONTABLE X(08) Terminal alfanumricocontable

USUARIO X(08) User-id que enva lainformacin

NMERO DE SECUENCIA X(08) Nmero de secuencia

CODIGO DE LA TRANSACCION X(08) TransaccinOPCIN 9(02) Intro=00,F1=01,F2=02...

LONGITUD TOTAL DEL MENSAJE PS9 9(05) Longitud PS9 desde a

INDICADOR DE COMMIT EN ALTAMIRA 9(01) 0 Sin commit 1 concommit

TIPO DE MENSAJE 9(01) 1- New Request,2- Authorization,3- Conversation ScrollInfo.,5- ConversationContinuation,6- Authorization in aconversation

TIPO DE PROCESO X(01) O On-line F Off-line

CANAL X(02) Canal de la aplicacinINDICADOR DE PREFORMATEO X(01) Y Formateo N Sin

FormateoLENGUAJE X(01) Alfanumrico indicador el

lenguajeTAG DE FIN DEL INPUT HEADER X(05)

) INPUT MESSAGE. Este es el formato del mensaje que dependiendo del tipo de mensajedescrito en el Input Header y dependiendo de la transaccin enviada ser de formatoy longitud variable. El formato ms comn que se utilizar bajo Cics bridge ser elsiguiente. Para mayor informacin sobre otro formato consultar el documentoinformacin del protocolo PS-9.


TAG DE INICIO DEL INPUT MESSAGE X(04) LONGITUD DEL COPY 9(04) Longitud del COPYTIPO DEL COPY X(01) C si es COPY B

Si es BMSCOPY X(---) Datos del copyTAG DE FIN DEL INPUT MESSAGE X(05)

El programa QG1CMTCP monitor bajo Sockets, una vez realizada la conexin a la IP y puertocorrespondiente mediante APIs de Sockets, empieza por validar los tres formatos. Dependiendodel requerimiento del cliente es como se procesara la informacin.


20/125

- 20 -

a) Cuando parmetro de host TIPOREQUERes el valor default (espacios ****), nos indica que elcliente no requiere de sesiones de Cics bridge. Por lo que por cada peticin del cliente tieneque enviar la siguiente secuencia de formato:

1. El programa leer todo lo que el cliente enve y primeramente tomara la parte de elmessage descriptor TCP checando los tags de este formato en la posicin

correspondiente, tambin valida que los campos longitud mxima de ps9, waitinterval ynmero de sesin sean numricos, en caso de que no sean correctas cualquiera deestas premisas se enviara el error correspondiente y cerrada el socket asignado.

2. Una vez validado el Message descriptor, el programa toma la segunda partecorrespondiente al Input Header PS9, en esta parte checa los tags del Input Headerque se encuentren en la posicin correcta y se valida que el campo de longitud total delmensaje PS9 sea numrico. En caso de que no sea satisfactoria la respuesta a estasvalidaciones se regresara el error correspondiente.

3. Si hasta este momento todo va bien, se hacen las operaciones correspondientes parachecar la longitud de la commarea a enviar a la transaccin procesadora y se le realizael START correspondiente, enviando el socket que se tomar para regresar larespuesta y cerrando el socket asignado para recibir la informacin.

4. Para este esquema existe una variante si el parmetro TIPOUSUARI es USER RACF,TIPOVALIDA es RACF y REQUERIMIENTO del Message Descriptor es LRSS, setomar el usuario y password que venga en el Message descriptor y se realizar lavalidacin en RACF si es correcto se proceder a realizar el START a la transaccinprocesadora correspondiente y en caso contrario se regresar el error correspondiente.

b) Cuando parmetro de host TIPOREQUER es el valor SESI, nos indicar que el cliente requierede sesiones de Cics bridge. Bajo un esquema de sesiones primero tiene que firmarse al Cicsbridge haciendo el LOGON y una vez firmado comenzar a enviar las operacionescorrespondientes, una vez terminada su actividad tendr que dejar la sesin haciendo elcorrespondiente LOGOFF.

5. Para el requerimiento del MD sea LOGN LOGF correspondiente al LOGON yLOGOFF solo es necesario enviar el formato del Message Descriptor, mismo que servalidado como el punto 1. En el LOGN se crear una sesin para el usuario enviado enel MD. Para el LOGF ser necesario indicar el usuario y nmero de sesin a la cual sequiere dar de baja.

6. Cuando se requiera operar alguna transaccin se tendr que enviar una trama de lasiguiente forma: ,

Pero aqu en el MD se tendr que indicar el usuario, nmero de sesin y requerimiento igual aVERY. El programa realizar el punto 1 posteriormente validar que exista la sesin y contengaal usuario indicado, de tal forma que si es correcto realizara el punto 2 y 3, en caso de que noexista la sesin que el usuario no corresponda a la sesin se regresar el errorcorrespondiente.

7. Para este esquema tambin existe una variante si el parmetro TIPOUSUARI esUSERRACF , TIPOVALIDA es RACF y REQUERIMIENTO del Message Descriptor esLOGN, se tomar el usuario y password que venga en el Message descriptor y serealizar la validacin en RACF si es correcto se proceder a generar la sesin y encaso contrario se regresar el error correspondiente. Esto es solo en el momento delLOGON ya que de esta forma solo hay una validacin en RACF y no una por cadapeticin.


21/125

- 21 -

c) Existe tambin una funcin cuando parmetro de host TIPOUSUARI es USERRACF ,TIPOVALIDA es RACF y REQUERIMIENTO del Message Descriptor es CHPW. Esterequerimiento es el cambio de password en el cual solo se enva el formato del MessageDescriptor con estos valores adems del user-id password y nuevo password encriptados. ElHost desencriptar el password y new password tomando la llave de Desencripcincorrespondiente y tomando el user-id ejecutar el commando CHANGE PASSWORD

cambiando el password sea correcto o errneo regresar el mensaje correspondiente alcliente.


22/125


23/125

- 23 -

traditional Altamira architecture)'6' - Indicates that an architecture error

has ocurred. The applicationprogram informs that the OutputScreen has been prepared and theOutput format does not exist.

The user should advise CPD to checkthe LOG. (Only applicable in

traditional Altamira architecture)'7' - Indicates that an architecture errorhas ocurred. In case of prefortatingindicator, the preformat namerelated to the espedified format isnot informed or does not exist. Theuser should advise CPD to checkthe LOG. (Only applicable intraditional Altamira architecture)

A Indicates that an Abend Error hasocurred. The user should adviseCPD to check the LOG.

SSSSSSSS 8 Sequence number Any Alphanumeric set of characters. Frontend or middleware will provide thisnumber. Altamira will just give it back. It isused to synchronize back and front end.

NNNNN 5 Output message length. Also needed forvalidation purposes and also to identifythe end of the message.(Output Header Length + Output DataLength)

Any number between 26 and maximumoutput length.

TTTTT 5 Tag Indicating end of output header Total de longitud: 26 bytes.

FFOORRMMAATTOOSSDDEEMMEENNSSAAJJEESSDDEESSAALLIIDDAA..

.. - Error map. .. - Warning map. .. - Next transaction map. .. - Journal map.

.. - Destination map.

.. - Output Copy map. .. - Scroll Map. .. - Conversational Authorization map. .. - Unexpected Message map. .. - Preformated Data map.

FFOORRMMAATTOODDEEEERRRROORR..

Field Bytes Meaning Possible ValuesTTTT 4 Tag for beginning of error map CODERR 7 Error code Any Alphanumeric set of characters

following Altamira standard for error

namesNUMVAR 1 Number of variables Any value >= 0. When NUMVAR is equal

to 0, the Variable fields wont be sent.ERRVAR1 20 First error variable data Any Alphanumeric set of characters

(if NUMVAR > 0)

ERRVARN 20 Error variable data number N Any Alphanumeric set of characters(if NUMVAR > 1)

TTTTT 5 Tag for end of error map Mxima longitud: ?. Actualmente tenemos un mximo de 2 variables de datos, con 57 bytes.


24/125

- 24 -

FFOORRMMAATTOODDEEOOUUTTPPUUTTCCOOPPYY..

Field Bytes Meaning Possible ValuesTTTT 4 Tag for beginning of destination map. ID 1 ID of the Destination Any value among 1,..,5IND-PANDOC 1 Destination of the format (Screen, Printer, Hard Disk or

JetformP ScreenD Printer

NUM-DOCUM 1 Type of document if the output is to document. 1 DIN A-4 Normal

print.2 DIN A-4Compressed print.3 Sheet5,6,7,8 Savingsbooks.9 DIN A-4 in a laserprinterC CheckB Band (ribbon)I AmountJ Magnetic DiaryR Pre-printeddocument.

PRILIN-DOCUM 2 Position of the first line to be written in the document.IMPRESO 6 ID of the form to be used

IDIOMA 1 Language ID of the language tobe used.TTTTT 5 Tag for end of destination map.

Maxima longitud: 5 x 21 bytes.

Field Bytes Meaning Possible ValuesTTTT 4 Tag for beginning of Output copy map T 1 Type of copy B BMS

C COPYY 1 Number ID of the DE map which

describes the copy destination. 0means no destination

012345

FFFFFFFF 8 Format name / Output number Format name that will match with copy namefollowing Altamira Naming Standards, or theoutput number for the transaction.

? Data Copy of the specified type (BMS or standardCOPY).

TTTTT 5 Tag for end of Output Copy Map

BMS copy sigue la estructura FILLER [longitud-atributo-campo], con un tamao mximo de 2000bytes.En caso de un copy fijo, este consistir de un nmero fijo de campos con contenido alfanumrico.Esto permite usar diferentes copias para la misma transaccin. El copy usado ser definido por elnmero de salida.

Si el destinatario es diferente de 0, debe de existir un mapa destino () que informe el destino

para la salida.En el caso de copy fijo el mapa destinatario ser siempre 0, como el front-end conocer eldestinatario.

Puede haber varios mapas con estructura de copy BMS solo en caso de copy fijo, y ambostipos son exclusivos (por ejemplo, el mensaje puede contener varios de tipo BMS o uno detipo copy)

Longitud maxima: 20 Kb.


25/125

- 25 -

4 Programacin concurrente y paralela.

4.1 Introduccin.

La programacin en paralelo, es una tcnica de programacin en la que muchas instrucciones seejecutan simultneamente o paralelamente. Se basa en el principio de que los problemas grandesse pueden dividir en partes ms pequeas, las cuales se pueden resolverse de forma paralela (noes lo mismo que concurrente). Existen varios tipos de programacin en paralelo: paralelismo a nivelde bit, paralelismo a nivel de instruccin, paralelismo a nivel de datos y paralelismo de tareas.Durante muchos aos, la programacin en paralelo se ha aplicado en la computacin de altasprestaciones, pero el inters en ella ha aumentado en los ltimos aos debido a las restriccionesfsicas que impiden escalarlo con frecuencia. La computacin en paralelo se ha convertido en elparadigma dominante en la arquitectura de computadoras, principalmente en los procesadoresmutincleo. Sin embargo, recientemente, en los equipos paralelos su consumo de energa se haconvertido en una preocupacin.

Las computadoras paralelas se pueden clasificar segn el nivel de paralelismo que admite suhardware: las computadoras de multincleo y multiproceso tienen varios elementos deprocesamiento en una sola mquina, mientras que los clusters, los MPP y los grids emplean variascomputadoras para trabajar en la misma tarea.

Los programas de las computadoras en paralelo, son ms difciles de escribir que los normalessecunciales, porque el paralelismo introduce nuevos tipos de errores de software, siendo las ricecondition los ms comunes. La comunicacin y la sincronizacin entre las diferentes subtareas sontpicamente las grandes barreras para conseguir un buen rendimiento de los programas paralelos.El incremento de velocidad que consigue un programa como resultado del algoritmo paralelizadoviene dado por la ley de Amdahl, el cual permite observar si mejora el performance del programacon el paralelismo.

4.2 Programacin Multihilo.

En los sistemas operativos un hilo de ejecucin, hebra o subproceso es la unidad deprocesamiento ms pequea que puede ser planificada por un sistema operativo.

La creacin de un nuevo hilo es una caracterstica que permite a una aplicacin realizar variastareas a la vez (concurrentemente). Los distintos hilos de ejecucin comparten una serie derecursos tales como el espacio de memoria, los archivos abiertos, situacin de autenticacin, etc.Esta tcnica permite simplificar el diseo de una aplicacin que debe llevar a cabo distintasfunciones simultneamente.

Un hilo es bsicamente una tarea que puede ser ejecutada en paralelo o en el mismo intervalo detiempo con otra tarea.

Los hilos de ejecucin que comparten los mismos recursos, sumados a estos recursos, son enconjunto conocidos como un proceso. El hecho de que los hilos de ejecucin de un mismo procesocompartan los recursos hace que cualquiera de estos hilos pueda modificar stos. Cuando un hilomodifica un dato en la memoria, los otros hilos acceden a ese dato modificado inmediatamente.

Lo que es propio de cada hilo es el contador de programa, la pila de ejecucin y el estado del CPU(incluyendo el valor de los registros).


26/125


27/125

- 27 -

4.4 Modelo y herramientas usados en el proyecto.

El OpenMP C y C++ APIs permite escribir aplicaciones que efectivamente usen mltiplesprocesadores. Visual C++ soporta la versin OpenMP 2.0 Standard, el cual forma parte de VisualStudio 2008, versin que se genero el cdigo para que la aplicacin soporte paralelismo.

Directive Description

atomic Specifies that a memory location that will be updated atomically.

barrier Synchronizes all threads in a team; all threads pause at the barrier, until all threads execute

the barrier.

critical Specifies that code is only executed on one thread at a time.

flush (OpenMP) Specifies that all threads have the same view of memory for all shared objects.

for (OpenMP) Causes the work done in a for loop inside a parallel region to be divided among threads.

master Specifies that only the master threadshould execute a section of the program.

ordered (OpenMP Directives) Specifies that code under a parallelized for loop should be executed like a sequential loop.

parallel Defines a parallel region, which is code that will be executed by multiple threads in parallel.

sections (OpenMP) Identifies code sections to be divided among all threads.

single Lets you specify that a section of code should be executed on a single thread, not necessarily

the master thread.

threadprivate Specifies that a variable is private to a thread.

parallel.Define una regin paralela, la cual es el cdigo que ser ejecutado por mltiples hilos enparalelo.

#pragma omp parallel [clauses]{

block de codigo}

Donde,

clause(optional)

Cero o mas clausulas.

En seguida se muestran las clusulas soportadas por la directivaparallel.

copyin

default (OpenMP)

firstprivate

if (OpenMP)

num_threads

private (OpenMP)

reduction

shared (OpenMP)


28/125

- 28 -

Ejemplo de uso de la directiva parallel:

// omp_parallel.cpp// compile with: /openmp#include

#include

int main! {#pragma omp parallel num_threads"!

{int i omp_get_thread_num!$print%_s&'ello %rom thread (d)n&* i!$

}

}


29/125

- 29 -

5 Criptografa.

5.1 Introduccin

Criptologa (del griego krypto, oculto, y graphos, escribir, literalmenteescritura oculta) tradicionalmente se ha definido como la parte de la criptologa que se ocupa delas tcnicas, bien sea aplicadas al arte o la ciencia., que alteran las representaciones lingsticasde mensajes, mediante tcnicas de cifrado y/o codificado, para hacerlos ininteligibles a intrusos(lectores no autorizados) que intercepten esos mensajes. Por tanto el nico objetivo de lacriptografa era conseguir la confidencialidad de los mensajes. Para ello se diseaban sistemas decifrado y cdigos. En esos tiempos la nica criptografa que haba era la llamada criptografaclsica.

La aparicin de las Tecnologas de la Informacin y comunicacin y el uso masivo de lascomunicaciones digitales han producido un nmero creciente de problemas de seguridad. Lastransacciones que se realizan a travs de la red pueden ser interceptadas. La seguridad de estainformacin debe garantizarse. Este desafo ha generalizado los objetivos de la criptografa paraser la parte de la criptografa que se encarga del estudio de los algoritmos, protocolos (se les llama

protocolos criptogrficos) y sistemas que se utilizan para proteger la informacin y dotar deseguridad a las comunicaciones y a las entidades que se comunican. Para ello los criptgrafosinvestigan, desarrollan y aprovechan tcnicas matemticas que les sirven como herramientas paraconseguir sus objetivos.

Los grandes avances que se han producido en el mundo de la criptografa han sido posiblesgracias a los grandes avances que se ha producido en el campo de las matemticas y las cienciasde la computacin.

Objetivos de la criptografa .La criptografa actualmente se encarga del estudio de los algoritmos,protocolos y sistemas que se utilizan para dotar de seguridad a las comunicaciones, a lainformacin y a las entidades que se comunican. El objetivo de la criptografa es disear,implementar, implantar, y hacer uso de sistemas criptogrficos para dotar de alguna forma deseguridad. Por tanto se ocupa de proporcionar:

Confidencialidad. Es decir garantiza que la informacin est accesible nicamente apersonal autorizado. Para conseguirlo utiliza cdigos y tcnicas de cifrado.

Integridad. Es decir garantiza la correccin y completitud de la informacin. Paraconseguirlo puede usar por ejemplo: funciones de Hash criptogrficas MDC, protocolos decompromiso de bit, o protocolos de notorizacin electrnica.

No repudio. Es decir proporciona proteccin frente a que alguna de las entidadesimplicadas en la comunicacin, pueda negar haber participado en toda o parte de lacomunicacin. Para conseguirlo puede usar por ejemplo firma digital.

Autenticacin. Es decir proporciona mecanismos que permiten verificar la identidad del

comunicante. Para conseguirlo puede usar por ejemplo: funcin hash criptogrfica MAC oprotocolo de conocimiento cero.

Soluciones a problemas de la falta de simultaneidad en la telefirma digital de contratos.Para conseguirlo puede usar por ejemplo: protocolos de transferencia inconsciente.

Un sistema criptogrfico es seguro respecto a una tareas si un adversario con capacidadesespeciales no puede romper esa seguridad, es decir, el atacante no puede realizar esa tareaespecfica.


30/125

- 30 -

La criptografa de Triple DES se llama al algoritmo que hace triple cifrado de tipo DES. Tambin esconocido como TDES o 3DES, fue desarrollado por IBM en 1998.

Algoritmo. No llega a ser un cifrado mltiple, porque no son independientes todas las subclases.Este hecho se basa en que DES tiene la caracterstica matemtica de no ser un grupo, lo queimplica que si se cifra el mismo bloque dos veces con dos claves diferentes se aumenta el tamaoefectivo de la clave.

La variante ms simple del Triple DES funciona de la siguiente manera:

Donde es el mensaje a cifrar y , y las respectivas claves DES. En la variante 3TDESlas tres claves son diferentes; en la variante 2TDES, la primera y tercera clave son iguales.

Seguridad. Cuando se descubri que una clave de 56 bits no era suficiente para evitar un ataquede fuerza bruta, TDES fue elegido como forma de agrandar el largo de la clave sin necesidad decambiar de algoritmo de cifrado. Este mtodo de cifrado es inmune al ataque por encuentro amedio camino, doblando la longitud efectiva de la clave (112 bits), pero en cambio es precisotriplicar el nmero de operaciones de cifrado, haciendo este mtodo de cifrado muchsimo msseguro que el DES. Por tanto, la longitud de la clave usada ser de 192 bits, aunque como se hadicho su eficacia solo sea de 112 bits.

Usos. El Triple DES est desapareciendo lentamente, siendo reemplazado por el algoritmo AES.Sin embargo, la mayora de las tarjetas de crdito y otros medios de pago electrnicos tienen comoestndar el algoritmo Triple DES (anteriormente usaban el DES). Por su diseo, el DES y por lotanto el TDES son algoritmos lentos. AES puede llegar a ser hasta 6 veces ms rpido y a la fechano se ha encontrado ninguna vulnerabilidad.

Base 64, es un sistema de numeracin posicinala que usa el 64 como base. Es la mayorpotencia de dos que puede ser representada usando nicamente los caracteres imprimibles deASCII. Esto ha propiciado su uso para codificacin de correos electrnicos, PGP y otrasaplicaciones. Todas las variantes famosas que se conocen con el nombre de Base64 usan el rangode caracteres A-Z, a-z y 0-9 en este orden para los primeros 62 dgitos, pero los smbolosescogidos para los ltimos dos dgitos varan considerablemente de unas a otras. Otros mtodosde codificacin como UUEncode y las ltimas versiones de binhex usan un conjunto diferente de64 caracteres para representar 6 dgitos binarios, pero stos nunca son llamados Base64.

5.2 TDES y base 64, para el manejado en el proyecto.

Para el proyecto se utilizo el algoritmo TDES con una llave de bits para garantizar la

seguridad de la informacin. Tambin se usa el algoritmo de base 64 para garantizar la conversinde caracteres entres el sistema distribuido y el Host, debido a que uno usa un mapa de caracteresASCII y el otro EBCDIC, respectivamente.


31/125

- 31 -

6 Sistema de comunicacin TCP-IP para aplicaciones cliente a Mainframe-Host (SICOTIP).

6.1 Requerimientos.

Antecedentes y situacin actual.

Las aplicaciones de una institucin financiera, en su canal de atencin telefnica, el cualesta basada su comunicacin con el cliente, en la interaccin va telefnica. Estas aplicacionesdistribuidas denominadas GUIs, IVRs y CTI, las cuales tendrn enlace con el sistema principalMainFrame, donde se centraliza la informacin de las cuentas de los clientes y toda la informacinnecesaria relacionada con estos.

La aplicacin GUI de atencin telefnica que usaran los asesores, que estarn en los Call Centers(internos o de origen externo, outsoursing), utilizaran las aplicaciones distribuidas paraproporcionar los servicios requeridos por los clientes, esto cuando a los asesores les llega lallamada.

Los IVRs son los equipos de audio-respuesta, los cuales dan arribo de atencin a mas del 80% de

las llamadas a nivel nacional de los clientes y no clientes de la empresa Bancaria, los cualesrequieren algn servicio a travs de las llamadas telefnicas.

CTI, es el sistema automtico que monitorea y da seguimiento lgico a la llamada durante surecorrido en la red de enlace telefnico (integra la telefona y call centres).

Las aplicaciones GUI en muchas variantes, dependiendo la plataforma de implementacin, secomunican al sistema central a travs de la red interna de un banco. Todava ah empresas queusan un software de emulacin de terminales 3270 instalado en las PCS y usando la tcnica descreen scraping para capturar las pantallas tipo Host (24X80 caracteres) y transformarlas a lasventanas de la IG de los asesores.

Este medio de enlace es lento debido a las diferentes transformaciones de informacin, por lo queel tiempo de la llamada se incrementa siendo superior a 3 minutos en promedio total, y superior a 5

segundos por solicitud al Host. Estos tiempos incrementen el costo de la llamada, reflejndose enun gasto excesivo del mismo.

Por lo que la propuesta en este proyecto para algn banco que lo requiera, y que de disminuir lostiempos de la llamada, donde esto implica disminucin del gasto de la misma. Para esto se realizoel anlisis y planteando la situacin actual de alguna empresa bancaria, se propone la solucin pormedio de comunicacin de sockets tipo TCP.

En base a esto, se procedi a realizar el anlisis del problema, encontrando de el principalproblema es el medio de comunicacin hacia el Host. Entre las propuestas de solucin seencontraron las dos siguientes:

MQ Series, software propiedad de IBM el cual proporciona un medio de comunicacin asncronoentre diferentes plataformas. Actualmente ya es una solucin estndar en unas empresas. El

problema principal es costo de las licencias por equipo, as mismo la incompatibilidad con otrasplataformas de software propietario en los IVRs. Otro punto, es el tiempo de comunicacin, el cualno disminuye significativamente como para considerarse la solucin ideal.

Uso de Sockets TCP-IP, siendo el medio mas directo de comunicacin entre redes de datos de tipoTCP-IP. En la arquitectura de ASTA sobre Host, recin se tiene la solucin de comunicacin deSocket denominado CICS Bridge TCP-IP, donde las pruebas iniciales entre equipos distribuidos yel MainFrame tienen tiempos de respuesta de 3 segundos por solicitud. Este mismo esquema en


32/125

- 32 -

Host ya cuenta con un servicio de encripcin bajo TDES y Base 64, para que garantice un canalmas seguro.

Estas dos opciones se presentaron al negocio, indicando que la solucin bajo sockets se requiereun desarrollo de un modulo para las IGs, as como la adecuacin de las mismas para que puedancomunicarse bajo este protocolo. El rea de negocio estuvo de acuerdo con el desarrollo y

modificacin, procediendo a la creacin del requerimiento requisitazo y autorizado, ya con elpresupuesto necesario para la solucin.

Por lo anterior, se determino que la solucin ms idnea para el problema es implementarla sobreun esquema tipo Sockets TCP-IP en distribuido y CICS Bridge Sockets TCP-IP en Host ASTA. Deesto se determina la construccin de un modulo que permita a las aplicaciones distribuidasconcertarse por TCP-IP hacia el Host. Por lo que nace la necesidad de crear la aplicacinSICOTIP.

Presentacin General.

Se requiere mejorar los tiempos de respuesta de las diferentes aplicaciones distribuidas delcanal de Atencin Telefnica de una empresa Financiera, para comunicarse al sistema central ydisminuir el tiempo total de la llamada de los clientes que accedan a este canal. La solucin

necesita poder contar de un medio que garantice la integridad y seguridad de la informacin (canalseguro), as como un medio para minimizar las adaptaciones de comunicacin con entidadesexternas que provean el servicio de atencin telefnica (Call Center externos), cuando lasnecesidades del negocio lo requieran.

Cliente.

Canal de comunicacin de acceso de clientes de un Banco, por va telefnica. A travs delos nmeros locales o del servicio 01800 a nivel nacional.

Metas.

Mejorar el tiempo de respuesta significativamente al que se cuenta actualmente en elservicio de atencin telefnica. Mejorar la satisfaccin de atencin y servicio de los clientes o no

clientes por el Banco a travs del medio telefnico. Disminuir el costo de las llamadas, para que enbase a esto poder ofrecer ms opciones o promociones de productos a travs de este canal, queimplica mayores ventas.

Seguridad de la informacin de los clientes en el canal de Atencin Telefnica. La solucin debesoportar la transaccionalidad de llamadas tanto horarios pico y no pico.

Funciones del sistema.

El sistema permitir disminuir el tiempo de respuesta de comunicacin hacia el Host, por lo queesto implica disminucin de tiempo total de la llamada.

El sistema permitir un canal seguro para la informacin de los clientes, que viaja por este medio.

El sistema contara con un protocolo estndar de comunicacin que permita comunicarseadecuadamente con el MainFrame o sistema central.


33/125

- 33 -

El sistema aprovechara o explotara en la medida de lo posible la infraestructura para manejo deconcurrencia o paralelismo, as como balanceo de cargas. Como beneficio del performance de laaplicacin.

Facilitar el enlace y reglas de firewall, para nuevas empresas o call centers externos que pornecesidad del negocio necesiten conectarse al Host por este medio y aplicaciones.

Atributos del sistema.

Atributo Detalles

Tiempo de respuesta Meno al actual. Menor a 5 segundos por transaccin.

Uso de los estndares del Banco Manejo de Sockets TCP-IP, uso de protocolo PS9.

Seguridad Encripcin TDES y Base 64

Tolerancia a fallas La solucin contara con time outs mximos, en puntos

finales de Distribuido y host, para que en base a eso sedetermine acciones a seguir. En transacciones no criticas,como consultas, se permitir reenviar 2 o 3 intentos depeticin, en caso de no xito se dar por terminada lasolicitud informando del error retornado. En transaccionescrticas o contables solo se realizara un intento, en caso deerror o no respuesta se informara y se informara al cliente oasesor para que se tome a juicio la accin a seguir.

Plataforma Windows XP, 7. para el servicio en las PCs clientes

Windows Server. Para el servicio Proxy

SO-390, ASTA, CICS Bridge TCP-IP. En MainFrame.

Facilidad de enlace a entidades externas Contara con un modulo de Proxy que permita conectar a

cualquier entidad externa comunicarse o adaptarsefcilmente con el Banco.


34/125

- 34 -

6.2 Anlisis.

Casos de Uso.

Diagrama de casos de uso.

Modelo Conceptual inicial.


35/125

- 35 -

Casos esenciales de uso.

A continuacin se indica la clasificacin de los casos de uso identificados para el proyecto:

Casos primarios de uso.

Envi de mensajes

Casos secundarios de uso.

Servicio Proxy de envi de mensajes.

Casos opcionales de uso.

Encripcin de mensajes.


36/125

- 36 -

Caso de uso: Envi de mensajes.

Actores: IVR, CTI, Interfaz Grafica de usuario, Call Center Externo.

Propsito: recibir mensajes provenientes de alguna de las aplicaciones de Atencin Telefnica yenviar este va sockets al destino Host. Esperar la respuesta del Host y regresarla a la aplicacinorigen.

Descripcin: Alguna de las aplicaciones de Atencin Telefnica de una empresa Bancaria generaun mensaje de solicitud de informacin hacia el Host. El mensaje lo recibe el servicio decomunicacin tcp-ip, donde el mensaje es validado. Si esta activa la opcin de encripcin,entonces el mensaje es encriptado con la encripcin Tripe Des. El mensaje resultante es pasado ala codificacin de base 64. Posteriormente, el mensaje es armado a usar protocolo PS9. Elmensaje resultante es enviado por sockets al Host. En su defecto si el solicitante del mensaje esuna entidad externa (call center outsourcing) entonces el mensaje es pasado primero a servidorProxy, el cual tomara el mensaje y lo retransmitir al Host. El mensaje de respuesta es tratado a lainversa, esto es, se valida el mensaje de salida en PS9. Si esta activo el uso de criptografa, sevalida la salida y se quita la codificacin base 64, posterior se desencripta usando Tripe DES. Elmensaje resultante se retorna a la aplicacin solicitante original.

Tipo: Primario y esencial.Referencias cruzadas:

Funciones:

Casos de uso: el caso de uso envi de mensajes, usara el caso de uso encriptar mensaje,en caso necesario. Tambin si el call center es externo, se usara el caso de uso servicio Proxy.

Curso normal de los eventos.

Accin de los actores Respuesta del sistema

La aplicacin GUI/IVR/CTI enva la cadena de la solicitud alHost al servicio TCP-IP

Recibe el mensaje, realiza validaciones bsicas del formatode la cadena. Si esta correcta la cadena, y si esta activo laopcin de encripcin, entonces enva el mensaje al caso deuso encriptar. Si el mensaje fue encriptado correctamente osi el mensaje no necesito encripcin, entonces se formateael mensaje en protocolo PS9. El mensaje generado se envaal Host a travs de sockets TCP o si la aplicacin origen esentidad externa, entonces el mensaje es trasmitido tambinva sockets a servicio Proxy.

El servicio espera la respuesta, si se recibi el mensaje, sevalida. En caso de ser correcto, se deformatea quitandoPS9.

Si el mensaje esta encriptado se enva a caso de usoencripcin, del mensaje resultante se regresa a la aplicacinorigen.

LA aplicacin recibe el mensaje de respuesta, donde si larespuesta es correcta se visualiza. En caso de ser unmensaje de error, se muestra una descripcin adecuada alasesor o al cliente

Este mismo proceso se repite tantas veces comosolicitudes realice la aplicacin origen.


37/125


38/125

- 38 -

Caso de uso: Encripcin de mensajes.

Actores: Servicio envi de mensajes TCP-IP.

Propsito: recibir mensajes provenientes del servicio envi de mensajes TCP-IP, codificarlos enTripe DES y al resultado codificarlo a base 64.

Descripcin: recibir mensajes provenientes del servicio envi de mensajes TCP-IP y realizar lacodificacin del mensaje usando el cifrado Tripe DES. Si el resultado es correcto, el mensajeobtenido se procesa, convirtindolo a base 64. El mensaje resultante es retornado al servicio deenvi de mensajes TCP-IP que origino la solicitud

Tipo: Primario y esencial.

Referencias cruzadas:

Funciones:

Casos de uso: el mensaje recibido es originado por el caso de uso envi de mensajes.

Curso normal de los eventos.

Accin de los actores Respuesta del sistema

La aplicacin SDAT VB o Ncar enva la cadena de lasolicitud al Host al servicio TCP-IP

Recibe el mensaje, se enva el mensaje a caso de usoencripcin de mensajes.

El mensaje recibido se encripta usando Tripe Des. Elresultado se codifica en base 64. Se retorna el mensaje alservicio envi de mensajes.

El servicio de envi de mensaje continua el flujo detrasmisin va sockets

El mensaje se recibe del Host Si el mensaje es valido y en formato PS9, se deformatea.Del mensaje resultante, si esta encriptado, se enva adesencriptar. Este mensaje, se quita la codificacin Base 64,despus se desencripta usando Tripe DES.

El mensaje resultante se regresa al servicio de envi demensajes TCP-IP para que continu el flujo de respuesta.


39/125

- 39 -

Diagrama de Actividades.


40/125

- 40 -

6.3 Diseo.

Diagrama de secuencia del sistema.


41/125

- 41 -

Contratos de operaciones.

Sistema SICOTIP

envioMensaje(mensajeEntrada, tamaoEntrada, mensajeSalida, tamaoSalida)

asignaParametros(IP, Puerto, usoEncripcion)

generaSiguienteTrama(mensajeRespuesta)

Nombre: asignacionParamentros( IP:string, Puerto: entero, usoEncripcion: Boolean)

Responsabilidades: definir y/o inicializar los valores de los atributos: IP, puerto y usoEncripcion,para su posterior uso.

Tipo: Sistema.

Salida:

Precondiciones:

Se cuenta con los valores a asignar a los atributos de IP, Puerto y usoEncripcion.

Poscondiciones:

Se recibir el valor del atributo IP

Se asignara el valor del atributo Puerto

Se asignara el valor del atributo usoEncripcion.

Nombre: envioMensaje(mensajeEntrada, tamaoEntrada, mensajeSalida, tamaoSalida)

Responsabilidad: recibe el mensaje que se requiere enviar al sistema central Host. Si el atributo

usoEncripcion tiene valor Trae, entonces se encripta el mensaje. El mensaje encriptado o no seformatea en PS9 y se enva a Host usando sockets.

Tipo: Sistema.

Salida:

Precondiciones:


42/125

- 42 -

Se contara con el mensaje a enviar a Host, el cual tambin contara con los datosnecesarios para la solicitud de la informacin al rea central.

Poscondiciones:

Se creara la instancia de la clase sevicioTCP-IP.

Se recibir y validara el mensaje de entrada.

Si el atributo usoEncripcion ser con valor de verdad, entonces se creara instancia de laclase Cripto, y se relacionara a la instancia de la clase servicioTCP-IP.

Se enviara el mensaje encriptar(mensaje) a la instancia servicioTCP-IP.

Se creara la instancia de las clases TripeDes y Base64.

Se relacionara las instancias de las clases TripeDes y Base64 a la instancia de la claseCripto.

Se enviar mensaje generaCripto() a la instancia de la clase TripeDes.

Se enviar mensaje codificar() a la instancia de la clase Base64.

Se crear la instancia de la clase PS9. y se relacionara a la instancia de la claseservicioTCP-IP.

Se enviara mensaje armaEntrada(trama) a la clase PS9.

Se creara instancia de las clases MD, IH y ME. Se vinculara con la instancia de la clasePS9.

Se mandara mensaje genera(trama) a las instancias de las clases MD, IH y ME.

Se creara una instancia de la clase Thread. Para la generacin de un hilo de ejecucin. Se

relacionara a la clase servicioTCP-IP.

La instancia de la clase Thread creara una instancia de la clase Socket, y se vinculara a laprimera instancia mencionada.

Se enviara mensaje send(mensaje) a la instancia Socket para enviar la trama por el socketTCP al Host o al servicio Proxy.

Se esperara resultado del Socket por el mensaje recv().

El mensaje de respuesta se deformateara con la instancia de la clase PS9.

Si el mensaje es de topo encriptado. Se desencriptara el mensaje con la instancia de laclase Cripto.

El mensaje resultante se retornara a la instancia de la aplicacin origen.


43/125

- 43 -

Diagrama de clases.


44/125

- 44 -

Diagrama de interaccin.


45/125

- 45 -

Diagrama de componentes


46/125

- 46 -

6.4 Construccin.

Diagrama de Bloque correspondiente a la construccin del los dos mdulos del sistema SICOTIP.

CConexHost

WinSock

Ccliente::obj

cte

CBase64::objB

ase64

Csockbase

CServidor

IConexHost

TDESIVR

A licacin Conexion:


47/125

- 47 -

Debido a lo extenso de el cdigo fuente del sistema se incluye en el Anexo A.

CParametros

WinSock

Ccliente::objcte

CServerTCPDlgAutoProx

Csockbase

CServerTCPDlg

CServerTCPApp

CDialog

CWinApp

CCmdTarget CAboutDlg

CCServidor::servidor


48/125

- 48 -

6.5 Conclusiones y resultados.

Al finalizar la construccin de los dos mdulos que componen el proyecto, el modulo cliente y elservidor Proxy-TCP, se procedi a realizar pruebas individuales, despus pruebas nter sistemas.Posteriormente se realizaron pruebas de volumen en un ambiente de desarrollo ya comunicandolas aplicaciones distribuidas con el Host, se fueron presentando algunas incidencias pero se fueronresolviendo sin problema.

Para realizar la instalacin e implementacin de las aplicaciones en ambiente de produccin, serealizo de manera controlada sin presentar algn problema. Inicialmente se realizo un piloto,integrando sobre este esquema solo una clula, la cual consiste una agrupacin de 10 asesorestelefnicos, sin presentarse algn problema. Posteriormente de un perodo de prueba se fueronintegrando ms clulas, hasta integrar bajo este esquema dos centros de llamada (call centers)con 300 asesores aproximadamente.

As tambin, se realizo otro piloto para integrar la aplicacin cliente de conexin sockets, para un

IVR, y se fueron integrando mas, hasta integrar los 21 IVRs que se tienen en tres sites, donde cadaIVR cuenta con 90 puertos. Donde cada puerto es equivalente, a una lnea en la cual puede recibiruna llamada, por lo tanto, cada IVR puede recibir simultneamente 90 llamadas al mismo tiempo.

Despus de un par de meses de uso de la aplicacin, en el servidor Proxy, se detecto unaincidencia. La cual ocasionaba que se cruzara la informacin, en la retransmisin de la misma en larespuesta del Host al servidor Proxy y a su vez del servidor a las aplicaciones cliente donde semandaba la peticin original. Despus de un anlisis y la integracin de un log de operaciones deesta aplicacin, se detecto el problema y en esta ultima versin del cdigo, ya se cuenta con estaultima correccin. Donde hasta el momento se sigue trabajando sin problema con las aplicacionesque estn bajo este esquema.

En la parte del modulo de encripcin, solo se usa para las aplicaciones de Interfaz grafica (CallCenter) debido a que esta pendiente la integracin de este para los IVRs. Para esto, se esta

planeando realizar un piloto, con el fin de determinar el performance y poder medir el tiempo derespuesta, y saber que no afecte al tiempo actual de respuesta.

En el caso de que se tenga algn problema, o sea, que afecte al performance actual. Entonces, setendr que pensar en la alternativa de solucin, como puede ser el Cripto AES. Donde la idea, esde poder remplazar al de TDES, que en teora es mucho ms rapido y seguro. Se tendracontemplado desarrollar este modulo, en una siguiente etapa, como un proyecto adoptativoevolutivo, o sea integrando nueva funcionalidad al sistema actual.


49/125


50/125

- 50 -

Anexo A. Cdigo fuente.

Aplicacin Conexion:

// ConexHost.h : Declaration of the CConexHost

#ifndef__CONEXHOST_H_

#define__CONEXHOST_H_

#include"resource.h" // main symbols

/////////////////////////////////////////////////////////////////////////

////

// CConexHost

classATL_NO_VTABLE CConexHost :

publicCComObjectRootEx,

publicCComCoClass,

publicIConexHost

{

public:CConexHost()

{

}

DECLARE_REGISTRY_RESOURCEID(IDR_CONEXHOST)

DECLARE_PROTECT_FINAL_CONSTRUCT()

BEGIN_COM_MAP(CConexHost)

COM_INTERFACE_ENTRY(IConexHost)

END_COM_MAP()

// IConexHost

public:

BOOL InsertSubCadCadena(char*subcad, char*cadena, intposini, int

numcaract);

BOOL ObtenSubCadena(char*cadfuente, char*subcaddestino, int

posini, intnumcarateres);

intProcesaEncripcion(char* msgEntrada, char*MsgSalida, int

TipoSolicitud, int*TamSalida);

BOOL GeneraConsecutivoStr4(char*pcadCosecutivo, intpValorActual);

BOOL CountCadena1(char* cadfuente, int* numcarateres);

//STDMETHOD(EnviaMensajeHost)(/*[out,retval]*/ unsigned char*

nDato, unsigned char* ndirIP, int * nPuerto, int * lpnResultado);

STDMETHOD(EnviaMensajeHost)(/*[out,retval]*/unsignedchar* nDato,

unsignedchar* nSalida, int* nLonSal, unsignedchar* ndirIP, int*nPuerto, intnTipo, int* lpnResultado);

STDMETHOD(EnviaMsjHostEncripto)(/*[out,retval]*/unsignedchar*

nDato, unsignedchar* nSalida, int* nLonSal, unsignedchar* ndirIP, int

* nPuerto, intnTipo, int* lpnResultado);

STDMETHOD(ArmaEnvioMEPseudoConversSG_SC)(/*[out,retval]*/unsigned

char* nStrEntrada, unsignedchar* nStrSalidaME, int* nLongTrama, int*

lpnResultado);

STDMETHOD(CountCadena)(/*[out,retval]*/unsignedchar* cadfuente,

int* numcarateres, int* lpnResultado);


51/125

- 51 -

STDMETHOD(Cripto)(/*[out,retval]*/unsignedchar* nDato, unsigned

char* nSalida, int* TipoSolicitud, int*TamSalida, int* lpnResultado);

charmMensaje[32000];

};

#endif//__CONEXHOST_H_

// ConexHost.cpp : Implementation of CConexHost

#include"stdafx.h"

//#include

#include"socstr.h"

#include"Conexion.h"

#include"ConexHost.h"

#include"TDESIVR.h"

#include"Base64.h"

/////////////////////////////////////////////////////////////////////////

////

// CConexHost

//typedef ULONG (CALLBACK* LPFNDLLFUNC1)(char*, char*, int*, char*);

//typedef ULONG (CALLBACK* LPFNDLLFUNC1)(char*, char*, int*, char*);

STDMETHODIMP CConexHost::EnviaMensajeHost(unsignedchar* nDato, unsigned

char* nSalida, int* nLonSal, unsignedchar* ndirIP, int* nPuerto, int

nTipo, int*lpnResultado )

{

// Para Llamar la Dll

//HINSTANCE hDLL; // Handle to DLL

//LPFNDLLFUNC1 lpfnDllFunc1; // Function pointer

//DWORD dwParam1;

//UINT uParam2, uReturnVal;

//char MsgEnt[161], MsgSal[161];

//Implementacion de la conenexion a Host

intError=0;

intEnviados=0;

intRecibidos=0;

intLongitud=0;

intindice =0;

//int nSocketType = SOCK_STREAM,lintBub;

//DEFINICION DE IP Y PUERTO

LPCTSTR lpszSocketAddress = (char*)ndirIP; //DESARROLLO Y TEST

//LPCTSTR lpszSocketAddress = "150.50.102.15"; //DESARROLLO Y TEST

//LPCTSTR lpszSocketAddress = "150.100.246.44"; //PRODUCCION

//LPCTSTR lpszSocketAddress = "150.50.102.15"; //Desarrollo

UINT nSocketPort=*nPuerto;

//UINT nSocketPort=3550; //Produccion


52/125

- 52 -

//UINT nSocketPort=3555; //Produccion

//UINT nSocketPort=3224; //Test

//UINT nSocketPort=3216; //puerto Desarrollo

//char Mensaje[50000]="";

charMensajeRecib[32000]="";

char*pmensaje, *ptrRespuesta=MensajeRecib;

charNumSesion[9]="";

char*lMensajeEntrada=(char*)nDato;

char*lMensajeSalida=(char*)nSalida;

charMensajeError[100]="",lNumError[20]="";

pmensaje=lMensajeEntrada;

//AfxMessageBox(lMensajeEntrada,MB_YESNO);

strcpy((char*)nSalida,"");

WORD wVersionRequested;

WSADATA wsaData;

interr;

BOOL respuesta=false;

wVersionRequested = MAKEWORD( 2, 2 );

//BOOL AfxSocketInit( WSADATA* lpwsaData = NULL );

//respuesta= AfxSocketInit( &wsaData);

err = WSAStartup( wVersionRequested, &wsaData );if( err != 0 ) {

returnS_OK;

}

/* Confirm that the WinSock DLL supports 2.2.*/

/* Note that if the DLL supports versions greater */

/* than 2.2 in addition to 2.2, it will still return */

/* 2.2 in wVersion since that is the version we */

/* requested. */

if( LOBYTE( wsaData.wVersion ) != 2 ||

HIBYTE( wsaData.wVersion ) != 2 ) {

/* Tell the user that we could not find a usable *//* WinSock DLL. */

WSACleanup( );

returnS_OK;

}

//************************************

/* The WinSock DLL is acceptable. Proceed. */


53/125

- 53 -

//************************************

CCliente objcte(lpszSocketAddress,nSocketPort);

//************Validacion si uso de Encripcion******

charMsgSalCripto[32000]="", MsgSub1[32000]="",

MsgSub2[32000]="",strLongitud[10]="";intResultCripto=0, tamCripto=0,i=0, *ptrTamCripto=&tamCripto;

char*ptrSub2=MsgSub2;

chartmpcadena[10]="";

for( i=0; i


54/125

- 54 -

/*

ULONG uReturnVal=0;

//char MsgEnt[10000], MsgSal[10000], MngRetornado[32000],

Servicio[2];

char Servicio[2];char *ptrServ=Servicio;

int *ptrLMsg, LongMens, tamMsg=0, tamMsgSal=0, i=0;

char tmpcadena[10]="";

ptrLMsg=&LongMens;

strcpy(Servicio,"E");

LongMens=strlen(pmensaje);

uReturnVal= TDESCipher(pmensaje, MsgSalCripto, ptrLMsg, Servicio);

//Realiza la cuenta de caracteres diferentes de blanco y cadena

null

tamCripto=0;for(i=0;i


55/125

- 55 -

strcpy(strLongitud,tmpcadena );

}

else

if(strlen(strLongitud)==3)

{ strcpy(tmpcadena,"00");

strcat(tmpcadena,strLongitud);

strcpy(strLongitud,tmpcadena );}

else

if(strlen(strLongitud)==4)

{ strcpy(tmpcadena,"0");

strcat(tmpcadena,strLongitud);

strcpy(strLongitud,tmpcadena );

}

else

//if(strlen(strLongitud)>5)

{ strcpy(strLongitud,"00000");

//Error de longitud

}

InsertSubCadCadena(strLongitud, MsgSub1, 9, 5);

//_ultoa( tamCripto,tmpcadena, 10 );//AfxMessageBox(_T(strLongitud) ,MB_YESNO);

//AfxMessageBox(_T(MsgSub1) ,MB_YESNO);

//Envia Mensaje Ya encriptado

objcte.PedirServicio(MsgSub1,MsgSub2,&Longitud);

/*

Respuesta mensaje desencriptado:

Para reconocer que un mensaje viene desencriptado an este

parametrizado

como mensaje de entrada y salida encriptado, se va a reconocer

porque el

septimo caracter trae un 7 un 8. Ejemplos:"267000000009001630000 SESION ASIGNADA 00005 IDAGRD

"

"268000000009001633200 ERROR DE SESIONAMIENTO CON EL

OWNER 0000005 IDAGRD

"

*/

//Valida que la respueta este desencriptada y retorna el mensaje

//if( (MsgSub2[6]=='7') || (MsgSub2[6]=='8') || (MsgSub2[6]=='2'))

if( (*(MsgSub2+6)=='7') || (*(MsgSub2+6)=='8'))

{ //nDato=(unsigned char*) MsgSub1;

//nSalida=(unsigned char*) MsgSub1;Longitud=strlen(MsgSub2);

for( i=0; i


56/125

- 56 -

*nLonSal=Longitud;

//WSACleanup( );

returnS_OK;

}

//Desencripta Respuesta que si este encriptada

strcpy(MsgSalCripto,"");

strcpy(MsgSub1,"");

for(i=0;i


57/125

- 57 -

strcpy(strLongitud,"");

//_ultoa( tamCripto,strLongitud, 10 );

//AfxMessageBox(_T(strLongitud) ,MB_YESNO);

//nSalida=(unsigned char*) MsgSub1;

*nLonSal=Longitud;

}//************Fin ValidacionProceso de Encripcion**

//WSACleanup( );

returnS_OK;

}

STDMETHODIMP CConexHost::EnviaMsjHostEncripto(unsignedchar* nDato,

unsignedchar* nSalida, int* nLonSal, unsignedchar* ndirIP, int*

nPuerto, intnTipo, int*lpnResultado )

{

// Para Llamar la Dll//HINSTANCE hDLL; // Handle to DLL

//LPFNDLLFUNC1 lpfnDllFunc1; // Function pointer

//DWORD dwParam1;

//UINT uParam2, uReturnVal;

//char MsgEnt[161], MsgSal[161];

/*

hDLL = LoadLibrary("D:\\memo\\PruebasTCPIP\\Cripto\\TDESIVR");

if (hDLL != NULL)

{

lpfnDllFunc1 = (LPFNDLLFUNC1)GetProcAddress(hDLL,

"IVRCipher");

if (!lpfnDllFunc1){

// handle the error

FreeLibrary(hDLL);

return 0;

}

else

{

// call the function

uReturnVal = lpfnDllFunc1(MsgEnt, MsgSal,);

}

}

*/

//Implementacion de la conenexion a HostintError=0;

intEnviados=0;

intRecibidos=0;

intLongitud=0;

intindice =0;

//int nSocketType = SOCK_STREAM,lintBub;


58/125

- 58 -

//DEFINICION DE IP Y PUERTO

LPCTSTR lpszSocketAddress = (char*)ndirIP; //DESARROLLO Y TEST

//LPCTSTR lpszSocketAddress = "150.50.102.15"; //DESARROLLO Y TEST

//LPCTSTR lpszSocketAddress = "150.100.246.44"; //PRODUCCION

UINT nSocketPort=*nPuerto;

//UINT nSocketPort=3550; //Produccion//UINT nSocketPort=3555; //Produccion

//UINT nSocketPort=3224; //Test

//UINT nSocketPort=3216; //puerto Desarrollo

//LPCTSTR lpszSocketAddress = "150.50.102.15"; //Desarrollo

//char Mensaje[200]="1.0.000636

00030LOGNUSERGENE****IDAGRD GRD71026 00000000";

//char

Mensaje[2000]="1.0.000500X1X2X3X4X5X6X7X8X9X0X1X200600LOGNUSERGENE***

*UCQTLBMP 123456789012345678901234000000012006-02-

2010:00:00******************************";

charMensaje[50000]="";

charMensajeRecib[10000]="";char*pmensaje, *ptrRespuesta=MensajeRecib;

charNumSesion[9]="";

char*lMensajeEntrada=(char*)nDato;

char*ptrSalida=(char*)nSalida;

charMensajeError[100]="",lNumError[20]="";

//strcat(Mensaje,"

");

//pmensaje=Mensaje;


//*Para fines de prueba de base 64 y encripcion con triple Des

if(nTipo==1){

CBase64 objBase64;

//objBase64.encodeStr(pmensaje,MensajeRecib,2000);

objBase64.encodeStr(pmensaje,ptrSalida,2000);

AfxMessageBox(_T(pmensaje) ,MB_YESNO);

//AfxMessageBox(_T(ptrSalida) ,MB_YESNO);

FILE *stream;

charstrFileName[100]="Logb64.txt";

if( (stream = fopen(strFileName, "a+")) == NULL )

AfxMessageBox(_T("The file 'Logb64.txt' was not opened")

,MB_YESNO);

/*else

AfxMessageBox(_T("The file 'Logb64.txt' was opened") ,MB_YESNO);

*/fprintf( stream, "%s\n\t", pmensaje);

fprintf( stream, "%s\n\t", ptrSalida);

if( fclose( stream ) )

AfxMessageBox(_T("The file 'Logb64.txt' was not closed")

,MB_YESNO);

}


59/125


60/125

- 60 -

if( err != 0 ) {

/* Tell the user that we could not find a usable */

/* WinSock DLL. */

returnS_OK;

}

/* Confirm that the WinSock DLL supports 2.2.*/

/* Note that if the DLL supports versions greater *//* than 2.2 in addition to 2.2, it will still return */

/* 2.2 in wVersion since that is the version we */

/* requested. */

if( LOBYTE( wsaData.wVersion ) != 2 ||

HIBYTE( wsaData.wVersion ) != 2 ) {

/* Tell the user that we could not find a usable */

/* WinSock DLL. */

WSACleanup( );

returnS_OK;

}

/* The WinSock DLL is acceptable. Proceed. */

//CCliente objcte(lpszSocketAddress,nSocketPort);

//PRUEBA DE TRANSACCION SIN SESION.

//strcpy(Mensaje,"1.0.032584

00600****USERGENE****UCQTLBMP

x1x2x3x4x5x6x7x8x9x0x1x2000000012006-02-2010:00:00

26VMXBL01BL00B UCQTLBMP00000000T2J1

000063611OLBNE0557C

LINEABAN1111 TC5471550172331772

1234567890123456789012345678901234

123456789012345678901234567890

");

Longitud=strlen(lMensajeEntrada);objcte.PedirServicio(pmensaje,ptrRespuesta,&Longitud);

nDato=(unsignedchar*) lMensajeEntrada;

WSACleanup( );

returnS_OK;

}

STDMETHODIMP CConexHost::ArmaEnvioMEPseudoConversSG_SC(unsignedchar*

nStrEntrada, unsignedchar* nStrSalidaME, int*nLongTrama, int

*lpnResultado )

{

intError=0;

intEnviados=0;

intRecibidos=0;

intLongitud=0;

intind =0;


61/125

- 61 -

charMensaje[320000]="";

charCadComparar[10000]="";

char*pmensaje, *ptrmentmp=Mensaje;

char*ptrRespuesta=(char*)nStrSalidaME;

char*lMensajeEntrada=(char*)nStrEntrada;

charMensajeError[100]="",lNumError[20]="";char*strTagIniSG="";

char*strTagFinSG="";

char*strTagIniSC="";

char*strTagFinSC="";

charstrNextTrnId[9]="";

int iNextTrnId=0;

charstrAbsNumFirstLine[5]="";

int iAbsNumFirstLine=0;

charstrNumLines[5]="";

intinumLines=0;

charstrLinelength[5]="";

intiLinelength=0;

charstrIndWaySendTrn[2]="";

charstrTypeCopy[2]="";

charstrLenCopy[5]="";

charstrConsecutivo[5]="";

charstrTmp[20]="";

//strcat(Mensaje,"

");


strcpy(ptrRespuesta,"");

CountCadena(nStrEntrada,&Longitud, &Er

Teoria Altamira Cics

Documents

Transcript of Teoria Altamira Cics