Implementación y Evaluación Del Servicio PDF

UNIVERSIDAD NACIONAL DEL
CENTRO DEL PERU
FACULTAD DE INGENIERÍA DE SISTEMAS
TESIS
IMPLEMENTACIÓN Y EVALUACIÓN DEL SERVICIO DE

INTEGRACIÓN DE SISTEMAS EN LA AUTOMATIZACIÓN
DE PROCESOS EN APM TERMINALS CALLAO S.A.
PRESENTADA POR:
BELITO SUBILETE, Carmen

VELASQUEZ QUISPE, Lizbet Nataly
PARA OPTAR EL TÍTULO PROFESIONAL DE:
INGENIERA DE SISTEMAS
HUANCAYO – PERÚ
2014
ASESOR
DR. HECTOR HUAMÁN SAMANIEGO
ii
AGRADECIMIENTOS
Las más sinceras muestras de agradecimiento a todas las personas que hicieron
posible esta tesis:
A DIOS
Gracias a Dios por darme la vida y las fuerzas para concluir satisfactoriamente por estar
conmigo a cada momento y en cada paso.
A NUESTROS PADRES
Por su ejemplo, amor y aliento y para ser cada día mejor.
A NUESTRO ASESOR
Por su apoyo incondicional y por compartir desinteresadamente sus amplios conocimientos
y experiencia.
A NUESTROS MAESTROS DE LA FIS

A quienes les debemos gran parte de nuestro conocimiento, agradecer su paciencia y
enseñanza, preparándonos para un futuro competitivo.
A NUESTRO ALMA MATER

Por ser un refugio de enseñanzas y que permitió recibir las primeras semillas para nuestra
formación profesional.
iii
DEDICATORIA:
Dedicada a nuestros padres, que hicieron

todo en la vida para lograr nuestros objetivos,
por el aliento permanente y darnos el apoyo
cuando sentíamos que el camino se
terminaba. Realmente no hay palabras que
logren expresar nuestro agradecimiento
iv
RESUMEN
A continuación se presenta el siguiente trabajo de Tesis titulado: Implementación y

evaluación del servicio de integración de sistemas en la automatización de procesos
en APM Terminals Callao S.A, el mismo que surge debido a que los procesos de control de
accesos no se encuentran automatizados, presentándose incidencias por errores humanos
que llevan a tener un elevado número de quejas o reclamos. Así también los sistemas
involucrados no se encuentran integrados, y se han encontrado tres procesos que son críticos
como son el proceso de registro de horarios, control de asistencia y registro de choferes y
camiones, donde las actividades internas de cada proceso se realizaban manualmente.
Entonces se ha planteado el objetivo de determinar la influencia del servicio de integración
sobre la automatización de procesos, basándose en una investigación de tipo aplicada con un
nivel de investigación explicativa.
Es así que con la metodología de desarrollo de Sistemas y la herramienta tecnología BizTalk

Server 2013, se ha llegado a definir los requerimientos, diseñar en función al modelo de
integración de sistemas empresariales (EAI), desarrollar flujos de procesos e implementar un
servicio de integración de sistemas que está compuesto por cuatro interfaces que han
permitido comunicar a los sistemas Nombrada, Access Control System, Navis N4 y DBIS
COMMTRAC. Luego de las pruebas de calidad superadas se llegó a desplegar con éxito el
servicio de integración en el ambiente de producción, con una arquitectura escalable y
sostenible en el tiempo.
Finalmente, a través del uso de indicadores se logró determinar la influencia positiva del
servicio de integración sobre la automatización de los procesos, llegando a reducir la ejecución
de las actividades manuales en los procesos, y disminuyendo los reclamos por incidencias
debido a errores humanos en el registro de datos o envío de información. Por lo tanto se
demostró que la hipótesis planteada es válida, por lo cual se recomienda continuar
automatizando los procesos mediante la inclusión de interfaces en el servicio de integración
de sistemas.
C. Belito S. y L. Velasquez Q.
v
ABSTRACT
The following thesis work entitled occur: Implementation and evaluation of service systems
integration in process automation in APM Terminals Callao SA , it arises because the process
of access control are not automated, presenting human error incidents leading to having a high
number of complaints or grievances . Well as the systems involved are not integrated, and
found three processes are critical such as the registration process scheduling, assist control
and logs trucks and drivers, where the internal activities of each process is performed
manually. So has arisen in order to determine the influence of integration on service process
automation, based on an investigation of type applied with a level of explanatory research.
Thus the systems development methodology and BizTalk Server 2013, tool technology has
come to define requirements, design based on the model of enterprise systems integration
(EAI), developing process flows and implement service integration system which comprises
four interfaces that have allowed systems to communicate Nombrada, Access Control System,
DBIS COMMTRAC and Navis N4. After testing surpassed quality was reached successfully
deploy service integration in the production environment, with a scalable and sustainable
architecture in time.
Finally, through the use of indicators is able to determine the positive influence of service
integration on the automation of processes, leading to reduced performance of manual
activities in processes, and reducing claims for incidents due to human errors data record or
send information. Thus it was shown that the hypothesis is valid, so it is recommended to
continue automating processes by including service interfaces in systems integration.
vi
ÍNDICE
Pág.
ASESOR................................................................................................................................ ii
AGRADECIMIENTOS ............................................................................................................ iii
RESUMEN ............................................................................................................................. v
ABSTRACT .......................................................................................................................... vi
ÍNDICE ................................................................................................................................. vii
INTRODUCCIÓN ................................................................................................................... 1
CAPÍTULO I ........................................................................................................................... 3
GENERALIDADES ................................................................................................................ 3
1.1. PLANTEAMIENTO DEL PROBLEMA ...................................................................... 3
1.1.1. El crecimiento de una organización y su dependencia tecnológica. ......................... 3
1.1.2. APM Terminals en el Perú ...................................................................................... 5
1.1.3. Procesos involucrados en el control de accesos ...................................................... 8
1.1.3.1. Proceso de gestión de horarios de estibadores .................................................... 9
1.1.3.2. Proceso de control de asistencia de Estibadores ............................................... 10
1.1.3.3. Proceso de registro y control de choferes y camiones........................................ 11
1.1.4. Sistemas de información involucrados en APM Terminals .................................... 13
1.2. FORMULACIÓN DEL PROBLEMA ........................................................................ 14
1.3. OBJETIVOS DE LA INVESTIGACIÓN ................................................................... 14
1.3.1. Objetivo General .................................................................................................... 14
1.4. JUSTIFICACIÓN DEL PROYECTO ....................................................................... 14
1.4.1. Justificación Teórica ............................................................................................... 14
1.4.2. Justificación Metodológica ..................................................................................... 15
1.4.3. Justificación Práctica .............................................................................................. 15
1.5. HIPÓTESIS ............................................................................................................ 15
1.5.1. Hipótesis General................................................................................................... 15
1.5.2. Variables e Indicadores de las Hipótesis ................................................................ 15
1.6. METODOLOGÍA DE LA INVESTIGACIÓN............................................................. 16
1.6.1. Tipo de Investigación ............................................................................................. 16
1.6.2. Nivel de Investigación ............................................................................................ 17
1.6.3. Sistema de Referencia ........................................................................................... 17
CAPÍTULO II ........................................................................................................................ 18
MARCO DE REFERENCIA.................................................................................................. 18
2.1. ANTECEDENTES .................................................................................................. 19
2.2. MARCO TEÓRICO ................................................................................................ 23
2.2.1. Un modelo conceptual para la integración empresarial .......................................... 23
2.2.2. El enfoque de automatización e integración empresarial........................................ 27
2.2.3. Enterprise Application Integration (EAI) .................................................................. 28
2.2.3.1. Definición de la EAI ............................................................................................ 28
2.2.3.2. Objetivo de la EAI .............................................................................................. 29
2.2.3.3. Patrones de EAI ................................................................................................. 29
2.2.4. Microsoft Biztalk Server 2013 ................................................................................. 31
2.2.4.1. Mensajería de Biztalk ......................................................................................... 32
2.2.4.2. Orquestación ...................................................................................................... 37
2.3. MODELO APLICATIVO.......................................................................................... 43
2.3.1. Definición de requerimientos .................................................................................. 44
2.3.2. Análisis y diseño .................................................................................................... 46
2.3.3. Construcción .......................................................................................................... 47
2.3.4. Pruebas ................................................................................................................. 48
2.3.5. Producción y mantenimiento .................................................................................. 49
2.3.6. Miembros de un proyecto de sistemas ................................................................... 50
2.4. MARCO CONCEPTUAL ........................................................................................ 50
CAPÍTULO III ....................................................................................................................... 54
vii
INTERVENCIÓN METODOLÓGICA .................................................................................... 54
3.1. DEFINICIÓN DE REQUERIMIENTOS ................................................................... 54
3.1.1. Alcances del servicio .............................................................................................. 55
3.1.2. Definición requerimiento por interfaces .................................................................. 55
3.1.3. Relación de las necesidades identificadas con los requerimientos ......................... 58
3.2. ANÁLISIS Y DISEÑO ............................................................................................. 59
3.2.1. Análisis y diseño de procesos ................................................................................ 61
3.2.1.1. Proceso de registro de horarios ......................................................................... 61
3.2.1.2. Proceso de control de asistencia ........................................................................ 62
3.2.1.3. Proceso de registro de choferes y camiones ...................................................... 65
3.2.1.4. Flujo de la interfaz de horarios .......................................................................... 67
3.2.1.5. Flujo de la interfaz de asistencia ........................................................................ 70
3.2.1.6. Flujo de la interfaz de choferes .......................................................................... 72
3.2.1.7. Flujo de la interfaz de camiones ......................................................................... 74
3.2.2. ANÁLISIS Y DISEÑO DE DATOS .......................................................................... 77
3.2.2.1. Interfaz de horarios ............................................................................................ 77
3.2.2.2. Interfaz de asistencia ......................................................................................... 86
3.2.2.3. Interfaz de choferes ........................................................................................... 97
3.2.2.4. Interfaz de camiones ........................................................................................ 106
3.2.3. Análisis y diseño de la interfaz ............................................................................. 115
3.3. CONSTRUCCIÓN ................................................................................................ 120
3.3.1. Desarrollo de infraestructura ................................................................................ 121
3.3.2. Desarrollo de datos .............................................................................................. 121
3.3.3. Desarrollo de procesos ........................................................................................ 131
3.3.3.1. Desarrollo de la interfaz de horarios ................................................................. 131
3.3.3.2. Desarrollo de la interfaz de asistencia .............................................................. 135
3.3.3.3. Desarrollo de la interfaz de choferes ................................................................ 140
3.3.3.4. Desarrollo de la interfaz de camiones .............................................................. 144
3.3.4. Generando el instalador MSI ................................................................................ 151
3.4. PRUEBAS ............................................................................................................ 155
3.4.1. Interfaz Horarios................................................................................................... 155
3.4.2. Interfaz Asistencia ................................................................................................ 158
3.4.3. Interfaz Choferes.................................................................................................. 162
3.4.4. Interfaz Camiones ................................................................................................ 164
3.5. PRODUCCIÓN Y MANTENIMIENTO ................................................................... 167
3.5.1. Despliegue en producción .................................................................................... 167
3.5.2. Mantenimiento ..................................................................................................... 172
3.5.2.1. Diagnóstico de los servidores........................................................................... 173
3.5.2.2. Ejecución del mantenimiento............................................................................ 174
3.5.2.3. Documentos procesados por día ...................................................................... 176
3.5.2.4. Contador de rendimiento .................................................................................. 177
3.5.2.5. Resumen de mantenimiento del servidor de BizTalk ........................................ 177
CAPÍTULO IV .................................................................................................................... 179
EVALUACIÓN Y DISCUSIÓN DE RESULTADOS ............................................................. 179
4.1. PRESENTACIÓN DE RESULTADOS .................................................................. 179
4.1.1. Número de aplicativos o sistemas integrados ...................................................... 180
4.1.2. Capacitación para la administración del servicio .................................................. 180
4.1.3. Pruebas de certificación ....................................................................................... 181
4.1.4. Nivel de automatización de los procesos ............................................................. 182
4.2. EVALUACIÓN DE RESULTADOS Y PRUEBA DE HIPÓTESIS........................... 185
CONCLUSIONES .............................................................................................................. 188
RECOMENDACIONES ...................................................................................................... 189
ANEXOS ........................................................................................................................... 192
viii
ÍNDICE DE GRÁFICOS
Gráfico N° 1.1: Contenedores movilizados en el Puerto del Callao ........................................ 6
Gráfico N° 1.2: Estimación escenarios operaciones de importación (2009 – 2029) en
Toneladas Métricas................................................................................................................ 7
Gráfico N° 1.3: Estimación escenarios operaciones de exportaciones (2009 – 2029) en
Toneladas Métricas................................................................................................................ 8
Gráfico N° 1.4: Cuadro de reclamos I semestre - 2013 ........................................................ 10
Gráfico N° 1.5: Promedio de espera de Estibadores por turno - 2013 .................................. 11
Gráfico N° 1.6: Arquitectura de la situación actual de los sistemas ...................................... 14
Gráfico N° 2.1: Niveles de automatización e integración de software heterogéneo .............. 24
Gráfico N° 2.2: Motor de mensajería de BizTalk Server ....................................................... 31
Gráfico N° 2.3: Procesamiento de mensajes desde BizTalk ................................................ 33
Gráfico N° 2.4: Diseñador de Orquestación ......................................................................... 39
Gráfico N° 2.5: Esquema de la Metodología de Desarrollo de Sistemas .............................. 43
Gráfico N° 3.1: Mapeo del proceso de registro de horarios .................................................. 61
Gráfico N° 3.2: Mapeo de procesos del control de asistencia .............................................. 63
Gráfico N° 3.3: Mapeo de procesos del registro de choferes y camiones............................. 65
Gráfico N° 3.4: Flujo de proceso de la interfaz de Horarios. ................................................. 69
Gráfico N° 3.5:Flujo de proceso de la interfaz de Asistencia ................................................ 71
Gráfico N° 3.6:Flujo de proceso de la interfaz de Choferes .................................................. 73
Gráfico N° 3.7:Flujo de proceso de la interfaz de Camiones ................................................ 76
Gráfico N° 3.8: Flujo de la Interfaz de Horarios .................................................................. 117
Gráfico N° 3.9: Flujo de la Interfaz de Asistencia ............................................................... 118
Gráfico N° 3.10: Flujo de la Interfaz de Choferes ............................................................... 119
Gráfico N° 3.11: Flujo de la Interfaz de Camiones ............................................................. 120
Gráfico N° 3.12: Procedimiento Almacenado BTSPROCSELHOR001 ............................... 122
Gráfico N° 3.13: Procedimiento Almacenado BTSPROCUPDESTREG001 ....................... 123
Gráfico N° 3.14:Tabla Log_BTSNombradaACS ................................................................. 123
Gráfico N° 3.15: Método BadgeActivation del servicio web WebServiceNombrada ........... 124
Gráfico N° 3.16: Procedimiento Almacenado BTSPRCASTGET002 .................................. 124
Gráfico N° 3.17: Procedimiento Almacenado BTSPROCINSAST001 ................................ 125
Gráfico N° 3.18: Procedimiento almacenado BTSPRCASTUPD001 .................................. 125
Gráfico N° 3.19: Tabla Log_BTSACSaNombradaAsist ...................................................... 126
Gráfico N° 3.20: Método Report del servicio web WebServicePlanilla .............................. 126
Gráfico N° 3.21:Procedimiento almacenado BTSPRCDRIGET001 .................................... 127
Gráfico N° 3.22: Procedimiento almacenado BTSPRCDRIUPD001 ................................... 127
Gráfico N° 3.23: Tabla Log_BTSACSaN4CommtracDriver ................................................ 128
Gráfico N° 3.24:Método LastUpdated del servicio web WebServicesN4C.......................... 128
Gráfico N° 3.25: Procedimiento almacenado BTSPRCTRUGET001 .................................. 129
Gráfico N° 3.26: Procedimiento almacenado BTSPRCTRUUPD001 ................................. 129
Gráfico N° 3.27: Tabla Log_BTSACSaN4CommtracTrucks ............................................... 130
Gráfico N° 3.28: Método LastUpdated del servicio web WebServicesN4C......................... 130
Gráfico N° 3.29: Creación del proyecto BTSInterfazHorarios ............................................. 131
Gráfico N° 3.30: Esquema de la interfaz horarios .............................................................. 132
Gráfico N° 3.31: Mapa de la interfaz horarios .................................................................... 133
Gráfico N° 3.34: Creación del proyecto BTSInterfazAsistencia .......................................... 135
Gráfico N° 3.35: Esquema de la interfaz asistencia ........................................................... 136
Gráfico N° 3.36: Mapa de la interfaz asistencia.................................................................. 137
Gráfico N° 3.37: Configuración de scripting functoide ........................................................ 138
Gráfico N° 3.40: Creación del proyecto BTSInterfazDrivers ............................................... 140
ix
Gráfico N° 3.41: Creación del proyecto Btsprcdriget001Dri ................................................ 141
Gráfico N° 3.42: Mapa WsLastUpdated_Res_to_DriversDBIS ........................................... 142
Gráfico N° 3.43: Inicio de Orquestación Orch_InterfazDrivers.odx ..................................... 142
Gráfico N° 3.44: Orquestación de la interfaz de Choferes .................................................. 143
Gráfico N° 3.45: Pipeline SndDriN4snx .............................................................................. 143
Gráfico N° 3.46: Pipeline SndDriDBIScsv .......................................................................... 144
Gráfico N° 3.47: Creación del proyecto BTSInterfazTrucks ................................................ 145
Gráfico N° 3.48: Creación del proyecto BTSInterfazTrucks................................................ 146
Gráfico N° 3.49: Mapa de la interfaz de Camiones ............................................................ 147
Gráfico N° 3.50: Inicio de Orquestación Orch_InterfazTrucks.odx ..................................... 147
Gráfico N° 3.51: Orquestación de la interfaz de camiones ................................................. 148
Gráfico N° 3.52: Pipeline de la interfaz de Choferes .......................................................... 149
Gráfico N° 3.53: Pipeline de la interfaz de Choferes .......................................................... 149
Gráfico N° 3.54: Modelo correo con log de errores ............................................................ 150
Gráfico N° 3.55: Modelo correo con log de errores ............................................................ 150
Gráfico N° 3.56: Exportando la aplicación Asistencia ......................................................... 151
Gráfico N° 3.57: Ventana de Asistente de Exportación de archivos ................................... 152
Gráfico N° 3.58: Ventana de Seleccionar Recursos ........................................................... 152
Gráfico N° 3.59: Ventana de Dependencias....................................................................... 153
Gráfico N° 3.60: Ventana de Destino ................................................................................. 153
Gráfico N° 3.61: Ventana de Resumen .............................................................................. 154
Gráfico N° 3.62: Instalador de la interfaz asistencia ........................................................... 154
Gráfico N° 3.63: Valores de tabla boletanombradadetalle .................................................. 155
Gráfico N° 3.64: Información obtenida del sistema origen - Nombrada .............................. 156
Gráfico N° 3.65: Iniciando interfaz de Horarios .................................................................. 156
Gráfico N° 3.66: Iniciando componentes de la orquestación .............................................. 157
Gráfico N° 3.67: Estibadores autorizados para el ingreso .................................................. 157
Gráfico N° 3.68: Valores de tabla Events de la Base de Datos Access Control ................. 158
Gráfico N° 3.69: Valores de tabla BTSTBLPRCASIST001 ................................................. 158
Gráfico N° 3.70: Valores de tabla Events de la Base de Datos Access Control ................. 159
Gráfico N° 3.71: Inicio de la interfaz de Asistencia ............................................................. 159
Gráfico N° 3.72: Proceso de ejecución de la orquestación ................................................. 160
Gráfico N° 3.73: Datos de estibadores como respuesta del servicio web ........................... 160
Gráfico N° 3.74: nformación actualizada en el sistema Nombrada ..................................... 161
Gráfico N° 3.75: Información actualizada en el sistema Nombrada .................................... 161
Gráfico N° 3.76: Valores de tabla BTSTBLPRCDRI001 ..................................................... 162
Gráfico N° 3.77: Resultados del servicio web: Lista de choferes ........................................ 162
Gráfico N° 3.78: Archivo de salida Sistema DBIS COMMTRAC ......................................... 163
Gráfico N° 3.79:Archivo de salida Sistema DBIS COMMTRAC .......................................... 163
Gráfico N° 3.80: Valores actualizados en la tabla BTSTBLPRCDRI001 ............................. 164
Gráfico N° 3.81: Log de proceso en la tabla Log_BTSACSaN4CommtracDriver................ 164
Gráfico N° 3.82:Valores de tabla BTSTBLPRCTRU001 ..................................................... 164
Gráfico N° 3.83: Resultados del servicio web: Lista de camiones ...................................... 165
Gráfico N° 3.84: Archivo de salida Sistema Navis N4 ........................................................ 165
Gráfico N° 3.85: Archivo de salida Sistema DBIS COMMTRAC ......................................... 166
Gráfico N° 3.86: Valores actualizados en la tabla BTSTBLPRCDRI001 ............................. 166
Gráfico N° 3.87: Log de proceso en la tabla Log_BTSACSaN4CommtracTrucks .............. 166
Gráfico N° 3.88: Importación de MSI File ........................................................................... 167
Gráfico N° 3.89: Ventana Import MSI Wizard ..................................................................... 168
Gráfico N° 3.91: Ventana Import MSI Wizard - Asistencia .................................................. 169
Gráfico N° 3.92: Ventana Import MSI Wizard - Asistencia .................................................. 169
Gráfico N° 3.94: Interfaz de Asistencia en el ambiente de producción ............................... 170
Gráfico N° 3.95: Consola de Administración de Biztalk ...................................................... 171
x
Gráfico N° 3.96: Consola de Administración de Biztalk ...................................................... 171
Gráfico N° 3.97: Interfaces en ejecución ............................................................................ 172
Gráfico N° 3.98: Cantidad de trabajos realizados para el día 23/10/2013 .......................... 176
Gráfico N° 3.99: Cantidad de trabajos realizados para el día 24/10/2013 .......................... 176
Gráfico N° 3.100: Interfaz de Asistencia en el ambiente de producción ............................. 177
Gráfico N° 4.1: Numero de sistemas o aplicativos integrados ............................................ 180
Gráfico N° 4.2: Cantidad de personal capacitado............................................................... 181
Gráfico N° 4.3: Pruebas de certificación ............................................................................ 182
Gráfico N° 4.4: Nivel de automatización en los procesos de control de accesos ................ 184
Gráfico N° 4.5: Comparativo de registro de incidencias por error humano ......................... 186
Gráfico N° 4.6: Nivel de automatización en los procesos de control de accesos ................ 186
ÍNDICE DE TABLAS
Tabla N° 1.1: Turno diario de Estibadores - 2013 .................................................................. 9
Tabla N° 1.2: Tiempo de desembarque de las naves - 2013 ................................................ 12
Tabla N° 1.3: Variables e indicadores de la hipótesis .......................................................... 16
Tabla N° 3.1: Esquema de envío de datos ........................................................................... 56
Tabla N° 3.2: Esquema de envío de datos de asistencia ..................................................... 56
Tabla N° 3.3: Lista de requerimientos identificados ............................................................. 58
Tabla N° 3.4: Nivel de automatización del proceso de registro de horarios .......................... 62
Tabla N° 3.5: Nivel de automatización del proceso de control de accesos ........................... 64
Tabla N° 3.6: Nivel de automatización del proceso de registro de choferes y camiones ...... 66
Tabla N° 3.7: Los sistemas origen y destino de integración ................................................. 66
Tabla N° 3.8: Estados de envío de datos hacia sistema Nombrada ..................................... 67
Tabla N° 3.9: Campos contenidos en el mensaje Btsprocselhor001 .................................... 77
Tabla N° 3.10: Campos contenidos en el mensaje Btsprocupdestreg001 ............................ 78
Tabla N° 3.11: Campos contenidos en el mensaje BadgeActivation .................................... 79
Tabla N° 3.12: Campos contenidos en el mensaje Msg_Btsprcselhor001_Res_Intermedio . 80
Tabla N° 3.13: Campos contenidos en el mensaje InsertLog_BTSNombradaACSService ... 81
Tabla N° 3.14: Campos contenidos en el mensaje LogHora ................................................ 82
Tabla N° 3.15: Campos contenidos en el mensaje CorreoError ........................................... 82
Tabla N° 3.16: Mapa de transformación de Btsprocselhor001 a BadgeActivation ............... 83
Tabla N° 3.17: Mapa de transformación de Btsprocselhor001 a CorreoError ...................... 83
Tabla N° 3.18: Mapa de transformación de Btsprocselhor001 a LogHora ........................... 84
Tabla N° 3.19: Mapa de transformación de Btsprocselhor001, LogHora a
InsertLog_BTSNombradaACSService ................................................................................. 85
Tabla N° 3.20: Mapa de transformación de Msg_Btsprcselhor001_Res_Intermedio,
BadgeActivationResult a BTSPROCUPDESTREG001 ....................................................... 86
Tabla N° 3.21: Campos contenidos en el mensaje BTSPRCASTGET002 ........................... 87
Tabla N° 3.22: Campos contenidos en el mensaje Report ................................................... 88
Tabla N° 3.23: Campos contenidos en el mensaje AsistenciaIntermedio ............................. 89
Tabla N° 3.24: Campos contenidos en el mensaje AsistenciaIntermedioIni ......................... 89
Tabla N° 3.25: Campos contenidos en el mensaje BTSPROCINSAST001 .......................... 90
Tabla N° 3.26: Campos contenidos en el mensaje BTSPRCASTUPD001 ........................... 91
Tabla N° 3.27: Campos contenidos en el mensaje Log_BTSACSaNombradaAsist .............. 91
Tabla N° 3.28: Campos contenidos en el mensaje CorreoErrorAst ...................................... 92
Tabla N° 3.29: Campos contenidos en el mensaje LogAsistencia ........................................ 93
Tabla N° 3.30: AsistenciaIntermedioIni (BTS) a WebServicePlanilla-Report (ACS) ............. 93
Tabla N° 3.31: AsistenciaIntermedio(BTS) a BTSPROCINSAST001(Bd_Nombrada) .......... 94
Tabla N° 3.32: BTSPRCASTGET002 (Bd_MIDBiztalk) a CorreoErrorAst (BTS) .................. 94
Tabla N° 3.33: BTSPRCASTGET002 (Bd_MIDBiztalk) a LogAsistencia (BTS) .................... 95
Tabla N° 3.34: BTSPRCASTGET002 (Bd_MIDBiztalk) a BTSPRCASTUPD001
(Bd_MIDBiztalk) ................................................................................................................... 96
xi
Tabla N° 3.35: BTSPRCASTGET002 (Bd_MIDBiztalk), LogAsistencia(BTS) a
Log_BTSACSaNombradaAsist (BTS) .................................................................................. 96
Tabla N° 3.36: Campos contenidos en el mensaje BTSPRCDRIGET001 ............................ 97
Tabla N° 3.37: Campos contenidos en el mensaje BTSPRCDRIUPD001 ............................ 98
Tabla N° 3.38: Campos contenidos en el mensaje Log_BTSACSaN4CommtracDriver........ 98
Tabla N° 3.39: Campos contenidos en el mensaje WebServicesN4C. LastUpdate .............. 99
Tabla N° 3.40: Campos contenidos en el mensaje DriverDBIS .......................................... 100
Tabla N° 3.41: Campos contenidos en el mensaje DriverN4 .............................................. 101
Tabla N° 3.42: Campos contenidos en el mensaje CorreoError ......................................... 101
Tabla N° 3.43: Campos contenidos en el mensaje LogDriver ............................................ 102
Tabla N° 3.44: BTSPRCDRIGET001 (BTS) a WebServicesN4C - LastUpdate (ACS)........ 102
Tabla N° 3.45: BTSPRCDRIGET001 (BTS) a BTSPRCDRIUPD001 - (BTS) ..................... 103
Tabla N° 3.46: WebServicesN4C (ACS) a – DriverdN4_FECHA (N4) ................................ 103
Tabla N° 3.47: WebServicesN4C (ACS) a DriverdDBIS _FECHA (DBIS) ......................... 104
Tabla N° 3.48: BTSPRCDRIGET001 (BTS) a LogDriver (BTS) .......................................... 104
Tabla N° 3.49: Btsprcdriget001 (BTS), LogDriver (BTS) a Log_BTSACSaN4CommtracDriver
(BTS) ................................................................................................................................. 105
Tabla N° 3.50: BTSPRCDRIGET001 (BTS) a CorreoErrorDri (BTS) .................................. 105
Tabla N° 3.51: Campos contenidos en el mensaje Btsprctruget001 ................................... 106
Tabla N° 3.52: Campos contenidos en el mensaje Btsprctruupd001 .................................. 107
Tabla N° 3.53: Campos contenidos en el mensaje Log_BTSACSaN4CommtracTrucks .... 107
Tabla N° 3.54: Campos contenidos en el mensaje LastUpdate.......................................... 108
Tabla N° 3.55: Campos contenidos en el mensaje TruckDBIS_YYYY-MM-DDTHHMMSS-0500
.......................................................................................................................................... 109
Tabla N° 3.56: Campos contenidos en el mensaje TruckN4_YYYY-MM-DDTHHMMSS-0500
.......................................................................................................................................... 110
Tabla N° 3.57: Campos contenidos en el mensaje CorreoErrorTru .................................... 110
Tabla N° 3.58: Campos contenidos en el mensaje LogTruck ............................................. 111
Tabla N° 3.59: Mapa de transformación de Btsprctruget001 a LastUpdate ....................... 111
Tabla N° 3.60: Mapa de transformación de Btsprctruget001 a Btsprctruupd001 ............... 112
Tabla N° 3.61: Mapa de transformación de LastUpdate a TruckN4_Fecha (N4) ................ 112
Tabla N° 3.62: Mapa de transformación de LastUpdate a TruckDBIS_Fecha (DBIS)......... 113
Tabla N° 3.63: Mapa de transformación de Btsprctruget001 a LogTruck ........................... 114
Tabla N° 3.64: Mapa de transformación de Btsprctruget001, LogTruck a
Log_BTSACSaN4CommtracTrucks ................................................................................... 114
Tabla N° 3.65: Mapa de transformación de Btsprctruget001 a CorreoErrorTruck ............... 115
Tabla N° 3.66: Configuración del servidor de Base de Datos ............................................. 173
Tabla N° 3.67: Configuración del servidor de Aplicación .................................................... 174
Tabla N° 3.68: Configuración del servidor de Base de Datos ............................................. 174
Tabla N° 3.69: Configuración del host del servidor de Aplicación ...................................... 175
Tabla N° 3.70: Resumen del mantenimiento de los servidores del servicio de integración 177
Tabla N° 4.1: Nivel de automatización del proceso de registro de horarios ........................ 183
Tabla N° 4.2: Nivel de automatización del proceso de control de accesos ......................... 183
Tabla N° 4.3: Nivel de automatización del proceso de registro de choferes y camiones .... 184
Tabla N° 4.4: Comparativo de variables, antes y después ................................................. 185
xii
INTRODUCCIÓN
La integración de aplicaciones es un tema importante, debido a la proliferación de distintas

plataformas tecnológicas y al crecimiento en el desarrollo de sistemas, conllevando esto a que
las organizaciones incrementen la necesidad de automatizar sus operaciones y comunicar
dichos sistemas dentro de la empresa y luego extenderse a otras empresas.
La presente tesis titulada “Implementación y Evaluación del servicio de Integración de

Sistemas en la automatización de procesos en APM Terminals Callao S.A”, fue orientada a
darle énfasis a los problemas de comunicación entre los distintos sistemas informáticos de
uno de los terminales portuarios más importantes en el Perú.
El terminal portuario APM Terminals, posee una vasta zona de influencia conectado con la
zona industrial de la capital y el resto del país, por consiguiente es notable el crecimiento del
tráfico internacional y está provocando una fuerte presión en el terminal portuario ya que
requiere mayor velocidad de operación, tarifas competitivas y un mejor servicio; esto conlleva
a que la empresa portuaria invierta en infraestructura, así como la incorporación de
innovaciones tecnológicas que permitan hacer más productiva la infraestructura disponible,
por ello se optó por lograr un entorno de trabajo sistematizado mediante la integración de
sistemas para un óptimo intercambio de información, que es objeto de estudio y desarrollo en
este escrito.
El primer capítulo contempla el planteamiento del problema que describe la realidad actual y
se enfoca en la situación problemática. Los antecedentes y evidencias demuestran la
limitación que tiene APM Terminals en el intercambio de información entre los sistemas
existentes, generando demora e inconsistencia en algunos datos, esto propicia la definición
del objetivo para un posterior planteamiento de la hipótesis.
En el segundo capítulo se muestra el marco teórico referido a la Metodología de desarrollo de
Sistemas como la Metodología Estructurada, una de las metodologías propuestas por Llorens
1
Fabregas que permite desarrollar sistemas de información en las organizaciones a través de
sus cinco fases como requerimientos, análisis/diseño, construcción, pruebas y
producción/mantenimiento.
En el tercer capítulo contempla la Intervención Metodológica, se plantea la propuesta

metodológica derivado del enfoque de Desarrollo de Sistemas, mostrando el resultado
práctico de la aplicación.
En el cuarto y último capítulo se realiza la validación de la hipótesis y la presentación de los

resultados, a partir de las pruebas y puesta en producción de las aplicaciones desarrolladas
para los diversos sistemas a través de Biztalk Server.
Finalmente se plasma las conclusiones y recomendaciones suscitadas durante el desarrollo

e implementación de la tesis.
2
CAPÍTULO I
GENERALIDADES
El presente capítulo abordará el planteamiento del problema, con un breve análisis de la

relación TIC y crecimiento de la organización, así como la integración y comunicación de los
sistemas informáticos. Se realizará una descripción y análisis de los procesos involucrados
en la gestión de los recursos humanos en APM Terminals, dentro del sistema de referencia,
evidenciando y analizando los problemas suscitados en el proceso de control de accesos.
1.1. PLANTEAMIENTO DEL PROBLEMA

El papel de las TIC en la empresa, la constante evolución de la tecnología, junto a la
aparición de nuevas y más complejas formas de utilización de la misma y a la completa
interconexión de los sistemas, implica que las Tecnologías de la Información (TIC)
ofrecen extraordinarias oportunidades.
Los costes, riesgos y oportunidades hacen de las TIC un elemento estratégico para el
crecimiento, maduración y transformación de las organizaciones, además, las convierte
en factor de éxito y de supervivencia de la empresa.
Existe una corriente de pensamiento que considera las TIC como el principal impulsor
de la economía en el siglo XXI. Aunque esto puede ser objeto de debate, existe un
completo acuerdo en que las futuras necesidades de negocio y las ventajas competitivas
estarán soportadas por el uso intensivo de las TIC.
1.1.1. El crecimiento de una organización y su dependencia tecnológica.

En la actualidad muchas empresas no tienen un único sistema informático capaz
de dar solución a todos los procesos que en estas se encuentran, sino que existe
en su infraestructura tecnológica, variedad de estos sistemas informáticos,
respondiendo a diversas plataformas de desarrollo, distintos lenguajes y
arquitectura. La heterogeneidad de tecnologías, crean las llamadas “islas de
información” donde la comunicación entre estos sistemas informáticos es
insuficiente.
3
Esta situación provoca la fragmentación de los procesos de negocio en las
empresas, conllevando a que la información estratégica se encuentre dividida
por áreas o departamentos y no se tiene una mejor colaboración mutua y
coordinación entre las actividades o procesos que se pueden llevar a cabo con
más agilidad si estos sistemas informáticos se entendieran entre sí. Por eso, se
dice que no hay una integración única del negocio, las entidades con esta
característica en su negocio no son capaces de responder como un todo único y
se requiere de un mayor esfuerzo para lograrlo.
Dicho esto, se nota que la complejidad de las organizaciones es cada vez mayor,
porque se camina hacia un modelo de organización sin barreras que se
comunica a través de distintos canales de información y datos sobre un conjunto
heterogéneo de sistemas de información operacionales que deben permanecer
integrados para dar una respuesta conjunta a las demandas del negocio. No
obstante, cada departamento o equipo de trabajo debe evolucionar
tecnológicamente acorde a sus propias necesidades sin limitaciones impuestas
por la visión integrada de la organización. Los responsables de sistemas de
información deben asumir que es necesario mantener el compromiso de la
evolución tecnológica para el negocio y la integración de los sistemas.
La integración de la tecnología y las técnicas relacionadas con la información no
estructurada en los informes y los medios digitales, y los datos estructurados en
base de datos, se están convirtiendo en una parte importante en el ámbito de la
integración. Esto se debe a una variedad de factores, incluida la aparición de
XML como un formato de datos estándar.
La integración de software heterogéneo se origina en la gran diversidad de
productos de software que las empresas emplean para apoyar sus diferentes
procesos productivos. Muchos de estos productos provienen, por lo general, de
diversos proveedores y están basados en plataformas de hardware y software
diferentes o emplean modelos conceptuales incompatibles, por consiguiente no
tienen, la capacidad requerida para integrarse y aplicar la interoperabilidad.
La información y los datos son el corazón de cada proyecto de integración y
últimamente la integración se realiza sobre distintos tipos de intercambio de
datos y formatos diferentes. Entre los enfoques recientes que han emergido para
resolver el problema de integración de software se destacan la Integración de
Aplicaciones Empresariales - EAI (Linthicum, 2000; Zahavi, 2000) y las
arquitecturas de objetos distribuidos, tales como CORBA, Enterprise JavaBeans
y COM (Chauvet, 1997; Siegel, 2000, Monson, 2000), en este caso será
compatible.
4
1.1.2. APM Terminals en el Perú
APM Terminals opera una Red Global de Terminales en 34 países que ayuda a
brindar la infraestructura portuaria esencial para el transporte internacional y el
crecimiento económico global. La compañía es la división de operaciones
portuarias independiente del Grupo A.P. Moller-Maersk, la cual trabaja de cerca
con la comunidad internacional del transporte y los gobiernos nacionales para
reducir costos, brindar excelencia operativa y mejorar el acceso al mercado
mundial. Las modernas infraestructuras portuarias impulsan la competitividad de
los mercados locales, regionales e internacionales y el desarrollo económico.
El Puerto Multipropósito del Callao es la puerta de entrada al Perú, la cuarta
economía más grande de América del Sur. Ubicado a 15 kilómetros de la capital
de Lima, el puerto del Callao, además de ser el puerto más grande del Perú, es
el más grande de la costa del Pacífico sudamericano.
En abril del 2011 APM Terminals adjudica la concesión del Terminal Norte
Multipropósito del Terminal Portuario del Callao en Perú, inicia sus operaciones
como APM Terminals Callao en julio del mismo año. APM Terminals es socio
mayoritario del terminal junto con Callao Port Holdings B.V. y la peruana Central
Portuaria. APM Terminals es un terminal marítimo diseñado para el manejo de
carga contenedorizada y carga general como: metales, granos, fertilizantes y
químicos, carbón, vegetales, aceite de pescado, maquinarias, entre otros.
Además de operar en infraestructuras ya existentes, APM Terminals tiene
proyectos de modernización que convertirán a APM Terminals Callao en un
puerto modelo para la industria portuaria de Sudamérica. La ubicación
estratégica del terminal junto con la modernización de sus instalaciones,
beneficiarán directamente a su cartera de clientes.
Es así que del total de movimientos de contenedores de nuestro país, el Callao
maneja el 90% a través de sus terminales Norte y Sur; el primero a cargo de
APM Terminals y el segundo de DP World”.1
Se agrega que este último es el que tiene mayor especialización en el manejo
de este tipo de carga unitarizada, contando con seis grúas pórtico y 18 grúas de
patio o RTG. Ambos terminales tienen entre sus planes de expansión
incrementar la capacidad de manejo de carga, pero esto se daría a partir del
presente año.
El Centro de Comercio Exterior (CCEX) de la Cámara de Comercio afirmó que
de continuar con el ritmo actual, para el 2015 el puerto del Callao alcanzará su
1 Cámara de Comercio Exterior. El puerto del Callao en riesgo desde el 2015. Lima. 2013
5
máxima capacidad de movimiento de contenedores (TEU) al sobrepasar los 2
millones de unidades, generando a partir de entonces un gran cuello de botella
para nuestro comercio exterior.
En paralelo, las exportaciones continuarían incrementándose aproximadamente

en un 40%2 a comparación de los años anteriores, llevando al puerto del Callao
a una situación límite. La CCEX afirmó que la realidad de nuestro principal puerto
aún está lejos de responder adecuadamente a las necesidades de un puerto
moderno y competitivo, y de convertirse en el hub que todos esperamos para
constituirse en la plataforma logística más importante de la costa oeste de
Sudamérica.
Desde hace cinco años, cuando el comercio exterior del país emprendió vuelo,
se sufren cuellos de botella preocupantes, y el principal problema es la
congestión de las vías de acceso al puerto del Callao, la puerta de ingreso y
salida del 85% de la carga que moviliza el Perú. El siguiente diagrama muestra
la evolución que ha tenido el puerto respecto a la movilización de contenedores.
Gráfico N° 1.1:
Contenedores movilizados en el Puerto del Callao
2500000
2000000
1500000
2000
2012
1000000
2015
500000
0
N° Contenedores
Fuente: Cámara de Comercio Exterior.

Elaboración: Propia
Del gráfico anterior se muestra que en el año 2000, el Callao movilizó 400 mil
contenedores aproximadamente; en el año 2012 llegó a 1,8 millones y se
proyecta que para el siguiente año supere los 2 millones. Y si bien el puerto tiene
compromisos de inversión por casi US$1.000 millones para su ampliación y
2 ASMARPE: Asociación Marítima del Perú – VUCE Avances y nuevos RETOS 2013
6
modernización, no existen desembolsos en la parte externa que acompañen este
crecimiento.3
Así también se han realizado estudios de la demanda de uso del terminal
portuario, donde la Fundación Valenciaport realizó proyecciones de la carga en
toneladas métricas, tanto para las exportaciones, como para las importaciones.
Gráfico N° 1.2:
Estimación escenarios operaciones de importación (2009 – 2029) en
Toneladas Métricas.
Fuente: Fundación Valenciaport

Elaboración: Fundación Valenciaport.
La creciente demanda para el uso del servicio de descarga de las importaciones

en el terminal portuario es creciente, aún en un escenario pesimista, observando
que en el año 2029, la cantidad de toneladas métricas casi se duplicarán
respecto al presente año.
En el caso de la demanda de carga de exportaciones se representa en el gráfico
N° 1.3.
3 Diario el comercio. ¿En realidad el puerto del Callao es el ‘hub’ de la región? Lima.2013
7
Gráfico N° 1.3:
Estimación escenarios operaciones de exportaciones (2009 – 2029) en
Toneladas Métricas.
Fuente: Fundación Valenciaport.

Elaboración: Fundación Valenciaport.
De lo anterior se visualiza que la estimación de las exportaciones en toneladas

métricas va en crecimiento, lo que indica que es urgente la mejora de las
instalaciones existentes y construcción de nuevos puestos de atraque, y áreas
de almacenamiento, conjuntamente con la automatización de los procesos para
satisfacer la creciente demanda que se refleja en los pronósticos.
En vista de la congestión de las vías de acceso al terminal y la demanda
creciente, APM trabaja en tres turnos, las 24 horas del día en la carga y descarga
de contenedores y carga general con el apoyo de grúas, maquinaria y personal
humano (estibadores).
El personal que labora en el puerto, camiones de carga, camionetas u otros tipos
de vehículos deben estar debidamente registrados y con la documentación al
día para poder ingresar al puerto. Es así que se presentan procesos críticos en
el área de control de accesos y seguridad de APM, en vista de que los procesos
no se encuentran automatizados y algunos procesos se realizan de forma
manual.
1.1.3. Procesos involucrados en el control de accesos

El crecimiento de APM Terminals, la incorporación de nuevas aplicaciones, las
operaciones y la consolidación de procesos productivos, requieren controles
sobre los procesos de interfaces entre los distintos sistemas, como es el caso
8
del proceso de control de accesos, a continuación se describe la situación actual
de los cuatro sub-procesos que están contenidos en este proceso:
1.1.3.1. Proceso de gestión de horarios de estibadores

El terminal portuario APM Terminals cuenta con un grupo de estibadores,
quienes laboran en determinados días, turnos y horarios. Para dar inicio
a este proceso las empresas de administración de recursos humanos de
estibadores presentan la relación de su personal y el rol de servicio, esto
se realiza enviando un correo de solicitud de ingreso indicando los días a
laborar y el tipo de trabajo a realizar a la oficina de control de acceso para
su autorización. El correo es enviado con 48 horas de anticipación con la
relación del personal autorizado que ingresará a laborar a APM
Terminals.
Luego se ingresa la relación de datos de los estibadores en el sistema
Nombrada, incluyendo el día, fecha y hora de ingreso.
La información de los horarios se transfiere de forma directa al personal
de seguridad de turno, enviándole cuadros de Excel impresos o a través
del correo corporativo.
La asignación de los horarios se realiza manualmente, en la tabla N° 1.1
se muestra la cantidad de estibadores que deben ingresar por turnos.
Tabla N° 1.1:
Turno diario de Estibadores - 2013
Turno Horario Cantidad de
estibadores por turno
1 7:00 A.M. – 3:00 P.M. 150 estibadores
2 3:00 P.M. – 11:00 P.M. 150 estibadores
3 11:00 P.M. – 7:00 A.M. 150 estibadores
Fuente: APM Terminals – Área de RR.HH.

De la tabla mostrada se detalla que en APM Terminals se manejan tres

horarios, las 24 horas del día, los 7 días de la semana y los 365 días del
año, lo que indica la importancia de mantener la disponibilidad de cada
recurso y soporte en sus procesos.
En este proceso diario de asignación de horarios, se presentaron ciertas
inconsistencias, generando la incomodidad de los trabajadores y del
mismo personal administrativo de APM Terminals y el personal de
seguridad, lo cual se refleja en números mediante el gráfico N° 1.4.
9
Gráfico N° 1.4:
Cuadro de reclamos I semestre - 2013
Reclamos en el proceso de gestión de

horarios
12
Cantidad de Reclamos
10 Inconsistencia de
horario
8
6 Pérdida de
4 relación de
trabajadores
2
0
Enero Febrero Marzo Abril Mayo Junio
2013 2013 2013 2013 2013 2013
Fuente: APM Terminals – Oficina de reclamos de trabajadores portuarios

En el gráfico mostrado, según fuentes de la oficina de reclamos se

muestra la cantidad de reclamos que fueron registrados durante el primer
semestre del año 2013, donde se puede observar que la cantidad de
registros llegan a diez reclamos por mes, siendo esta una cifra alarmante
ya que la labor que se desempeña en un puerto marítimo como se
describe líneas arriba es exhaustivo y permanente, donde no hay lugar
para errores o fallas de diversos tipos, debido a que esto genera pérdidas
económicas y deficiencia en la confiabilidad del terminal portuario.
1.1.3.2. Proceso de control de asistencia de Estibadores

El control de asistencia se da en dos puertas de ingreso, para lo cual cada
estibador debe portar su documento de identidad (DNI) y tiene que estar
en la lista enviada para la asignación de horarios. El personal de
seguridad es quien realiza el control en las puertas de ingreso, validando
la identidad del estibador. Este procedimiento se realiza para 150
personas por cada turno de forma diaria, provocando cierto desorden al
generarse colas y sobretodo demoras para el inicio de las labores del
estibador, en la tabla N° 2.1 se visualiza el promedio de espera de un
estibador para ingresar al puerto durante los primeros siete meses del
año 2013 .
10
Gráfico N° 1.5:
Promedio de espera de Estibadores por turno - 2013
Fuente: APM Terminals – Área de Accesos y Seguridad.

En el gráfico mostrado se da referencia al tiempo donde los estibadores

se encuentran en cola de espera para su ingreso al puerto, sobre todo en
los turnos de día, ya que el tiempo promedio de espera era de 32 minutos
durante el periodo de enero a julio del 2013, cabe resaltar que en el primer
turno de la mañana se presenta más demora en comparación a los otros
turnos, esto debido a que se tiene que controlar además el ingreso al
puerto de trabajadores administrativos, proveedores o terceros que
ingresan ocasionalmente. Por otro lado, no se lleva un control de la salida
de los estibadores, es así que en muchas ocasiones se asume que el
estibador completó sus horas de trabajo, pudiendo no ser así.
1.1.3.3. Proceso de registro y control de choferes y camiones

El traslado de los productos de importación o exportación es un aspecto
importante en el proceso de embarque y desembarque, por esa razón
APM Terminals cuenta con dos sistemas (N4 NAVIS y DBIS
COMMTRAC) que tienen como funcionalidad administrar la información
registrada de los camiones y choferes que ingresan al puerto.
Para el caso del desembarque, el proceso de registro y control de
choferes se da inicio cuando el usuario envía 48 horas antes del
desembarque los datos del chofer y del camión que ingresará al puerto
para realizar la tarea de traslado de carga (general o contenedor), el
registro de la información es de forma manual en el sistema N4 NAVIS y
DBIS COMMTRAC, realizando antes los controles pertinentes.
11
Para los permisos de ingreso de los camiones y choferes, deben ingresar
con sus pases TIP y TIV permanentes o la carta asignada por la oficina
de control de acceso portando su guía de embarque o salida de la
mercadería y su SCTR en salud y pensión vigentes. Asimismo cuando
solicita el apoyo de otra empresa se tiene que enviar un correo a la oficina
de control de accesos indicando el motivo, los nombres, el N° de pase
TIP, N° DNI de los choferes, placa de los vehículos y N° de pase (TIV) de
cada chofer, y los días a laborar, donde la documentación de cada camión
debe estar al día, así como el SOAT. El correo deberá ser enviado a la
oficina de control de acceso con 48 horas de anticipación del personal
autorizado con los e-mail correspondiente (Gerente General,
Representante Legal, Gerente de Operaciones y dos personas más que
designaron en la cartilla de firma virtual).
En la siguiente tabla se visualiza la demora al desembarque de las naves
que arriban al puerto del Callao.
Tabla N° 1.2:
Tiempo de desembarque de las naves - 2013
Nombre de Naves Fecha de arribo Fecha de desembarque
BBC BELEM 15/01/2013 23:00 18/01/2013 23:00
WEHR KOBLENZ 18/01/2013 07:00 21/01/2013 23:00
BBC GERMANY 21/01/2013 23:00 25/01/2013 23:00
OSLO BULK 2 24/01/2013 15:00 27/01/2013 07:00
SEABOARD CHILE 05/02/2013 15:00 09/02/2013 15:00
EM HYDRA 11/02/2013 07:00 14/02/2013 15:00
MSC FEDERICA 13/02/2013 07:00 16/02/2013 23:00
MSC FABIANE 24/02/2013 23:00 27/02/2013 15:00
MSC MYKONOS 06/04/2013 15:00 09/04/2013 07:00
MSC ROSARIA 17/04/2013 23:00 21/04/2013 15:00
COSCO FUKUYAMA 15/05/2013 07:00 19/05/2013 23:00
RHL AGILITAS 22/05/2013 15:00 26/05/2013 07:00
COSCO TIANJIN 27/05/2013 07:00 30/05/2013 23:00
Fuente: APM Terminals Callao S.A.
Se puede observar que las naves que arriban al puerto del Callao,
generan tiempo de espera de hasta 3 a 4 días por cada nave, uno de los
motivos para este tiempo de espera se debe a que los choferes y
camiones no tienen la autorización para su ingreso a APM Terminals, el
proceso de autorización y registro de datos de choferes y camiones,
puede tomar más de 48 horas. Este tiempo de desembarque es de suma
12
importancia, siento necesaria para la confiabilidad de los usuarios al
terminal portuario.
Como información adicional, el personal de APM Terminals indicó que
existen desembarques que se deben realizar de manera inmediata, pero
como el proceso de registros toma tiempo, se dificulta la atención a este
tipo de solicitudes.
Actualmente no existe una solución para la integración de los diversos
sistemas que permita implementar nuevos procesos o modificar procesos
de interfaces de manera rápida, ordenada y documentada.
1.1.4. Sistemas de información involucrados en APM Terminals

APM Terminals como operador marítimo soporta sus operaciones de negocios
en diferentes sistemas informáticos y aplicaciones, se describe a continuación
los sistemas involucrados en el registro y control de accesos al puerto:
 Access Control System LENEL On Guard (ACS): Aplicación de control de

acceso en donde se almacenan toda la información requerida para permitir
el ingreso de trabajadores de APM Terminals, estibadores, choferes y
camiones, a los diversos accesos con que cuenta el terminal marítimo.
 Terminal Operating System N4 NAVIS: Aplicación que gestiona el manejo
de la carga de contenedores del terminal, cuenta con información de choferes
y camiones, datos que son requeridos para el ingreso de estos a través de
las balanzas del terminal.
 Terminal Operating System DBIS COMMTRAC: aplicación que gestiona el
manejo de la carga general del terminal, cuenta con información de choferes
y camiones, datos que son requeridos para el ingreso de estos a través de
las balanzas.
 NOMBRADA: Aplicación que gestiona y define las cuadrillas de estibadores
que ingresan en un determinado horario al puerto para realizar las labores de
estiba en las diversas naves y muelles del terminal.
El sistema ACS (Access Control System) se encuentra en implementación, y

los sistemas conviven aislados debido a que no cuentan con un servicio de
integración de sistemas, sin comunicación controlable y gestionable, inhibiendo
el crecimiento y con riesgo de perder la sostenibilidad en el tiempo. Como se
puede apreciar en el gráfico siguiente:
13
Gráfico N° 1.6:
Arquitectura de la situación actual de los sistemas
Arquitectura de Integración de la situación actual
ACCESS
CONTROL N4 NAVIS
SYSTEM
COMMTRAC NOMBRADA
Fuente: Documento del set de aplicaciones de APM Terminals

Del gráfico anterior se observa que se cuenta con cuatro (4) sistemas, donde
una se encuentra en proceso de implementación, los cuales trabajan
independientemente. Los datos se manejan en bases de datos con modelos
estructurados y con el motor en Microsoft SQL Server 2008.
1.2. FORMULACIÓN DEL PROBLEMA

 ¿Cómo influye el servicio de integración de sistemas en la automatización de
procesos en el control de acceso a APM Terminals Callao S.A.?
1.3. OBJETIVOS DE LA INVESTIGACIÓN

1.3.1. Objetivo General
 Determinar la influencia del servicio de integración de sistemas en la
automatización de procesos en el control de acceso a APM Terminals Callao
S.A.
1.4. JUSTIFICACIÓN DEL PROYECTO

1.4.1. Justificación Teórica
El desarrollo de la investigación pretende sugerir el estudio de integración de
aplicaciones por medio de la metodología estructurada de desarrollo de
sistemas, que permite abordar los proyectos de esta índole, de tal manera que
14
se realiza una investigación de la situación problemática inicialmente para así
encontrar un solución adecuada acorde a las necesidades del usuario.
1.4.2. Justificación Metodológica

La metodología estructurada de desarrollo de sistemas presenta una estructura
secuencial que aborda proyectos de sistemas de manera organizada,
empezando por levantar la información, diseñar la solución, alineación de los
procesos en el desarrollo y la implementación. Asimismo se retroalimenta en
base a la evaluación y monitoreo de los procesos, para luego realizar controles
de cambio, con la finalidad de elevar la eficiencia y lograr la satisfacción de los
usuarios. Para la implementación de integración de sistemas (middleware) se
hará uso de herramientas tecnológicas propias para este tipo de requerimientos.
1.4.3. Justificación Práctica
La investigación e implementación de la solución permitirá automatizar los
procesos de asignación de horarios, registro de asistencia, camiones y choferes
mediante la integración de los sistemas involucrados, dado que la información
será transmitida de forma automática y a demanda; y los procesos pueden ser
administrados conforme a los requerimientos y a las reglas de negocio en APM
Terminals, esto contribuirá a reducir los errores en el registro de datos,
disminuirá el ciclo en cada proceso y la información que se manejará será única
en los sistemas involucrados.
1.5. HIPÓTESIS
1.5.1. Hipótesis General
La implementación del servicio de integración de sistemas influye directa y
positivamente en la automatización de los procesos de control de accesos en
APM Terminals Callao S.A.
1.5.2. Variables e Indicadores de las Hipótesis

Hipótesis General: Y =  (X)
Variable Independiente:
X = La implementación del servicio de integración de sistemas.
Variable Dependiente:
Y = La automatización de los procesos de control de accesos en APM.
15
Tabla N° 1.3:
Variables e indicadores de la hipótesis
Unidad de Instrumento de Fuentes de

Variables Definición Indicador evaluación
medida verificación
VARIABLE INDEPENDIENTE
Cantidad de Documento de
Número de interfaces pase a
aplicativos o Aplicativo o desplegadas en producción
sistemas sistemas producción aprobado.
Servicios que
integrados
permiten
integrar los
Servicio de Capacitación Registro de
aplicativos para
integración de acerca de la Horas de Pruebas de trabajadores
automatizar los
sistemas. administración del capacitación entrada y salida capacitados
procesos de
servicio
control de
accesos.
Pruebas de Cantidad de Porcentaje de Informe de
certificación pruebas casos probados pruebas
certificadas con éxito.
VARIABLE DEPENDIENTE
Evaluación y
Nivel de Porcentaje de Cantidad de análisis
automatización de subprocesos subprocesos realizado
Automatización los procesos. ejecutados por un ejecutados por sobre los
Se refiere a la
de los procesos sistema. un sistema. procesos.
transferencia de
de control de
información
accesos en Incidencias Cantidad Conteo de
entre los
APM. ocurridas por incidencias por reclamos Registro de
sistemas
errores humanos errores humanos ocurridos en las reclamos
ocurridos dentro de puertas de recibidos del
la ejecución de los acceso al área de
procesos de control puerto. control de
de accesos. accesos y
seguridad.
Fuente: Documentación del proyecto de integración en APM Terminals

1.6. METODOLOGÍA DE LA INVESTIGACIÓN

1.6.1. Tipo de investigación
Se trata de la investigación aplicada o empírica, partiendo de la forma de conocer
la realidad, teniendo como objetivo dar solución a los problemas suscitados e
identificados en APM Terminals, además este tipo de investigación se presta
para hallar una consecuencia práctica de los resultados obtenidos ya que se
pretende generar una nueva arquitectura de sistemas con la implementación del
servicio de integración y monitoreo, de tal manera que pueda ser optimizado
mediante los controles de cambio.
Se puede decir que este tipo de investigación es vista como un proceso
investigativo científico, serio y riguroso y como una forma necesaria y óptima
para conocer las realidades partiendo desde la misma evidencia y con el fin de
dar solución a los problemas identificados.
16
1.6.2. Nivel de investigación
La investigación es de nivel explicativa dado que pretende ocuparse de la
relación causa-efecto para obtener un resultado mediante la prueba de hipótesis.
Este nivel de investigación busca mostrar aspectos de la realidad analizando la
situación para así determinar el efecto de la implementación del servicio de
integración, como parte del cambio de arquitectura y la influencia en la
automatización de los procesos involucrados.
1.6.3. Sistema de referencia

El sistema de referencia es el ámbito que abarca esta investigación, esto
comprende un enfoque completo al área de control de accesos, que dentro de
ella contiene cuatro subprocesos que son: registro de horario de estibadores, el
control de accesos para choferes, camiones y estibadores al puerto del Callao.
Estos procesos vienen siendo soportados por los siguientes sistemas de
información: Nombrada, Access Control System, NAVIS N4 y DBIS Commtrac,
así como también los usuarios y administradores de las aplicaciones
mencionadas.
Se realizará un análisis de la situación actual del sistema de referencia para
poder hacer un comparativo en base a lo que se va cambiar y obtener un
resultado final.
Este capítulo se concentra esencialmente en describir y plantear el problema, así como

mostrar la presencia de la tecnología en el desarrollo y crecimiento de una organización.
Es esencial que una organización se encuentre preparada para mantener un crecimiento
sostenible con el soporte de los sistemas de información, en tal sentido la implementación de
un servicio de integración de aplicación para APM Terminals es determinante en la
automatización de procesos de registro y control de sus recursos.
17
CAPÍTULO II
MARCO DE REFERENCIA
Uno de los retos que enfrentan las organizaciones modernas es darles a sus empleados
información completa en tiempo real. Muchas de las aplicaciones en uso actualmente se
apoyan en tecnologías antiguas, por lo cual esos sistemas enfrentan dificultades a la hora de
transferir esta información entre las aplicaciones. Esa falta de comunicación conduce a
ineficiencias, en el que los mismos datos se almacenan en varias ubicaciones, o procesos
sencillos no pueden ser automatizados.
El proceso de conectar las aplicaciones unas para intercambiar información operativa o

financiera es denominada EAI (Enterprise Application Integration), cuando dichos sistemas no
pueden compartir su información efectivamente, se crean cuellos de botella que requieren de
la intervención humana en la forma de toma de decisiones o en el ingreso mismo de la
información, para evitar este tipo de inconvenientes.
La integración de aplicaciones empresariales es el proceso de vinculación de este tipo de

sistemas de información dentro de una sola organización en conjunto con el fin de simplificar
y automatizar los procesos de negocio en la mayor medida posible, al mismo tiempo que se
evita tener que hacer cambios radicales en las aplicaciones o las estructuras de datos
existentes. En las palabras del Grupo Gartner , EAI es el "intercambio sin restricciones de
datos y procesos de negocio entre las aplicaciones o fuentes de datos conectadas en la
empresa4.
Microsoft BizTalk Server es una integración de aplicaciones empresariales (EAI), usado para
hacer frente a todos sus retos de integración en las empresas.
4 Informe de abril de 2001 para los AIIM International, "Aplicaciones Empresariales: Adopción de E-
laborales y Documento Technologies, 2000-2001: Estudio de la Industria Mundial," Gartner define EAI
de como "el pecado Restrictions Intercambio de Datos y Procesos de Negocio Entre CUALQUIERA
Conectado Aplicaciones y fuentes de Datos en la Empresa. " Gable, Julie (marzo / abril de 2002).
"Integración de Aplicaciones Empresariales". Información Management Journal. Consultado el 2008-
01-22.
18
BizTalk Server proporciona un potente entorno de desarrollo y ejecución que integra los
procesos de negocio, dentro de la empresa, así como la integración con otras empresas.
La metodología usada para definir este tipo de proyectos, incluyen procedimientos detallados,
productos resultante, funciones, herramientas y normas de calidad para la terminación del
ciclo de vida completo del desarrollo del sistema. Se enfoca en la necesidad de la organización
para el cumplimiento cabal de sus actividades y se basa en su metodología para establecer
fases que determinan cada paso del diseño o la implementación de un sistema de información,
su técnica es utilizada para desarrollar estrategias que mejoren el funcionamiento de
los sistemas de información ya existentes.
2.1. ANTECEDENTES
En Latinoamérica y el Perú existen diversas muestras de trabajos, tesis o
investigaciones basadas en la integración de sistemas. A continuación los
antecedentes:
A. Roberto Diaz Ramirez (2001).Integración de Aplicaciones e Intercambio de
Datos Utilizando XML y Herramientas B2B. Título para optar el grado de
licenciado en administración de sistemas de información. Universidad
Francisco Marroquin. Guatemala.
La tesis que se presenta a continuación, introduce un tema bastante nuevo para la
industria de la informática en Guatemala, inclusive es relativamente nuevo a nivel
mundial.
El interés por el tema surge a raíz de la experiencia del autor de trabajar en una
organización internacional con la necesidad de integrar sus dos más grandes
sistemas con plataformas diversas y una cantidad de información común y útil para
ambos sistemas.
El autor hace énfasis al tema de la integración de aplicaciones, presentando una
reseña histórica de la evolución de la necesidad de integración y a las soluciones
que han surgido con el tiempo, mencionando las principales ventajas que la
integración de aplicaciones representa en el ámbito de los negocios. Además
realiza un análisis de cómo la integración de aplicaciones ha evolucionado el
comercio electrónico B2B y las dificultades que enfrenta, dando a conocer las
diversas alternativas de proveedores y cómo evaluarlos en busca de una solución
de integración de aplicaciones.
Adicionalmente muestra algunos ejemplos de integración que ayudan a comprender
mejor el alcance de los proyectos e integración de aplicaciones, dando a conocer
una perspectiva del valor agregado que la integración de aplicaciones representa y
de las distintas opciones de esta tecnología.
19
B. Alfredo Andrés Díaz Puentes (2008). Integración de SAP y aplicaciones
legadas a través de SOA. Memoria para optar el título de ingeniero civil en
computación. Universidad de Chile. Santiago de Chile.
El objetivo general del presente trabajo, es un caso real de integración entre el ERP
de SAP y los legacy del área de logística de una compañía distribuidora de
combustible en Chile utilizando los principios que el patrón de diseño SOA ofrece y
con la ayuda de herramientas comerciales que implementan y facilitan la integración
entre sistemas computacionales heterogéneos. El área de logística de la compañía
cuenta con una variedad de aplicaciones legacy Web del tipo J2EE que utilizan de
manera independiente y que les permiten realizar la programación de los pedidos
de combustible que sus clientes efectúan, asignación de los pedidos a los distintos
camiones tanques, modificaciones y cancelaciones que se deben realizar a los
pedidos, medición de eficiencia de los transportes y viajes efectuados.
La integración se basó en los conceptos que el patrón SOA indica como mejor
práctica con la ayuda de plataformas tecnológicas de la línea WebSphere de IBM
tales como MessageBroker, MQ, Adaptadores del MessageBroker para
comunicarse con el ERP y con el sistema operativo sobre el cual funciona que es
Os/400 sobre iSeries. Las principales decisiones tomadas durante el proyecto están
basadas con casos en los cuales se hizo pasar el flujo de datos por la plataforma
SOA instalada y entregaba mejores prestaciones, tiempos de respuesta y
seguridad. Durante todo el proyecto, estos fueron temas de discusión y análisis
dado que cada caso en la práctica trae un análisis individual que debe ser
enfrentado bajo la mirada de conveniencia para la empresa, entendiéndose que
estas conveniencias podrían ser tiempos de respuesta, puntos de falla, servicio e
imagen al cliente.
El resultado final fue un conjunto de aplicaciones del tipo Web y legacy que se
comunican con el ERP de SAP para lograr de manera exitosa el despacho de
combustible desde las plantas de la compañía; todo esto con la ayuda de una
infraestructura conformada por filesystem y carpetas compartidas, plataformas de
integración de IBM, flujo de mensajes que transmiten los datos, etc. Se concluye
que los proyectos de integración logran el objetivo principal sobre el cual se basan,
respecto al performance y eficiencia de los procesos es muy difícil dimensionarla y
considerarla durante este tipo de proyectos y deben ser enfrentados, por lo general,
posteriormente a su puesta en marcha, cuando los datos cuantitativos del
funcionamiento entregan muchos más antecedentes que ayuden a encontrar las
oportunidades de mejoras y los cuellos de botella que deben ser solucionados.
20
C. Luis Eduardo Medina Bonilla, Luis Enrique Pinedo Marín (2010).
Implementación de un sistema de integración para las bibliotecas municipales
de Lima y Callao utilizando SOA y J2ME. Tesina para optar el título profesional
de Ingeniero de Sistemas. Universidad Nacional Mayor de San Marcos. Lima
- Perú.
Hoy en día las organizaciones operan con diversos sistemas informáticos, los
cuales tienen que comunicarse entre sí con independencia del tipo de plataforma,
para poder intercambiar e integrar la información. En este contexto se hace
necesario establecer mecanismos que permitan realizar esta integración para poder
ofrecer mejores servicios que puedan brindar una fuente de información diversa y
consolidada.
La presente tesina propone un enfoque de solución basado en una arquitectura
orientada a servicios e integración de datos para las bibliotecas municipales de Lima
y Callao. Actualmente las bibliotecas municipales de Lima y Callao no cuentan con
un servicio web, todas ellas cuentan con aplicaciones que sólo proporcionan
información de la misma biblioteca, lo cual no resulta cómodo para los usuarios
siendo necesario consultar en diferentes bibliotecas.
La solución planteada es una integración basada en servicios web y utilizando un
bus de servicios empresarial (ESB), donde cada servicio web será implementado
para cada municipalidad que tenga un aplicativo de consulta de material
bibliográfico. El bus de servicios será el encargado de dirigir cada petición de
consulta hacia el respectivo servicio web.
Las razones que conllevaron a la elección de la solución son las siguientes: ofrecer
un mejor servicio de consulta de material bibliográfico. Facilitar a los usuarios de las
bibliotecas el acceso a la información de las municipalidades sin la necesidad de
desplazarse físicamente hacia la biblioteca.
D. Karin Zaida Acero Navarrete, Danny Humberto Escalante Gallardo (2012).

Integración de los sistemas informáticos de la empresa ADALTEX utilizando
Oracle Service Bus como middleware basado en el estándar SOA. Tesis para
optar el Título Profesional de Ingeniero de Sistemas. Universidad Nacional
Mayor de San Marcos. Lima- Perú
Durante varias generaciones, los sistemas de las empresas han servido para un
propósito específico a un único usuario o grupo de usuarios, los cuales actúan como
la interfaz de dicho sistema con el resto de la organización, con lo cual se ha limitado
su conexión con otros sistemas modernos o más amplios en la empresa. Partiendo
de esta necesidad es que surge el concepto de “Integración de aplicaciones
21
Empresariales” o EAI (siglas en inglés de Enterprise Application Integration) que se
define como el uso de software y principios de arquitectura de sistemas para
integrar un conjunto de aplicaciones dentro de cualquier empresa.
La integración de aplicaciones y procesos de negocio es una prioridad para la gran
mayoría de las empresas de hoy en día. Uno de los retos que encaran las
organizaciones modernas es dar a sus empleados información completa en tiempo
real. Las aplicaciones en uso actualmente se apoyan en tecnologías antiguas, por
lo cual los sistemas enfrentan dificultades a la hora de transmitir información entre
las aplicaciones. Lo que se busca en esta tesis es proponer una solución efectiva
para resolver muchos de estos problemas mediante la integración de sistemas
internos en la empresa ADALTEX con una arquitectura flexible y adaptable a las
tecnologías utilizadas en el desarrollo de sistemas informáticos. Logrando así un
mecanismo para incrementar el conocimiento de la organización y crear ventajas
competitivas futuras a la empresa.
E. Rafael Zancan Frantz (2008). Integración de Aplicaciones - Un Lenguaje
Específico de Dominio para el Diseño de Soluciones de Integración.
Memorias de Investigación. Universidad de Sevilla. España.
El área de la integración está cobrando una gran importancia en el contexto de los
ecosistemas de software actuales y de la inversión que requieren para resolver los
problemas de integración, son varios enfoques que se dan a la integración. El
primero, el Mashup, está enfocado en proporcionar la creación de una nueva
aplicación por medio de la composición de servicios EAI que integra las aplicaciones
dentro de la misma empresa, con el objetivo de mantener las aplicaciones
funcionando en sincronía y de forma exógena poder integrar sus funcionalidades;
B2B tiene un propósito de tener en cuenta a la hora de diseñar la solución de
integración, ETL cuyo objetivo es extraer datos de fuentes distintas, procesar las
transformaciones que se hacen necesarias para almacenarlos en otra base de
datos y entonces permitir la ejecución de operaciones de lectura sobre los datos,
ofreciendo por medio de esta nueva base una vista homogénea pero ofﬂine de los
datos.
Las herramientas actuales tienen problemas de alcance y aún no son capaces de
responder de forma deseable a los problemas planteados por la integración.
Al término de la investigación llevada será posible construir una herramienta para
EAI que tenga un alcance más amplio que las actuales, y, que por lo tanto, permita
diseñar soluciones más directas y sencillas con una menor inversión. En esta
memoria se describe una propuesta, denominada Guaraná, para diseñar soluciones
de integración de aplicaciones.
22
2.2. MARCO TEÓRICO
La integración de la diversidad de tecnologías de información y comunicación que posee
normalmente una empresa se ha convertido en una necesidad ineludible e
impostergable. Esta necesidad está relacionada con la integración de software
heterogéneo y se origina en la gran diversidad de productos de software que las
empresas emplean para apoyar sus diferentes procesos productivos, muchos de estos
productos provienen de diferentes proveedores, además pueden estar basados en
plataformas de hardware y software diferentes o emplean modelos conceptuales
incompatibles y no tienen, la capacidad requerida para integrarse e interoperar. Entre
los enfoques recientes que han emergido para resolver el problema de integración de
software se destaca la Integración de Aplicaciones Empresariales (EAI).
2.2.1. Un modelo conceptual para la integración empresarial

Para apoyar sus diferentes procesos de negocios, la mayoría de las empresas
poseen un conjunto muy variado de sistemas de información y control. Por lo
general, estos sistemas han sido desarrollados en momentos diferentes y
usando tecnologías de software disímiles y, en muchos casos, incompatibles.
Por otro lado, es común que estos sistemas operen en equipos de computación
de diferentes marcas o tecnologías y corran bajo sistemas operativos diferentes.
Este problema ha sido tratado de diferentes maneras por los especialistas del
área. La primera modalidad de integración que emergió se concentró en la
integración de los equipos de computación a través de redes tanto locales como
de amplio alcance. Este tipo de integración facilitó la transmisión de datos entre
equipos y sistemas operativos heterogéneos conectados en red y dio origen a
nuevas formas de concepción de sistemas de información basadas en la
distribución de los datos.
La integración de sistemas de información heterogéneos (aquellos
fundamentados en equipos y tecnologías de software múltiples) es, sin embargo,
un problema que va más allá de la conexión física de los equipos en los que
tales sistemas se apoyan. Para la solución de este problema han surgido, en la
última década, propuestas que van desde la integración de sistemas a través de
una interfaz gráfica común, hasta llegar a la integración de los procesos de
negocios inter-empresa o intra-empresas basados en las nuevas tecnologías de
información y comunicaciones.
La mayoría de estas soluciones son complementarias y descansan en la
interconexión de equipos en redes.
23
Basado en las relaciones que estas soluciones presentan, se propone en el
gráfico N° 2.1 un modelo conceptual que aborda la integración de los sistemas
de información, control y decisión de una empresa a través de una serie de
capas o niveles escalables.
Estos niveles permiten avanzar gradualmente en la integración de sistemas
heterogéneos desde un nivel netamente físico de integración de equipos y
sistemas operativos (nivel 1) hasta llegar a la automatización e integración de
procesos de información, control y decisión, la cual se da en los niveles 5-6.
Gráfico N° 2.1:
Niveles de automatización e integración de software heterogéneo
Fuente: Enfoques de Automatización e Integración de Sistemas Heterogéneos.

Elaboración: Ariel Logan – Desarrollador de Ensayo Automatización e Integración de
Sistemas Heterogéneos.
a. Nivel 1: Integración basada en redes

Este nivel constituye la plataforma tecnológica sobre la cual se
fundamentan los otros niveles de integración. La integración se da aquí
a través de la interconexión física y lógica de los equipos de
computación de la empresa usando redes de área local y su conexión
a redes de amplio alcance, particularmente Internet. Dentro de una
empresa de producción, y en función de las diferentes plataformas en
ella presentes, es común encontrar redes que soportan los procesos en
tiempo real; redes que permiten la supervisión de los procesos de
producción; la concentración de la información mediante los sistemas
de supervisión y redes para apoyar los ambientes o sistemas de
información gerencial para la planificación de producción, gestión,
comercialización, etc. En una empresa de producción deben existir los
dispositivos que interconecten estos tipos de redes, lo cual se hace, por
lo general, mediante pasarelas (gateways).
24
b. Nivel 2: Integración de datos
La integración en este nivel se realiza mediante la transferencia de

datos entre dos o más archivos y/o bases de datos heterogéneas. La
integración de datos entre dos aplicaciones involucra la transformación
de los datos de una de ellas al formato usado por la otra, sin que sea
necesario modificar el código de las aplicaciones. Este tipo de
integración se puede realizar de dos modalidades diferentes: de base
de datos a base de datos o mediante el uso de bases de datos
federadas (Linthicum, 2000). Para la integración de base de datos a
base de datos, se emplean mecanismos tales como la replicación de
datos, conectores ODBC o corredores de mensajes (message brokers).
En la segunda modalidad, las bases de datos heterogéneas se integran
a través de un modelo de datos virtual único, el cual establece las
correspondencias (mappings) con las bases de datos integradas. La
evolución en los mecanismos de integración de bases de datos
heterogéneas ha facilitado la integración entre sistemas de información
ubicados en diferentes niveles de la jerarquía gerencial de una
empresa.
c. Nivel 3: Integración de procesos
En este nivel, dos o más aplicaciones pueden compartir su lógica de

negocios (procesos) y sus datos. Los procesos emplean las redes para
interconectarse, y pueden acudir a modelos de datos comunes para
transferirse la información de manera segura. Esta manera de integrar
aplicaciones heterogéneas se da directamente a través de sus
procesos, los cuales interoperan mediante interfaces de programación
(APIs) o mediante el pase de mensajes remotos entre objetos. La
integración mediante interfaces de programación requiere que cada
aplicación disponga de un conjunto de API’s, a través de los cuales
otras aplicaciones pueden acceder a los procesos y datos que ella está
dispuesta a compartir o hacer visible. La integración mediante pases de
mensajes remotos emplea varios mecanismos tales objetos
distribuidos, servidores de aplicación, monitores de procesamiento de
transacciones y marcos. Las arquitecturas de objetos distribuidos
CORBA, Enterprise JavaBeans (EJB) y COM se utilizan normalmente
para implementar la integración a nivel de procesos.
25
d. Nivel 4: Integración usando interfaces gráficas usuario-sistema
(GUI)
Resuelto el problema de la interacción entre los diferentes equipos, la

información existente en una aplicación puede ser necesaria para un
operador humano, que la debe recuperar independientemente del
sistema que la mantenga. Para dos aplicaciones o sistemas
heterogéneos, S1 y S2, es posible lograr su integración a un nivel
simplemente visual a través del uso de interfaces gráficas (GUIs)
basadas en la tecnología web. En este caso, una interfaz web es
utilizada para visualizar información y/o introducir conjuntamente datos
en S1 y/o S2, manteniendo la independencia y separación de cada
aplicación. Por ejemplo, un planificador podría, a través de una misma
interfaz, ver simultáneamente la existencia de un producto x en un
sistema de inventario y el valor del mismo en un sistema de mercadeo.
Esta manera de integrar aplicaciones es muy común en sistemas de
información web que acceden a diferentes bases de datos con la
intención de visualizar su contenido en una misma interfaz. Linthicum
(2000) discute un método de integración por interfaz, denominado
screen scrapping, el cual es aún más simplista que el anterior. En este
método, una aplicación S1 se integra a otra aplicación S2 a través de la
localización, lectura y transformación de los datos requeridos por S1
que están contenidos en la interfaz GUI de S2.
e. Nivel 5: Integración empresarial
Persigue la integración de los procesos de decisión, control y manejo

de información de la empresa, a través de un enfoque integral de
planificación estratégica fundamentada en el modelado de la empresa
y de sus sistemas de información, decisión y control. En este nivel, las
diferentes aplicaciones o sistemas que satisfacen un área de negocios,
se intercomunican haciendo uso de la integración de procesos, a partir
de modelos del negocio, donde se define de manera clara la separación
entre las diferentes funciones, la responsabilidad de la información y
una visión común de la empresa.
26
f. Nivel 6: Integración entre empresas
Permite que los procesos de negocios de una empresa se comuniquen

o intercambien información con los procesos de negocios de otra, a
través de nuevas tecnologías tales como el B2B (Business-to-
Business). Modelos comunes del negocio, permiten interactuar a dos
empresas para satisfacer actividades del negocio. La integración se
basa en desarrollo de modelos de intercambio de información y
representación común de la información. El metalenguaje XML aparece
como una herramienta estandarizada para la transferencia de
información auto-contenida y la descripción de los procesos.
Estos cinco niveles, que describen diferentes formas de llevar a cabo la

integración de sistemas en una empresa.
2.2.2. El enfoque de automatización e integración empresarial
A comienzos de 1997, se organizó un grupo de trabajo interdisciplinario,

conformado por investigadores de la Escuela de Ingeniería de Sistemas de la
Universidad de Los Andes y del Instituto de Cálculo de la Universidad del Zulia,
con el objetivo de estudiar y buscar soluciones a los problemas de integración
de tecnologías de software. Con el apoyo financiero del CONICIT, este grupo
analizó diversos enfoques de integración empresarial y de software
heterogéneo, entre los que se destacan la automatización integral, la
planificación estratégica de sistemas de información, la integración e ingeniería,
la integración de aplicaciones empresariales y las arquitecturas de objetos.
A través de un proceso de selección e integración de las mejores prácticas,

conceptos, procesos y modelos propios de los enfoques citados, se produjo un
conjunto de soluciones orientadas a mejorar la efectividad de la aplicación de
las tecnologías TIC en el ámbito empresarial. Al enfoque resultante, desarrollado
por el grupo de la ULA, se le denominó Automatización e Integración
Empresarial (EAI).
Este enfoque ha sido utilizado con éxito en varias empresas públicas y privadas
del país, entre las que se incluyen la industria petrolera, empresas de tratamiento
y distribución de agua potable e instituciones para la administración de
regímenes fiscales especiales.
27
2.2.3. Enterprise Application Integration (EAI)
Enterprise Application Integration (EAI) o Integración de Aplicaciones de

Empresa, se define como el uso de software y principios de arquitectura de
sistemas para integrar un conjunto de aplicaciones5.
Las compañías están constantemente implementando nuevas soluciones de

manera informal, tanto al nivel de negocio como técnico. Esto ha provocado que
se formen sistemas aislados.
Debido al aumento de la necesidad de comunicación e intercambio de datos

entre estas aplicaciones independientes se ha desarrollado una disciplina cuyo
objetivo es lograr la comunicación entre todos los sistemas que operan en una
empresa, la integración de aplicaciones empresariales (EAI).
2.2.3.1. Definición de la EAI
EAI es el proceso de conectar las aplicaciones con otras para

intercambiar información. Cuando dichos sistemas no pueden compartir
su información efectivamente se crean cuellos de botella que requieren
de la intervención humana en la forma de toma de decisiones o en el
ingreso mismo de la información.
Durante varias generaciones, los sistemas de las empresas han servido

para un propósito específico a un único usuario o grupo de usuarios, los
cuales actúan como la interfaz de dicho sistema con el resto de la
organización, con lo cual se ha limitado su conexión con otros sistemas
modernos o más amplios en la empresa, más aún por la creciente
demanda de las empresas por compartir datos y usarlos en sus
procesos sin tener que realizar cambios en sus aplicaciones o en sus
estructuras de datos.
Uno de los retos que encaran las organizaciones modernas es darles a

sus empleados información completa en tiempo real. Muchas de las
aplicaciones en uso actualmente se apoyan en tecnologías antiguas,
por lo cual esos sistemas enfrentan dificultades a la hora de mover esta
información entre las aplicaciones.
5 http://es.wikipedia.org/wiki/Enterprise_application_integration
28
EAI, como una disciplina, busca solventar muchos de esos problemas,
así como crear nuevos paradigmas para ciertamente mejorar las
organizaciones, tratando de trascender el objetivo de conectar las
aplicaciones individuales para buscar ser un mecanismo que
incremente el conocimiento de la organización y crear ventajas
competitivas futuras a la empresa.
2.2.3.2. Objetivo de la EAI

EAI puede ser usado con diferentes fines:
 Integración de datos (información): asegurando que la información
en varios sistemas sea consistente. Esto también se conoce como
EII (Enterprise Information Integration).
 Integración de procesos: enlace de los procesos de negocios entre
diferentes aplicaciones.
 Independencia de proveedor: extrayendo las políticas o reglas del
negocio de las aplicaciones e implementándolas en un sistema EAI,
de forma que cualquiera de las aplicaciones usadas pueda ser
cambiada sin que dichas reglas de negocio deban ser
reimplementadas.
 Facade común: Un sistema EAI puede actuar como el front-end de
un cúmulo de aplicaciones, proporcionando una interfaz de acceso
única y consistente a esas aplicaciones y aislando a los usuarios
sobre la interacción con distintas aplicaciones.
2.2.3.3. Patrones de EAI

Se cuentan con tres tipos de patrones que se detallan a continuación:
A. Patrones de Integración
Hay dos patrones que implementan los sistemas de EAI:
 Mediación: aquí, los sistemas de EAI actúan como el vínculo
de los enrutadores entre varias aplicaciones. En el lugar en
el cual ocurre un evento interesante en alguna aplicación
(e.j., se crea una nueva información, se completa una nueva
transacción, etc.) se notifica a un módulo de integración del
sistema EAI. El módulo entonces propaga esos cambios a
las otras aplicaciones relevantes.
 Federación: en este caso, el sistema EAI actúa como un
consolidador de información entre varias aplicaciones.
29
Todos los accesos del 'exterior' a cualquiera de las
aplicaciones son recibidos por el sistema EAI, y éste está
configurado para exponer sólo la información relevante
conectándose a las aplicaciones del mundo exterior, y efectuar
todas las interacciones con las aplicaciones internas sin
intervención del agente externo.
Ambos patrones son usados en conjunto frecuentemente. El mismo

sistema EAI puede tener varias aplicaciones en sync (mediación),
mientras sirve requerimientos de agentes externos contra esas
aplicaciones (federación).
B. Patrones de Acceso
EAI soporta patrones de acceso tanto síncronos como asíncronos,
el primero es el habitual en el caso del patrón de mediación y el
segundo en el caso de federación.
C. Vida de los patrones

Una operación de integración puede ser de "corta vida" (por ejemplo,
puede mantenerse la sincronía de los datos entre dos aplicaciones
en un segundo) o de "larga vida" (por ejemplo, en uno de los pasos
puede ser necesario que el sistema EAI requiera de la aprobación
por parte de un agente humano de un préstamo y que éste necesite
horas o días para autorizarse).
La Integración de Aplicaciones Empresariales está relacionada con las

tecnologías de middleware, tal como Middleware Orientado a Mensajes
(MOM), y tecnologías de representación de datos, tal como XML. Otras
tecnologías EAI involucran el uso de servicios web como parte de una
arquitectura orientada a servicios, como medio de integración.
Las ventajas que tiene EAI son buenas permitiendo el acceso a la
información en tiempo real entre los sistemas, además de encadenar
los procesos de negocio y ayuda a incrementar la eficiencia
organizacional y mantiene la integridad de la información entre varios
sistemas.
30
2.2.4. Microsoft Biztalk Server 2013
BizTalk Server es una plataforma central de Microsoft para la Integración de
Aplicaciones Empresariales (EAI) y Gestión de Procesos de Negocio (BPM) las
funciones de integración y automatización de XML y servicio web. BizTalk Server
funciona como un motor de ejecución de procesos y como un concentrador de
varios transportes de mensajería y transformación de documentos.
La combinación de distintos sistemas en procesos empresariales efectivos
supone todo un desafío. En consecuencia, BizTalk Server incluye una amplia
variedad de tecnologías. La siguiente gráfica muestra los componentes más
destacados del producto.
Gráfico N° 2.2:
Motor de mensajería de BizTalk Server
Fuente: MSDN Library

Elaboración: Microsoft Corporation.
Tal y como se indica en la ilustración, el motor de BizTalk Server es el

componente principal del producto. Este motor cuenta con dos piezas
principales:
 Un componente de mensajería que proporciona la capacidad de
establecer una comunicación con otros tipos de software. Dado que
depende en adaptadores para distintos tipos de comunicación, el motor
admite una amplia gama de protocolos y formatos de datos, incluidos los
servicios web, entre otros.
 Un soporte para la creación y ejecución de procesos definidos
gráficamente, denominado orquestación. Las orquestaciones, integradas
sobre los componentes de mensajería del motor, implementan la lógica
que dirige un proceso empresarial completo o parte de éste.
31
2.2.4.1. Mensajería de Biztalk
En el centro de BizTalk Server se encuentran el motor de mensajería y
el motor de orquestación, que proveen la arquitectura subyacente para
integrar e intercambiar mensajes entre diferentes servicios, tanto dentro
de la organización como con entidades externas.
El motor de mensajería de BizTalk se encarga de:
 Recibir los mensajes entrantes.
 Analizar los mensajes recibidos para identificar sus formatos
concretos.
 Evaluar el contenido del mensaje para determinar cómo se
encaminará y procesará.
 Entrega los mensajes a sus destinatarios.
 Registra el estado de los documentos.
 El motor de orquestación, por su lado, coordina y planifica el
procesamiento de los mensajes y realiza la lógica compleja sobre
ellos a medida que pasan por un flujo de trabajo definido.
BizTalk Server aplica el modelo publicación/suscripción para enrutar los

mensajes. Este modelo permite a los desarrolladores diseñar procesos
y servicios que se suscriben a mensajes en vez de crear conexiones
punto a punto entre dos servicios. Con ello se hace posible añadir
nuevos proveedores y consumidores de servicios o modificar los
servicios existentes sin tener que rediseñar las aplicaciones.
En este modelo (como se muestra en el gráfico N° 2.3), los proveedores
de mensajes –también llamados “publicadores”- remiten mensajes a un
almacén centralizado (la base de datos MessageBox). Los suscriptores,
que pueden ser puertos de envío u orquestaciones, se suscriben a
mensajes concretos. Cuando MessageBox recibe un mensaje de
interés, se envía a todos los suscriptores.
Las suscripciones de BizTalk Server se basan en la coincidencia de
expresiones con pares nombre-valor asociados con cada mensaje que
procesa BizTalk Server. Estos pares nombre-valor se conocen como
propiedades de contexto del mensaje. Cada mensaje de BizTalk tiene
un contexto de mensaje asociado a él, que viaja con el propio mensaje
a medida que es procesado por BizTalk Server. El contexto del mensaje
se representa en memoria como un objeto, y persiste junto al mensaje
32
en forma de grupo de pares nombre-valor cuando se almacena en la
base de datos MessageBox. Cuando MessageBox recibe un mensaje,
algunas de sus propiedades de contexto se evalúan para detectar si
coinciden con alguna de las suscripciones activas, comparando los
valores de esas propiedades con los valores predefinidos utilizando
operadores del tipo “AND”, “OR” o “EXISTS”.
Gráfico N° 2.3:
Procesamiento de mensajes desde BizTalk

En el gráfico anterior se muestra cómo implementa BizTalk Server el

modelo publicación/suscripción.
 Los mensajes entran en el sistema BizTalk Server a través de
un puerto receptor. Cada puerto receptor contiene uno o más
puntos de recepción. Cada punto de recepción está configurado
con un adaptador, que define el método de comunicación
utilizado para conectarse y recibir datos desde un sistema o una
aplicación externa, como puede ser una carpeta de archivos, un
sitio web, una base de datos SQL Server o una aplicación de
otro fabricante
 El mensaje recibido se procesa en el pipeline de recepción. Un
pipeline puede contener varios componentes con los que se
33
desencriptan los mensajes, se reparten los mensajes batch, se
convierte un mensaje desde su formato nativo en un documento
XML o se valida su firma digital.
 Los puertos de recepción pueden, opcionalmente, configurarse
con uno o más mapas, que sirven para transformar mensajes
desde una estructura de datos a otra. Los mapas se utilizan para
transformar mensajes generados con formatos muy diversos a
un formato único y normalizado que será el que se utilice dentro
de la aplicación BizTalk.
 El mensaje se entrega a una base de datos Microsoft SQL
Server llamada MessageBox. Cuando un mensaje entra en
MessageBox, los metadatos asociados al mismo se evalúan
contra los valores de las suscripciones activas para saber a qué
puertos de envío o a qué orquestaciones debe enviarse el
mensaje.
 Una orquestación define la lógica que controla el flujo de trabajo
de un proceso de negocio. Un proceso de negocio puede utilizar
una o varias orquestaciones. Cada una de ellas consta de tipos
concretos de formas que se utilizan para expresar condiciones,
iteraciones y otros comportamientos.
 El mensaje, que puede o no procesarse a través de una
orquestación, se puede entregar a un puerto de envío. El puerto
de envío puede transformar los datos del mensaje utilizando un
mapa y después procesarlo a través de un pipeline de envío.
 El pipeline de envío puede convertir el mensaje desde el formato
XML interno utilizado por BizTalk Server al formato requerido por
el destinatario, y también puede encriptarlo para garantizar la
seguridad de la transmisión.
 El puerto de envío utiliza después un adaptador para conectarse
y transmitir el dato al sistema o aplicación externo.
El subsistema de mensajería de BizTalk Server habilita la comunicación

con una amplia gama de sistemas y aplicaciones. Soporta la conversión
de distintos formatos de datos, cuando recepciona o envía mensajes, y
es capaz de manejar protocolos propietarios y servicios basados en
estándares.
34
BizTalk Server emplea documentos estructurados para todas las
operaciones internas de mensajería y orquestación. Con independencia
del formato del mensaje entrante (que puede ser, por ejemplo XML, un
archivo de texto plano o EDI), los motores de mensajería y orquestación
solamente trabajan con mensajes en formato XML a nivel interno. Para
crear una aplicación sencilla de procesamiento de mensajes, el
desarrollador deberá:
 Crear las definiciones de esquema para todos los tipos de
mensajes que tendrá que procesar BizTalk Server.
 Crear uno o más mapas para transformar los datos desde una
estructura de esquema a otra.
 Configurar los puertos de recepción y los puntos de recepción
para permitir la recepción de mensajes
 Configurar los puertos de envío para enviar los datos a sistemas
externos
 Crear un pipeline a medida para cada procesamiento específico
que necesiten los datos del mensaje.
A. Creación de esquemas
Los esquemas que se procesan en BizTalk Server pueden proceder
de fuentes muy variadas. Una definición de esquema puede venir
predefinida por alguna aplicación externa o puede haberla enviado
un partner externo a la compañía. Para integrarlo con una aplicación
EDI existente, BizTalk Server dispone de más de 8.000 esquemas
distintos para soportar los estándares actuales. No obstante, en
muchas ocasiones tendremos que crear nuestros propios esquemas
para estructuras de documento XML o en texto plano utilizando el
editor de BizTalk.
B. Tipos de esquemas soportados

BizTalk Server soporta de forma nativa los siguientes tipos de
esquemas:
 XML: Los motores de mensajería y orquestación requieren que
todos los mensajes se encuentren en formato XML. Un esquema
XML define la estructura jerárquica de un mensaje XML. BizTalk
Server identifica y valida todos los mensajes contra un esquema
asociado.
35
 Texto plano: Un esquema de archivo de texto plano define la
estructura de los mensajes que se reciben en formato de texto
plano. Un archivo plano puede ser un archivo cuyos valores se
separan mediante delimitadores o por la posición que ocupan en
una cadena de texto. El lenguaje XSD (XML Schema Definition)
no soporta de forma nativa la estructura de texto plano, por lo que
BizTalk Server utiliza las capacidades de anotación de XSD para
guardar esta información adicional dentro del propio esquema
XSD. BizTalk Server define un amplio conjunto de etiquetas de
anotación que se pueden utilizar para guardar toda la información
adicional necesaria.
C. Mapeo de datos
Los mapas de BizTalk se emplean para convertir un mensaje de
entrada conforme con algún esquema en un mensaje de salida
conforme con un esquema diferente. Estas conversiones pueden
ser sencillas o complejas, incluir cálculos u otras operaciones de
manejo de datos.
Un mapa define la relación entre los esquemas de entrada y de
salida mediante enlaces y functoides. Un enlace implica la copia
directa de un registro o un campo e indica la función básica de copia
de datos desde un elemento o atributo de un mensaje entrante hacia
un elemento o atributo en un mensaje saliente. Los enlaces entre
campos y registros de los esquemas de entrada y salida se
establecen en tiempo de diseño. Así, en tiempo de ejecución, los
enlaces dirigen la creación de una instancia de mensaje saliente
conforme con el esquema de destino a partir de la instancia de
mensaje entrante, el cual es conforme con el esquema de origen.
Los enlaces pueden establecer conexiones directas entre elementos
de ambos esquemas o formar conexiones en lo que se denomina
“functoides”.
D. Conexión mediante Adaptadores
BizTalk Server necesita adaptadores especializados para el
intercambio de mensajes con aplicaciones y sistemas muy dispares.
Un adaptador es un componente de software basado en .NET que
ofrece a BizTalk Server una interfaz con distintos tipos de sistemas
aplicando protocolos basados en estándares, y con aplicaciones
36
especializadas que emplean mecanismos de comunicación
propietarios.
La mayoría de adaptadores soportan tanto operaciones de envío
como de recepción, aunque algunos soportan comunicaciones en
un solo sentido nada más. El comportamiento de un adaptador se
define configurando las propiedades del puerto de envío o del punto
de recepción de una instancia concreta de un adaptador.
2.2.4.2. Orquestación
Un proceso de negocio consiste en una serie de acciones, que, en
combinación, resuelven una necesidad concreta de la empresa. La
automatización de procesos de negocio permite coordinar procesos
habituales de las empresas, como pueden ser la tramitación de una
orden de pedido, con personas y aplicaciones de negocio –por ejemplo
un sistema ERP (Enterprise Resource Planning), un CRM (Customer
Relationship Management) u otras aplicaciones de línea de negocio
(LOB). Estos procesos frecuentemente se inician como tareas manuales
que requieren integración y la captura de datos desde distintos sistemas
y por parte de varias personas. Los procesos pueden extenderse a lo
largo de horas, días, semanas o incluso meses para completarse.
La orquestación de BizTalk es una capacidad flexible y potente que
proporciona diversos servicios y herramientas con los que se pueden
diseñar, automatizar y administrar procesos de negocio. Al igual que con
los lenguajes de programación procedimentales de toda la vida, una
orquestación representa la lógica subyacente de los mensajes que se
procesan.
La orquestación de BizTalk dispone de un modelo de programación
transaccional que incluye soporte para el manejo de excepciones y
recuperación ante transacciones fallidas. Se pueden definir dos tipos de
transacciones al crear una orquestación:
 Transacciones atómicas: Permiten que la transacción pueda
revertirse de manera automática a un estado anterior en caso de
que no se complete de forma correcta.
 Transacción de largo recorrido. Puede durar días, semanas o
incluso periodos de tiempo mayores, contener transacciones
anidadas y utilizar manejo de excepciones personalizadas para
resolver situaciones de error.
37
En consecuencia, las orquestaciones ofrecen una gran flexibilidad a la
hora de definir el curso de la acción a seguir en caso de fallo en un
proceso de negocio.
A. Diseñador de Orquestación
El diseñador de orquestación es un entorno de diseño en donde se

pueden crear representaciones visuales de los procesos de negocio.
El área de diseño es un lienzo de trabajo donde se van depositando
distintas figuras de la caja de herramientas, tal como se muestra en
el gráfico N° 2.4. Las formas se corresponden con distintas acciones
que se deben ejecutar al procesar un mensaje. En muchos casos el
diseñador debe configurar opciones para cada forma que se utiliza
al crear la orquestación.
La superficie de diseño se divide en tres áreas: un área de procesos

y dos áreas de puerto. El área de proceso contiene formas que
describen el flujo del proceso de la orquestación. Por ejemplo las
formas de ámbito permiten definir transacciones en un proceso de
negocio. Un ámbito contiene uno o varios bloques, tiene un cuerpo
y opcionalmente puede tener un cierto número de bloques de
manejo de excepciones así como un bloque de compensación
añadido.
El área de proceso de la superficie de diseño tiene a sus dos lados

las superficies de puerto, que contienen solamente formas de puerto
y rol que interactúan con las formas de envío y recepción del área
de proceso. Se puede utilizar cualquiera de ambos lados (derecho
e izquierdo) de una superficie de puerto para crear un puerto de
envío o de recepción. Esto nos permite crear orquestaciones bien
documentadas con menos conectores entrecruzados, lo que facilita
su lectura y comprensión.
38
Gráfico N° 2.4:
Diseñador de Orquestación

Para desarrollar una orquestación, los pasos a seguir son estos:
 Definir los esquemas que describen el formato de los mensajes

a procesar con la orquestación.
 Añadir y configurar las formas que representan las diferentes
acciones a realizar y que definen el proceso de negocio.
 Definir nuevas instancias de mensaje que se procesarán dentro
de la orquestación.
 Definir los puertos de orquestación para el envío y recepción de
mensajes.
 Definir y asignar las variables de orquestación para declarar y
gestionar los datos que se utilizan en ella.
 Vincular las formas de envío y recepción a puertos, y especificar
los puertos físicos que se utilizarán.
 Crear, desplegar y probar la orquestación.
39
B. El motor de orquestación de BizTalk
El motor de runtime de orquestación de BizTalk es un servicio
altamente optimizado que monitoriza y ejecuta las orquestaciones.
En tiempo de ejecución, el motor de orquestación de BizTalk ejecuta
los archivos creados con el diseñador de orquestación.
El motor de orquestación de BizTalk realiza las siguientes
actividades:
 Creación de instancias y ejecución de orquestaciones
 Mantenimiento del estado de una instancia de orquestación
en ejecución de forma que pueda recuperarse en memoria
cuando sea preciso
 Optimización de las orquestaciones en ejecución para
maximizar la escalabilidad, el rendimiento y el uso eficiente
de los recursos
 Un sistema fiable de apagado y recuperación
El motor de orquestación ejecuta orquestaciones creando instancias

individuales de los procesos de negocio. El motor del runtime
coordina estas distintas instancias para garantizar que cada
mensaje de respuesta se dirija a la instancia de orquestación que le
corresponde, utilizando un patrón de enrutamiento especializado
llamado “correlación”.
Deshidratación y rehidratación
Cuando se ejecutan muchos procesos de negocio al mismo tiempo,
el sistema puede tener problemas de escasez de memoria y pérdida
de rendimiento. El motor de orquestación de BizTalk lo resuelve
“deshidratando” y “rehidratando” las instancias de orquestación. La
deshidratación designa al proceso de guardar el estado de una
instancia de orquestación activa en la base de datos MessageBox
para después eliminarla de la memoria. Esto puede ocurrir si el
motor de orquestación determina que una instancia concreta lleva
inactiva un cierto tiempo. La deshidratación de la instancia libera los
recursos que utilizaba.
40
Deshidratación
El motor de orquestación tiene definido el tiempo máximo que puede
esperar una orquestación para efectuar ciertas acciones y si se
supera este límite, la instancia se deshidrata. Esto puede ocurrir en
las siguientes circunstancias:
 Cuando la orquestación está esperando a recibir un mensaje y
la espera supera el tiempo máximo determinado por el motor.
 Cuando la orquestación está esperando por un mensaje
suscrito.
 Cuando el retraso en la orquestación supera el límite
determinado por el motor.
 Entre reintentos de una transacción atómica.
El motor de orquestación guarda todo el estado de una instancia de

orquestación en ejecución en un almacenamiento permanente en
varios puntos de manera que la instancia se puede recuperar
completamente en memoria en un momento posterior. La
deshidratación de las instancias de orquestación permite al motor
tener más instancias “en marcha” que las que los recursos físicos
del sistema donde se ejecuta BizTalk Server permitirían
normalmente. La deshidratación está controlada de forma
automática por el motor de orquestación, pero el administrador
puede modificar los valores umbral de deshidratación alterando
ciertas propiedades de configuración de BizTalk Server.
Rehidratación
La “rehidratación” es el proceso inverso a la deshidratación, y
consiste en de-serializar el último estado de ejecución de una
orquestación a partir de la base de datos o recuperar en memoria el
estado de una instancia de orquestación previamente guardado. El
motor de orquestación recibe la orden de rehidratar una instancia de
orquestación cuando recibe un mensaje o cuando concluye un
tiempo de espera. En ese momento carga en memoria la instancia
de orquestación salvada, recupera su estado y la ejecuta desde el
punto en que quedó detenida.
Una orquestación se puede configurar para ejecutarse en más de
un servidor. Cuando una instancia de orquestación ha sido
41
deshidratada, se puede rehidratar en cualquiera de esos servidores.
Si uno de ellos deja de funcionar, el motor sigue ejecutando la
orquestación en otro servidor, continuándola desde su estado
previo. El motor aprovecha también esta funcionalidad para
implementar el balanceo de carga entre varios servidores.
C. Llamada a ensamblados externos
A lo largo de un proceso de negocio en ocasiones es preciso acudir
a alguna aplicación .NET o una funcionalidad externa que es más
eficiente si se desarrolla en un lenguaje de programación normal,
como C#. Las orquestaciones de BizTalk pueden pasar parámetros
a aplicaciones externas utilizando llamadas a métodos y así integrar
la funcionalidad de aplicaciones externas dentro del proceso de
BizTalk.
D. Escenarios de integración de servicios
Los servicios web y WCF se utilizan para exponer la funcionalidad
de un sistema o aplicación a otras aplicaciones y son considerados
como el mecanismo más extendido para el suministro de servicios.
BizTalk Server es totalmente compatible con los actuales
estándares WCF y servicios web. Este soporte permite a los
desarrolladores tanto consumir servicios externos dentro de un
proceso de negocio como publicar un proceso de negocio en forma
de servicio que puede ser consumido por aplicaciones externas.
Si en la empresa se necesita que un proceso de negocio concreto
sea accesible desde Internet para consumo por parte de usuarios,
entidades externas u otras aplicaciones, la orquestación se puede
publicar en forma de servicio WCF. Esto se hace ejecutando el
asistente de publicación de servicios WCF de BizTalk. Este
asistente crea una aplicación ASP.NET basada en WCF que corre
sobre Internet Information Services (IIS).
BizTalk Server permite llamar a servicios desde dentro de una
orquestación y a través de los puertos de envío de mensajes.
Además se pueden crear servicios web conforme con los
estándares del sector y servicios WCF, publicando las
orquestaciones o esquemas existentes, lo que simplifica muchos
escenarios de integración que habitualmente se consideran de alta
complejidad.
42
2.3. MODELO APLICATIVO
En el momento que se decide realizar el desarrollo de un sistema, el equipo de
desarrollo está sujeto a cumplir una serie de pasos formales llamados “Ciclo de Vida"
en el desarrollo de sistemas, los cuales son utilizados típicamente para construir un
sistema desde la raíz o para hacer cambios notables en el mismo.
Además diseñar un sistema de información no solo requiere de la experiencia sino
también de la metodología a seguir, existen distintas metodologías desarrolladas para
este fin, cabe resaltar que el uso de una metodología forma parte de la innovación de
una organización.
Por tal motivo y para el buen desempeño y desarrollo de la integración de sistemas,
se hace uso de la metodología estructurada, una de las metodologías propuestas por
Llorens Fabregas que permite desarrollar sistemas de información en organizaciones
de cualquier tipo, evaluando un sistema de información a través de cinco fases
sumamente importantes los cuales son: definición de requerimientos, análisis y diseño,
construcción, pruebas, producción-mantenimiento. Esta metodología ésta orientada a
proyectos medianos o de gran envergadura donde busca satisfacer las necesidades
del individuo u organización.
En el gráfico N° 2.5, se muestra el esquema de la metodología de desarrollo de
sistemas o también llamada metodología estructurada.
Gráfico N° 2.5:
Esquema de la metodología de desarrollo de sistemas
DEFINICIÓN DE
REQUERIMIENTO CICLO DE DESARROLLO DE
S SISTEMAS
ANÁLISIS Y
DISEÑO
CONSTRUCCIÓN
PRUEBAS
PRODUCCIÓN/
MANTENIMIENTO
Fuente: Metodología estructurada Llorens Fabregas Ensayos y Documentos

Elaboración: Juan Pablo Silva - Análisis y Diseño de Sistemas de Información de la Facultad de
Ciencias de la Computación Universidad Nueva Esparta – Venezuela.
43
En el gráfico anterior se esquematiza las fases descritas por Llorens Fabregas, donde
la primera fase, definición de requerimientos, está enfocado a la necesidad de la
organización, la planeación y las estrategias que se van a emplear para el desarrollo
del proyecto. La segunda fase de análisis y diseño, en esta fase se hace uso de los
datos y los procesos, los cuales serán analizados y diseñados desde una perspectiva
conceptual para ser plasmados en una física, estos datos son los recopilados durante
la primera fase, el análisis tiene como objetivo organizar y definir los procesos para
cumplir con todos los requerimientos del cliente. Al concluir estas dos fases, se
procede a la fase de construcción del sistema, el cual es considerado como parte
fundamental en el desarrollo de un proyecto. Luego, continúa la fase de pruebas,
donde se mide el nivel de calidad, funcionalidad, integración y aceptación técnica. Al
concluir con estas pruebas de forma satisfactoria, se cargan los archivos, bases de
datos y las tablas del nuevo sistema, para que de esta forma el cliente pueda comenzar
su uso, primero durante un periodo de aceptación, y finalizado este como el sistema
oficial.
Por último, una vez que un sistema pasa a formar parte de la vida diaria de la
empresa cada programa, procedimiento y cada estructura de datos se convierte en
una pieza del negocio, que como tal, deberá funcionar de forma constante exacta y
confiable.
2.3.1. Definición de requerimientos
Esta fase es fundamental para que la estrategia planteada concuerde con las
metas de la empresa, ya que en ella se ejecutan las funciones del negocio y
planificación de sistemas; esto con el fin de proyectar las estrategias del
negocio.
Durante esta fase se desarrolla un modelo del área estudiada, donde se

representa los procesos que se llevan a cabo, la información utilizada y los
procesos relacionados.
Todo parte de la condición o necesidad del usuario para resolver un problema

o alcanzar un objetivo. Los requerimientos pueden dividirse en requerimientos
funcionales y requerimientos no funcionales, donde los requerimientos
funcionales definen las funciones que el sistema será capaz de realizar y los
requerimientos no funcionales tienen que ver con características que de una u
otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en
tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad y estándares.
44
Para considerar como requerimiento la solicitud del cliente, ésta debe tener las
siguientes características:
 Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el proyecto a desarrollar, y además si sus características
físicas o factor de calidad no pueden ser reemplazados por otras
capacidades del producto o del proceso.
 Conciso: Un requerimiento es conciso si es fácil de leer y entender.
 Completo: Un requerimiento está completo si no necesita ampliar
detalles en su redacción, es decir, si se proporciona la información
suficiente para su comprensión.
 Consistente: Un requerimiento es consistente si no es contradictorio
con otro requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación.
 Verificable: Un requerimiento es verificable cuando puede ser
cuantificado de manera que permita hacer uso de los siguientes
métodos de verificación: inspección, análisis, demostración o pruebas.
Este modelo permite proyectar las estrategias, procesos y flujos de datos de la

empresa al igual que las interrelaciones entre procesos, con el fin de desarrollar
un proyecto de sistema de información capaz de lograr el objetivo planteado y
permita dar soporte al área en estudio.
El proyecto de sistemas debe contener:

 Los sistemas que requiere el área del negocio, así como sus bases de
datos y la información que intercambian o comparten.
 Descripción detallada de cada sistema y aplicación incluyendo sus
objetivos funcionales y sus bases de diseño.
 Todo hardware y software que serán utilizados para el funcionamiento
requerido por el área de negocio.
 Esquema de los problemas actuales del área de negocio y de las
posibles mejoras que se puedan realizar en cada sistema.
 Análisis de los beneficios que se espera derivar de los sistemas que
conforman la arquitectura.
45
En conclusión se puede decir que los requerimientos son el punto de acuerdo
entre el cliente y el proyecto de desarrollo de software, este entendimiento es
necesario para poder desarrollar el servicio que satisfaga las necesidades del
cliente, por ende es lógico que para recabarlos haya que obtener la información
de primera mano. Esto es, mediante entrevistas con el cliente o recabando
documentación que describa la manera como el cliente desea que funcione el
sistema.
Las necesidades y / o requerimientos del cliente evolucionan con el tiempo y
cada cambio involucra un costo. Por eso es necesario tener archivada una
copia de la documentación original del cliente, así como cada revisión o cambio
que se haga a dicha documentación.
2.3.2. Análisis y diseño

El análisis y diseño de un sistema de información define el proceso de aplicar
ciertas técnicas y principios con el propósito de definir un proceso, con
suficientes detalles como para permitir su interpretación y realización física.
Esta fase se da inicio teniendo en cuenta la especificación preliminar de lo que
el nuevo sistema de información debe hacer y se tiene claro que es necesario
realizar cambios para dar solución a los problemas del sistema actual
respondiendo a las nuevas necesidades y a las oportunidades para usar la
información, por ello el objetivo de esta fase es desarrollar el diseño
arquitectónico de los sistemas, utilizando los requerimientos obtenidos en la
primera fase. En el diseño arquitectónico se engloban dos componentes: los
datos y los procesos, los cuales serán analizados y diseñados desde una
perspectiva conceptual a una física, dentro de las tres (3) actividades que se
encuentran en esta fase.
Actividades en la fase de Análisis/Diseño:

 Análisis y diseño de procesos: Las operaciones del negocio y los
requerimientos de funcionamiento definidos en la primera fase, se
toman en cuenta con el propósito de determinar la forma en que debe
funcionar el sistema.
 Análisis y diseño de datos: Con los requerimientos de información
definidos en la primera fase se debe organizar los distintos modelos de
datos que nos ayuden a diseñar la base de datos que hagan falta para
que el sistema funcione de acuerdo al modelo de funcionamiento.
46
 Análisis y diseño de la interfaz: Actividad en la cual se analiza y
diseña la forma en que pueden ser construidos las interfaces a
desarrollar, haciendo uso de los componentes necesarios para su
correcto funcionamiento.
El diseño de sistemas es el arte de definir la arquitectura

de hardware y software, componentes, módulos y datos de un sistema para
satisfacer los requerimientos del usuario.
Los métodos de análisis y diseño orientado a objetos se están volviendo en los
métodos más utilizados para el diseño de sistemas, por ello dentro de esta fase
se debe tener en cuenta los efectos que pueda producir la introducción del
nuevo sistema sobre el entorno en el que deba funcionar, adecuando los
criterios de diseño a las características del mismo. En este contexto está
adquiriendo una importancia creciente la adaptación de todo sistema-producto
a las capacidades de las personas que van a utilizarlo, de forma que su
operación sea sencilla, cómoda, efectiva y eficiente.
2.3.3. Construcción
En esta fase se da la transición del proceso de diseño al desarrollo del sistema,
es decir, se dará inicio con la implementación y ejecución del proyecto teniendo
en cuenta lo siguiente:
 Las especificaciones que provienen del análisis y diseño previo para
su codificación en un lenguaje de programación, además la utilización
de otras herramientas necesarias para el desarrollo del sistema.
 Realizar la documentación del sistema, esta debe incluir además los
programas que conforman el sistema.
 Verificar que se cuente con los equipos suficientes para la
implementación del sistema.
 Capacitar a los usuarios y al personal de sistemas en las actividades de
procesamiento de datos y mantenimiento.
 Establecer estrategias para la implementación del nuevo sistema.
En esta parte del procedimiento suelen aparecer errores del análisis y diseño,
pero esto es debido a una falta de planeación y control, además alguna de las
situaciones que se puedan presentar pueden ser debido a que algún proceso
no haya sido bien interpretado por el analista. Por ello se debe establecer un
47
tipo de planeación y control para evitar estas contingencias para evitar que
el proyecto pierda seriedad, definiendo claramente las funciones de las
personas involucradas en el proceso de desarrollo para que así al surgir
problemas, sea de manera oportuna y que todo el desarrollo sea llevado sin
contratiempos.
Dentro de esta fase de construcción existen actividades separadas en tres sub-
fases:
 Desarrollo de Infraestructura
Durante esta sub-fase se desarrollará y organizará la infraestructura que
permita cumplir las tareas de construcción en la forma más productiva
posible, esto implica contar con un ambiente de desarrollo con
herramientas específicas para una implementación adecuada del
sistema.
 Desarrollo de datos
Todo sistema de información se alimenta de datos para su
funcionamiento, por ello en esta sub-fase se crean y establecen las
objetos que darán vida al sistema en desarrollo.
 Desarrollo de procesos
En esta sub-fase se inicia con el desarrollo de los procesos identificados
y analizados en la etapa de diseño. Además de llevar a cabo las
actividades para construir las interfaces que harán posible el consumo,
procesamiento y transformación de información.
La fase de construcción incluye tareas fundamentales para la ejecución del

proyecto, tomando en cuenta los diversos procedimientos y basándose en las
mejores prácticas para la elaboración del sistema.
Paralelamente a la implementación del sistema y para su correcto desarrollo se
realizan las pruebas unitarias y las pruebas de integración a nivel de la unidad
de diseño.
2.3.4. Pruebas
Esta fase, da inicio luego de que las diferentes unidades de diseño han sido
desarrolladas y probadas por separado. Durante su desarrollo, el sistema se
emplea de forma experimental para asegurar que el software no falle, es decir
que funcione de acuerdo a sus especificaciones y a la manera que los usuarios
48
esperan que lo haga, y de esta forma poder detectar cualquier anomalía, antes
de que el sistema sea puesto en marcha.
Para evaluar el desenvolvimiento del sistema, en esta fase se llevan a cabo
varios niveles de prueba:
 Funcional: Prueba desde el punto de vista de los requerimientos

funcionales.
 De sistema: Prueba desde el punto de vista de los niveles de calidad
del sistema y de desempeño.
 De integración: Prueba de interfaces.
 De aceptación técnica: Prueba de manejo de condiciones extremas.
Si el sistema cumple de forma satisfactoria con estos niveles mencionados

anteriormente, se procede a realizar la carga de los archivos, base de datos y
tablas del nuevo sistema, para que de esta forma se pueda dar inicio al proceso
de aceptación final, durante el cual, el sistema comenzará a funcionar bajo la
responsabilidad del área de tecnologías de información y del usuario, por un
lapso determinado de tiempo, denominado “Periodo de Aceptación”.
Finalizado el periodo de aceptación, se le dará al sistema la aprobación final,
para que pase a ser el sistema oficial.
2.3.5. Producción y mantenimiento

Una vez que un sistema pasa a formar parte de la vida diaria de la empresa,
cada programa, cada procedimiento y cada estructura de datos se convierte en
una pieza del negocio que, deberá funcionar en forma constante, exacta y
confiable.
La operación del negocio ahora dependerá del funcionamiento del sistema, por
lo que las tareas de mantenimiento cobran vital importancia.
 Producción
Finalmente, en la etapa de producción se asegura que el sistema
funcione correctamente en la mayoría de los casos, y con intervención
mínima de los administradores del sistema. Para esto se realizan
nuevas pruebas, se reevalúan los resultados y se hacen refinamientos
del sistema, los cambios necesarios deberán ser introducidos sin afectar
a los usuarios. El resultado de esta etapa un sistema listo para su
operación.
49
Durante la fase de mantenimiento, se ponen en práctica todas las políticas
y los procedimientos destinados a garantizar la operación continua de los
sistemas y asegurar su uso efectivo, con el fin, de que éstos se constituyan
en una verdadera herramienta de apoyo al logro de los objetivos
estratégicos de la empresa.
 Mantenimiento
Luego que el nuevo sistema ha estado operando, el revisor del sistema
determinará si el programa ha logrado los requerimientos de los
objetivos, se debe prestar especial atención a la utilización y la
satisfacción de los usuarios finales, ellos constituirán un indicador
fundamental. Se debe revisar las solicitudes de cambios a los
programas que se han realizado, para evaluar el tipo de cambios que
se exigen al sistema, el tipo de cambios puede indicar problemas de
diseño, programación o interpretación de los requerimientos de usuario.
2.3.6. Miembros de un proyecto de sistemas

 Líder (Gerencia el proyecto).
 Analista (recoge información inicial y define requerimientos).
 Diseñador de S.I.
 Diseñador de Bases de Datos (B.D.).
 Programador (Codifica/Prueba).
 Usuario directo. (Expresa necesidades).
2.4. MARCO CONCEPTUAL

a. Integración: Es el proceso por el cual las cosas se unen y se adhieren a otras
para constituir un todo, completar un todo con las partes que faltaban, hacer que
alguien o algo pase a formar parte de un todo. Aunar, fusionar dos o más
conceptos, corrientes, entidades, etc., divergentes entre sí, en una sola que las
sintetice.
b. Middleware: Middleware es un software de conectividad que ofrece un conjunto
de servicios que hacen posible el funcionamiento de aplicaciones distribuidas
sobre plataformas heterogéneas. Funciona como una capa de abstracción de
software distribuida, que se sitúa entre las capas de aplicaciones y las capas
inferiores (sistema operativo y red). El Middleware nos abstrae de la complejidad
y heterogeneidad de las redes de comunicaciones subyacentes, así como de los
sistemas operativos y lenguajes de programación, proporcionando una API
50
(Application Programming interface) para la fácil programación y manejo de
aplicaciones distribuidas. Dependiendo del problema a resolver y de las funciones
necesarias, serán útiles diferentes tipo de servicios de middleware.
Por lo general el middleware del lado cliente está implementado por el Sistema
Operativo subyacente, el cual posee las librerías que implementan todas las
funcionalidades para la comunicación a través de la red.
c. Mapas: Los mapas de BizTalk se emplean para convertir un mensaje de entrada
conforme con algún esquema en un mensaje de salida conforme con un esquema
diferente. Estas conversiones pueden ser sencillas o complejas, incluir cálculos u
otras operaciones de manejo de datos. Un mapa define la relación entre los
esquemas de entrada y de salida mediante enlaces y functoides.
d. Orquestación: La orquestación de BizTalk es una capacidad flexible y potente
que proporciona diversos servicios y herramientas con los que se pueden diseñar,
automatizar y administrar procesos de negocio. Al igual que con los lenguajes de
programación procedimentales de toda la vida, una orquestación representa la
lógica subyacente de los mensajes que se procesan.
e. Pipeline: Son componentes de software que se utilizan para procesar los
mensajes, los cuales pueden ser procesadas como se reciben o justo antes de
que se envíen a través de un puerto de envío. El pipeline se puede utilizar para
proporcionar un procesamiento adicional para mensajes tales como la
normalización de los datos de varios formatos a XML.
f. Deshidratación: El motor de orquestación tiene definido el tiempo máximo que
puede esperar una orquestación para efectuar ciertas acciones y si se supera este
límite, la instancia se deshidrata.
g. Rehidratación: La “rehidratación” es el proceso inverso a la deshidratación, y
consiste en de-serializar el último estado de ejecución de una orquestación a partir
de la base de datos o recuperar en memoria el estado de una instancia de
orquestación previamente guardado. El motor de orquestación recibe la orden de
rehidratar una instancia de orquestación bien cuando recibe un mensaje o cuando
concluye un tiempo de espera. En ese momento carga en memoria la instancia de
orquestación salvada, recupera su estado y la ejecuta desde el punto en que
quedó detenida.
h. Functoides: Un functoid es una herramienta para la aplicación de los métodos a
los datos a través de una interfaz gráfica de usuario desde dentro de la
herramienta de mapeo de BizTalk. En un típico mapa de BizTalk, se copian los
datos de un origen a un destino arrastrando una línea entre los dos. Un functoid
51
se sienta en el medio de esta operación y aplica su método a los datos entrantes
con el fin de transformar a los requisitos de la de destino.
i. SOA: La Arquitectura Orientada a Servicios (Service Oriented Architecture), es un
concepto de arquitectura de software que define la utilización de servicios para dar
soporte a los requisitos del negocio. Permite la creación de sistemas altamente
escalables que reflejan el negocio de la organización, a su vez brinda una forma
estándar de exposición e invocación de servicios, lo cual facilita la interacción
entre diferentes sistemas propios o de terceros.
j. EAI: Integración de Aplicaciones Empresariales (Enterprise Application
Integration) es lograr la interoperabilidad y organización del flujo de información
entre aplicaciones heterogéneas, es decir, asegurar la comunicación entre las
distintas aplicaciones y formar el sistema de información de la empresa, incluso
de los clientes, socios o proveedores.
k. CORBA: (Common Object Request Broker Architecture) es un estándar que
establece una plataforma de desarrollo de sistemas distribuidos facilitando la
invocación de métodos remotos bajo un paradigma orientado a objetos. Permite
la interoperabilidad entre aplicaciones escritas en distintos lenguajes y ejecutadas
en distintas plataformas. Envuelve el código escrito en otro lenguaje junto con una
serie de reglas y órdenes de ejecución legibles por otra máquina CORBA. Además
de ello, define servicios de seguridad y transaccionalidad para las comunicaciones
entre objetos CORBA.
l. ODBC: (Open DataBase Connectivity), que es un estándar de acceso a bases de
datos desarrollado por Microsoft Corporation, el objetivo de ODBC es hacer
posible el acceder a cualquier dato de cualquier aplicación, sin importar qué
Sistema Gestor de Bases de Datos (DBMS por sus siglas en inglés) almacene los
datos, ODBC logra esto al insertar una capa intermedia llamada manejador de
bases de datos, entre la aplicación y el DBMS, el propósito de esta capa es traducir
las consultas de datos de la aplicación en comandos que el DBMS entienda.
m. API´s: API es la abreviatura de Aplication Programming Interface. Un API no es
más que una serie de servicios o funciones que el Sistema Operativo ofrece al
programador. Visto desde la perspectiva del código máquina, el API aparece como
una serie de llamadas mientras que si lo vemos desde la de un lenguaje de alto
nivel, el API aparece como un conjunto de procedimientos y funciones.
n. GUI: Es una interfaz de usuario en la que una persona interactúa con la
información digital a través de un entorno gráfico de simulación.
o. Biztalk Server: Servicio producido por Microsoft el cual provee las funciones de
automatización de procesos de negocio, modelamiento de procesos de negocio,
52
comunicación Business to business, integración de aplicaciones empresariales y
administración de mensajes.
p. CONICIT: Consejo Nacional de Investigaciones Científicas y Tecnológicas.
En todo estudio o investigación se opta por conveniente buscar el apoyo en una Metodología
como una herramienta que facilita el desarrollo de la investigación, como es el caso de este
enfoque, donde se considera el uso de una metodología estructural para dar soporte al
desarrollo completo con el fin de lograr el objetivo planteado.
53
CAPÍTULO III
INTERVENCIÓN METODOLÓGICA
El presente capítulo se centra en la aplicación de la Metodología de Desarrollo de Sistemas,

una metodología estructurada que permite usar las salidas de las etapas precedentes, como
entradas en las etapas sucesivas, y facilita corregir cualquier error detectado o llevar a cabo
mejoras en las distintos etapas que se generan a lo largo de la aplicación. Esta metodología
está orientada al desarrollo de proyectos que básicamente comprende cinco fases, que se
desarrollarán para formular una mejora en la automatización de procesos en APM Terminals
Callao S.A. para ello se evaluará los requerimientos propuestos por el usuario, seguido por el
análisis que consiste en relevar la información actual y proponer rasgos generales de la
solución, con el fin de diseñar una estructura para el desarrollo del proyecto. En la fase de
construcción se inicia con el desarrollo de la aplicación, al culminarla se realizan las pruebas
respectivas para pasar a producción y asegurarse del correcto funcionamiento de acuerdo al
requerimiento del usuario y el uso del mismo.
3.1. DEFINICIÓN DE REQUERIMIENTOS

Los requerimientos se han definido en función a las necesidades del usuario y el
planteamiento del problema, así como la definición del sistema de referencia, llegando
a establecer el objetivo principal: “Implementar un servicio de integración con BizTalk
Server 2013, que optimice y controle la comunicación entre los sistemas ACCESS
CONTROL SYSTEMS, NAVIS N4, DBIS COMMTRAC y NOMBRADA, logrando reducir
los reclamos de los usuarios de APM TERMINALS y automatizando los procesos
involucrados”.
La empresa APM Terminals ha considerado los siguientes requerimientos:

 Implementar una arquitectura de servicios con Microsoft BizTalk 2013.
 Implementar las diferentes interfaces entre las aplicaciones de software
involucradas.
54
 Garantizar el correcto funcionamiento de la solución con la ejecución de las
pruebas de calidad.
3.1.1. Alcances del servicio
Implementar las orquestaciones descritas en el alcance del servicio con las

siguientes características:
 Los sistemas origen proveerán servicio web, procedimientos

almacenados o archivos que generarán la información para ser enviado
a los sistemas destino.
 Los sistemas destino proveerán servicio web, procedimientos

almacenados o mecanismos internos que harán uso de la información
recepcionada.
 Las interfaces debe poder ser configurables tanto en horario como en

el número de veces que se ejecutará.
 Las interfaces deben proveer un status del proceso y grabar un log de

errores.
 Las interfaces deben proveer información histórica del proceso.
3.1.2. Definición requerimiento por interfaces
A continuación se detalla los requerimientos que deben ser resueltos por cada
interfaz.
A. Interfaz Horarios
La interfaz de Data Maestra Estibadores debe tener las siguientes

características:
 Orquestación en un solo sentido de información de Estibadores

desde el Sistema Nombrada a ACS.
 La información de estibadores es provista por el sistema Nombrada

a través de un procedimiento almacenado que publica la lista de
trabajadores nombrados por día y turno.
55
Tabla N° 3.1:
Esquema de envío de datos
Nombre de
Descripción Tipo Longitud Ejemplo
la columna
DNI DNI del trabajador portuario Varchar 250 25571062
Fecha de la NOMBRADA, formato
Fecha UTC Datetime 4/28/2013
Indicará el turno: Primer,
Turno Segundo, Tercero Int 1, 2 ó 3
Fuente: APM Terminals Callao SA
 El Sistema ACS publica un servicio web para actualizar la

información.
 La orquestación debe ejecutar el procedimiento almacenado
provisto por Nombrada. La información devuelta por este
procedimiento almacenado es enviada al sistema de ACS usando
el servicio web provisto por este sistema.
B. Interfaz Asistencia
La interfaz de procesos que comunique al Sistema de Control de Acceso y
el Sistema Nombrada, que envía la información de asistencia o Data
Maestra Estibadores, debe tener las siguientes características:
 Orquestación en un solo sentido de información de marcación de

asistencia, desde el ACS a la Nombrada
 La información de Estibadores es provista por el ACS como un
servicio web con la siguiente estructura:
Tabla N° 3.2:
Esquema de envío de datos de asistencia
Nombre de Descripción Tipo Longitud Ejemplo
la columna
Fecha Fecha inicio, formato UTC Datetime 28/08/2013
inicio
Hora inicio Hora de inicio, formato UTC String 5 08:00
Fecha final Fecha Fin, formato UTC Datetime 28/08/2013
ReaderID Número de identificación interna del int 1
panel.
PanelID Número de identificación interna de int 2
lectora.
TypeID Número de identificación interna del int 1
tipo Badge del cual se desea obtener el
reporte.
Fuente: APM Terminals Callao SA
56
 El Sistema Nombrada usa un procedimiento almacenado para
cargar la información de las personas que asistieron, actualizando
la asistencia en la boleta de NOMBRADA.
 La orquestación invoca el servicio web provisto por ACS. La

información devuelta por el servicio web es enviada al sistema
NOMBRADA usando el procedimiento almacenado provisto por
este sistema.
C. Interfaz Choferes
La interfaz entre el Sistema de Control de Acceso hacia los sistemas N4

NAVIS y DBIS COMMTRAC debe tener las siguientes características.
 Orquestación en un solo sentido de información de Choferes desde

el ACS al N4 NAVIS y DBIS COMMTRAC.
 Orquestación en un solo sentido de información de Choferes desde

el ACS al N4 NAVIS y DBIS COMMTRAC.
 La orquestación debe invocar un servicio web que devuelve la lista

de choferes provistos por el sistema ACS.
 En base a la información del ACS la orquestación devuelve la

información de Choferes en archivos xml (N4 NAVIS) y csv (DBIS
COMMTRAC).
 La orquestación genera el archivo SNX (XML personalizado),

donde el sistema N4 NAVIS lo toma desde un FileServer
configurado.
 La orquestación genera el archivo CSV (archivo plano), donde el

sistema DBIS COMMTRAC lo toma desde un FileServer
configurado.
 El Sistema N4 y DBIS COMMTRAC carga los archivos utilizando

su rutina de carga automática.
57
D. Interfaz Camiones
La interfaz entre el Sistema de Control de Acceso hacia los sistemas N4
NAVIS y DBIS COMMTRAC debe tener las siguientes características.
 Orquestación en un solo sentido de información de Camiones

desde el ACS al N4 NAVIS y DBIS COMMTRAC.
 La orquestación debe ejecutar dos procedimientos almacenados
provistos por el ACS
 La información de Camiones es provista por el ACS en archivos xml
(N4 NAVIS) y csv (DBIS COMMTRAC).
 La orquestación genera un archivo SNX (XML personalizado) en
base al archivo anterior, para el caso de N4 NAVIS.
 Los archivos son transferidos desde el directorio del File Server
origen al directorio del File Server destino del N4 NAVIS Y DBIS
COMMTRAC.
 El Sistema N4 NAVIS y DBIS COMMTRAC cargan los archivos
utilizando su rutina de carga automática para ambos archivos.
3.1.3. Relación de las necesidades identificadas con los requerimientos

Se lista los requerimientos conforme a las necesidades identificadas, donde hay
algunos requerimientos que implican desarrollo, y la gran mayoría es cubierta
por la herramienta BizTalk Server 2013, y dentro de sus ventajas permite
controlar, manejar transacciones, manejo de errores en los procesos y estados
de hidratación y deshidratación de procesos (orquestaciones) para no afectar el
performance del servidor.
Tabla N° 3.3:
Lista de requerimientos identificados
Requerimientos a Requerimientos incluidos en el

Necesidades identificadas
desarrollar producto
Desarrollar un esquema integrado
que permita automatizar las
interfaces de intercambio de
información necesarias entre los
Esquema flexible de
siguientes sistemas de información:
mantenimiento de las interfaces
ACCESS CONTROL SYSTEMS,
entre los sistemas informáticos.
NAVIS N4, DBIS COMMTRAC y
NOMBRADA. Este esquema debe
ser fácilmente adaptable a múltiples
aplicaciones e interfaces.
Capacidad para soportar el Tener la capacidad para soportar el
crecimiento de información de crecimiento de información de
transferencia entre aplicaciones. transferencia entre aplicaciones.
58
Esquema de notificaciones vía Establecer un esquema basado en
correo electrónico ante notificaciones vía correo electrónico
situaciones excepcionales. ante situaciones excepcionales.
Capacidad de informar
Informar detalladamente los eventos
detalladamente los eventos del
del sistema y el uso de recursos
sistema y el uso de recursos
técnicos, además de supervisar la
técnicos, además de supervisar
situación actual del servicio.
la situación actual del servicio.
Capacidad de recuperación de
Recuperar transacciones no
transacciones no concluidas
concluidas debido a problemas de
debido a problemas de los
los procesos.
procesos.
Infraestructura de integración de
Transferir la información de manera
procesos de transferencia de
confiable y segura.
información confiable y segura.
Capacidad de integrar reglas de
Desarrollo de Integrar las reglas de negocio como
negocio o validaciones dentro de
orquestaciones. parte de los procesos de integración.
las interfaces de transferencia.
Establecer un esquema
Ejecución de procesos de procesos
configurables, en horario y en configurables, respecto al
número de veces de ejecución horario y al número de
en un tiempo determinado. veces que serán
ejecutados, en un tiempo
determinado.
Capacidad de manejo de
Establecer un esquema que control
estados de procesos y un log de
y el log de errores.
errores.
Capacidad de proveer
Mediante la consola de
información histórica de los
administración de BizTalk.
procesos ejecutados.
Control de la transferencia de la Mediante la consola de
información. administración de BizTalk.
Fuente: APM Terminals SAC.

Elaboración: Propia.
Después de analizar la relación entre las necesidades identificadas y los

requerimientos, se tiene una visión más clara de lo que se va desarrollar y las
herramientas que serán utilizadas, todo esto con el objetivo de lograr cubrir las
necesidades del cliente de acuerdo a los requerimientos solicitados.
3.2. ANÁLISIS Y DISEÑO

La presente consiste en implementar un puente de integración (Middle-Ware) como lo
recomiendan las mejores prácticas de integración de aplicaciones empresariales (EAI),
este puente integrará las aplicaciones existentes en APM Terminals. Dicho puente es
soportado por BizTalk Server 2013, el cual maneja los siguientes servicios de
integración:
 Servicio de recepción de mensajes (conectividad heterogénea, síncrona y
asíncrona).
 Servicio de direccionamiento de los mensajes.
59
 Servicio de transformación de mensajes.
 Servicio de entrega de los mensajes (conectividad heterogénea, síncrona y

asíncrona).
 Servicio de Orquestación (Permite ejecutar los 4 servicios anteriores en forma

coherente para lograr la integración).
Considerando los requerimientos de APM TERMINALS, se propone desarrollar una

plataforma de integración de procesos que orqueste los diferentes servicios
mencionados anteriormente.
Las ventajas técnicas que proveerá el servicio de integración, son las siguientes:
 Integración con Web Services (SOA)
 Uso de motores de reglas de negocio.
 Uso de herramientas para análisis de procesos y de la información transferida

entre las aplicaciones.
La solución completa está soportada en los servicios BizTalk Server 2013, los cuales
incluyen múltiples características de administración, seguimiento, control y
monitorización de los procesos de integración que se encuentren en ejecución. Estas
características permitirán realizar el análisis de los procesos de integración a
implementar como parte del ciclo de vida del negocio en APM TERMINALS.
De manera específica, la solución propuesta brindará lo siguiente:
 Punto único y centralizado de integración de procesos entre las diferentes

aplicaciones de APM TERMINALS.
 Servicio para proveer información histórica del proceso y reportes de control de

la transferencia de la información.
 Esquema para identificar problemas que se puedan presentar, generando un log

de errores.
La solución propuesta contiene los siguientes módulos:
 BizTalk Server Administrator Console
 BizTalk Server Configuration Console
60
3.2.1. Análisis y diseño de procesos
Para tener una visión general respecto a los procesos en el control de accesos,
se realiza un mapeo de procesos donde se observan los componentes y sus
relaciones principales. Esto se realiza con el fin de conocer cómo se llevan a
cabo las actividades antes de la implementación del servicio de integración de
sistemas, mejorar los procesos, crear formas diferentes de trabajo al
presentarse algún tipo de problema. Para lograr esto se identificaron tres
procesos para el control de acceso a APM Terminals que se detallan a
continuación:
3.2.1.1. Proceso de registro de horarios

Este proceso comprende desde el envío de la lista de trabajadores
(estibadores) hasta que el personal de seguridad recepciona dicha
lista. En el gráfico N° 3.1 se muestra el proceso de envío de horarios
para el control de los estibadores.
Gráfico N° 3.1:
Mapeo del proceso de registro de horarios

61
Del gráfico anterior, el proceso se inicia cuando la empresa de
administración de recursos humanos envía con 48 horas de
anticipación y a través de un correo electrónico la relación de
trabajadores que laborarán en una determinada fecha y turno, esta
lista es supervisada por el gerente encargado y en caso éste observe
alguna inconsistencia la lista es retornada a la empresa de
administración de recursos humanos para su corrección o
actualización respectiva, pero si la lista autorizada se envía al área de
operaciones para el ingreso de los datos al sistema de Nombrada,
después de ingresados los datos, las listas de estibadores son
enviados al personal de seguridad para su custodia respectiva.
Después de haber detallado el proceso de registro de horario, a

continuación en la tabla N° 3.4 se especifica las actividades que son
realizadas de forma manual o ejecutadas por el sistema.
Tabla N° 3.4:
Nivel de automatización del proceso de registro de horarios
PROCESO ACTIVIDADES SISTEMA O CALCULOS
MANUAL
Enviar lista de Manual
estibadores
Proceso de Autorizar lista por Manual Total # de actividades = 5
registro de gerente # Actividades x Sistema = 1
horarios. Ingresar datos de Manual/Sistema Nivel de = 1*100/5=20%
horarios a automatización
Nombrada
Enviar lista a ACS Manual
Recepción de lista Manual
Nivel de automatización 20%
Fuente: Análisis de procesos en APM Terminals
De la tabla mostrada se puede observar que el nivel de automatización

del proceso de horarios es el 20%, donde la mayor parte de las
actividades se llevan a cabo de forma manual, esto implica estar
propensos a incurrir en errores.
3.2.1.2. Proceso de control de asistencia

El proceso de control de asistencia comprende esencialmente el
registro del ingreso de los estibadores al puerto en el turno y día
especificado en el proceso anterior. En el gráfico N° 3.2 se muestra el
mapeo del proceso de control de asistencia.
62
Gráfico N° 3.2:
Mapeo de procesos del control de asistencia

Del gráfico anteriormente mostrado se desprende que el proceso se

inicia cuando el estibador se presenta a laborar y para su ingreso debe
portar su documento de identidad con el personal de seguridad, este
último valida la autenticidad de los documentos y en caso no cumpla
con las condiciones requeridas se deniega el acceso, pero si el
documento de identidad es válido se procede a verificar si está
registrado en la relación de horarios para la fecha y turno en el que se
está presentando, si la verificación es válida se registra la asistencia
del estibador y permite el ingreso para dar inicio a sus labores, pero
en caso de que no se encuentre registrado en la lista, el personal de
seguridad envía una solicitud a través de un correo electrónico al área
de operaciones para realizar las coordinaciones, en tanto el área de
operaciones recepciona la solicitud y valida el ingreso del personal, en
caso sea afirmativo responde a través de un correo electrónico
indicando el motivo y sustento de la autorización, el personal de
63
seguridad recepciona la autorización y registra la asistencia y permite
el ingreso de estibador. En el caso de que el área de operaciones no
autorice el ingreso, el personal de seguridad deniega el acceso al
estibador.
Se concluye que para ingresar al terminal portuario, se debe cumplir
con las especificaciones y procedimientos respectivos, tanto para el
personal que labora en las instalaciones de APM Terminals como para
los usuarios o empresas importadoras y exportadoras, ya que ellos
envían camiones con sus respectivos choferes para hacer la carga o
descarga de una nave.
Después de haber detallado el proceso de control de asistencia, a
continuación en la tabla N° 3.5 se especifica las actividades que son
realizadas de forma manual o ejecutadas por el sistema.
Tabla N° 3.5:
Nivel de automatización del proceso de control de accesos
MANUAL
Presentar Manual
Documentos de
identificación
Validar identidad Manual
Verificar en lista de Manual Total # de actividades = 9
horarios # Actividades x Sistema = 0
Proceso de Registrar Manual Nivel de automatización =
control de asistencia 0*100/9 = 0%
asistencia. Permitir ingreso Manual
Enviar solicitud de Manual
ingreso
Recepciona Manual
solicitud
Autorizar ingreso Manual
Recepción de Manual
autorización

del proceso de control de asistencia es el 0%, donde todas las
actividades se llevan a cabo de forma manual sin contar con la
intervención de un sistema para llevar a cabo este proceso.
64
3.2.1.3. Proceso de registro de choferes y camiones
Este proceso se da con el objetivo de registrar a los choferes y
camiones que pueden ingresar al puerto. Para una mejor comprensión
del proceso se elaboró el mapa de procesos, tal como se muestra en
la gráfica N° 3.3.
Gráfico N° 3.3:
Mapa de procesos del registro de choferes y camiones.

Del gráfico anterior se detalla el ingreso de camiones y choferes,

donde el usuario o empresa envió los datos de choferes y camiones a
la oficina de control de accesos con 48 horas de anticipación, la oficina
de control de accesos recepciona la información y verifica si es
correcta, en caso sea afirmativo verifica si corresponde a un servicio
de carga general para poder registrarlo en el sistema de DBIS
COMMTRAC o sea un servicio de carga de contenedor (se tiene dos
tipos de carga: Carga General y Carga Contenedor) para ser
registrado en el sistema de NAVIS N4. En el caso de que la
información enviada por el usuario no es correcta, su solicitud de
ingreso es denegada sin lugar a reclamo hasta presentar los datos
correctos de acuerdo a los lineamientos del terminal portuario.
Después de haber detallado el proceso de registro de choferes y
camiones, a continuación en la tabla N° 3.6 se especifica las
actividades que son realizadas de forma manual o ejecutadas por el
sistema.
65
Tabla N° 3.6:
Nivel de automatización del proceso de registro de choferes y camiones
PROCESO ACTIVIDADES SISTEMA O CÁLCULOS
MANUAL
Enviar documentos choferes Manual
y vehículos
Recepcionar documentos de Manual Total # de actividades = 5
choferes y vehículos # Actividades x Sistema = 0
Proceso de Validar documentos Manual Nivel de automatización =
control de Registrar datos en NAVIS Manual 0 *100/5 = 0%
asistencia. N4
Registrar datos en DBIS Manual
COMMTRAC

del proceso de registro de choferes y camiones es el 0%, donde todas
las actividades se llevan a cabo de forma manual sin contar con la
intervención de un sistema para llevar a cabo este proceso.
Después de definir los procesos que serán automatizados, se puede

concluir que a través del mapa de procesos se puede percibir errores
en cuanto a la recolección de información, desarrollo de actividades
innecesarias que fácilmente pueden ser automatizadas, para mejorar
la eficiencia del trabajo y obtener un mejor resultado final. Entonces se
ha visto por conveniente diseñar interfaces que comuniquen los
sistemas y permita automatizar los procesos y en la tabla N° 3.7 se
muestra a los sistemas que se comunicaran y los procesos
involucrados.
Tabla N° 3.7:
Los sistemas origen y destino de integración
Proceso Interfaz Origen Destino
ACS NAVIS N4 COMMTRAC NOMBRADA
Proceso de registro de Camiones ACS NO SI NO NO
choferes y camiones
Proceso de registro de Choferes ACS NO SI NO NO
choferes y camiones
Proceso de registro de Horarios NOMBRADA SI NO NO NO
horarios
Proceso de control de Asistencia ACS NO NO NO SI
asistencia.
66
De la tabla anterior se puede apreciar los tres procesos existentes para
el control de accesos y las interfaces que se implementaron para
comunicar los sistemas existentes en APM Terminals y así de esta
manera automatizar dichos procesos.
3.2.1.4. Flujo de la interfaz de horarios

Este flujo se encarga de replicar la información de los datos del horario
de estibadores del sistema Nombrada hacia el sistema ACS (Access
Control System – On Guard).
El proceso se inicia cuando el demonio ejecuta el procedimiento
almacenado BTSPROCSELHOR001, del cual se obtiene la lista de
horarios de los trabajadores de acuerdo al turno en el que el estibador
debe ingresar, así mismo a cada registro nace con un estado inicial “0”
(Estado: Pendiente 0, pasa al Entregado ”1”). Al iniciar la
orquestación el estado es cambiado a “1” automáticamente.
La lista obtenida se almacena en la tabla Log_BTSNombradaACS,
como un histórico de los valores enviados al WebService. La lista
generada de forma global de la consulta al procedimiento almacenado
será disgregado a través de un esquema intermedio para obtener el
registro de cada estibador; una vez obtenidos los registros
individuales, BizTalk® mediante los adaptadores de envío y a través
de la orquestación consumirá el servicio web “WebServiceNombrada”,
activando el acceso en el sistema ACS para cada estibador.
En la tabla N° 3.8 se muestran los diferentes tipos de estado para el
campo EstadoEnvioOnGuard de la tabla BoletaNombradaDetalle,
campo que es actualizado de acuerdo a la respuesta obtenida del
servicio web.
Tabla N° 3.8:
Estados de envío de datos hacia el sistema Nombrada
Estado de Valor
envío
Pendiente 0
Entregado 1
Procesado 2
Error Tipo 1 3
Error Tipo 2 4
67
De la tabla se tiene como consideración que en caso se presentara
registros No Procesados en el sistema ACS, se almacenará una lista
de los DNI’s de los estibadores e identificado como error, para su envío
al administrador de las interfaces.
La orquestación de la interfaz se muestra en el gráfico N° 3.3, donde

el inicio del flujo de la interfaz es a través del procedimiento
almacenado BTSPROCSELHOR001 y culmina con el envío de
información al servicio web, teniendo en cuenta que en caso de
presentarse algún tipo de error, será notificado a través de un mail.
68
Gráfico N° 3.4:
Flujo de proceso de la interfaz de Horarios.
Begin
Obtiene la lista de horaios

de trabajadores (estado =1, trabajo tomado)
BTSPROCSELHOR001 (Nombrada)
Try
Transformación
Data of Interest BTSPROCSELHOR001 a HoraBTS
NAME TYPE MAX LEN
Se obtiene el
IDInstance de la orq.
Transformación BTSPROCSELHOR001 , HoraBTS a

Log_Log_BTSNombradaACS
Inserta el Log de los paremetros

enviados al WS en Log_BTSNombradaACS
Inicializa variables
Conteo de registros
iCountHorarios= N° de registros devueltos por SP
iContador=1
iNumber=0
bError=false
Loop
iContador <= iCountHorarios

Continue
Se asigna mensaje
BtsprcselHor001_Res(iContador) a un
Mensaje Intermedio
Try
Transformación Intermedio a
WebServiceNombrada.BadgeActivation (ACS)
Inserta el horario del trabajador

WebServiceNombrada.BadgeActivation (ACS)
Transformación Intermedio,
WebServiceNombrada.BadgeActivation (ACS) a
BTSPROCUPDESTREG001(Nombrada)
Actualiza estado = 2 (satisfactorio) o

estado=3(no satisfactorio)
BTSPROCUPDESTREG001(Nombrada)
Decide
BagdeActivationResult !=1
Else
Captura los trabajadores que

No tienen horario asignado
ErrorCollection=ErrorCollection+DNI
bError=true
Catch
Obtiene la colección total de DNI’s que no tienen un horario asignado
iContador=iContador+1
Loop End
Decide
bError==true
Else
Lanza una exception, con

la colección de errores
Catch
Se captura algun error o

La colleccion de errores
Transformación
BTSPROCSELHOR001 a CorreoError
Se envia el correoError
End

69
3.2.1.5. Flujo de la interfaz de asistencia
Este flujo se encarga de replicar la información del registro de
asistencia de los Estibadores desde el sistema ACS (Access Control
System – On Guard) hacia el sistema de NOMBRADA.
El proceso se inicia cuando el demonio de BizTalk ejecuta el
procedimiento almacenado BTSPRCASTGET002, del cual se obtiene
los parámetros de entrada para invocar al WebServicePlanilla. (En
este caso se obtiene dos tipos de parámetros de entrada para puertas
diferentes con la combinación de IDPanel + IdReader (2,1) y (2,5))
Los datos obtenidos se almacenan en la tabla
Log_BTSACSaNombradaAsist, como un histórico de los valores
enviados al WebService. La combinación de las puertas de acceso
enviadas será consumida uno por uno a través de un esquema
intermedio para obtener el parámetro de entrada que invoque al
WebServicePlanilla, del cual obtendrá la lista de asistencia con el
rango enviado en cada puerta.
La lista total de asistencia generada después de invocar al
WebServicePlanilla, será disgregado a través de un esquema
intermedio para obtener la asistencia registrada de cada estibador,
una vez obtenidos los registros individuales, BizTalk mediante los
adaptadores de envío y a través del Procedimiento almacenado
BTSPROCINSAST001 actualizará la asistencia del trabajador en el
sistema de Nombrada.
Después de culminar el proceso con éxito se realiza la actualización
de la fecha del último proceso con éxito para la siguiente llamada al
WebServicePlanilla con la fecha del último proceso ejecutado
correctamente con el procedimiento BTSPRCASTUPD001, en la tabla
BTSTBLPRCASIST002.
Si ocurriera cualquier error dentro de la orquestación, será notificada
a través del mail. Los correos serán enviados a las cuentas
establecidas.
La orquestación detallada de la interfaz se muestra en el gráfico N°
3.4, donde el inicio del flujo de la interfaz es a través del procedimiento
almacenado BTSPRCASTGET002, culminando con el envío de
información al sistema Nombrada.
70
Gráfico N° 3.5:
Flujo de proceso de la interfaz de Asistencia
Begin
Try
Obtiene los parámetros de entrada

Para obtener la relación de asistencia
BTSPRCASTGET002 (BD_MIDBiztalk)
Data of Interest
NAME TYPE MAX LEN
Inicializa variables
Conteo de registros
iContIniAst= N° de registros devueltos por SP
iContador1=1
Transformación
BTSPRCASTGET002 a LogAsistencia
Se obtiene el
Transformación BTSPRCASTGET002 , LogAsistencia a

Log_BTSACSaNombradaAsist
Inserta el Log de los parámetros

enviados al WS en Log_BTSACSaNombradaAsist
Transformación BTSPRCASTGET002 a
Btsprcastupd001Ast
Loop
iContado1r <= iContIniAst

Se asigna mensaje
Btsprcastget002 _Res(iContador1) a un Continue
Mensaje Intermedio
Transformación Intermedio a
WebServicePlanilla.Report (ACS)
Ingresa los valores para obtener

La lista de la asistencia del
WebServicePlanilla.Report (ACS)
Conteo de registros
iContAst= N° de registros devueltos del
WebServicePlanilla
iContador=1
Loop
Se asigna mensaje iContador <= iContAst

Msg_WsReportAst _Res(iContador) a un Continue
Mensaje Intermedio
Ingresa los valores para invocar al SP

BTSPROINSAST001
Captura el DNI de los trabajadores

Try
Actualiza la asistencia del trabajador

a traves del SP
BTSPROINSAST001
Decide
ReturnValue !=1
Else
Captura los trabajadores que

No fue actualizada la asistencia
sErrorCollection=sErrorCollection+DNI
bError=true
Catch
Obtiene la colección total de DNI’s que no

fue actualizada su asistencia
iContador=iContador+1
Loop End
iContador1=iContador1+1
Actualiza la fecha del

proceso con exito
Loop End
Decide
bError==true
Else
Lanza una exception, con

la colección de errores
Catch
Se captura algun error o

La colleccion de errores
Transformación
BTSPRCASTGET002 a CorreoErrorAst
End

71
3.2.1.6. Flujo de la interfaz de choferes
Este flujo se encargará de replicar la información de los datos de
Camiones desde el sistema ACS hacia el sistema NAVIS N4 y DBIS
COMMTRAC.
El proceso se inicia cuando el demonio (propio de BizTalk) ejecuta el
procedimiento almacenado BTSPRCDRIGET001, que obtiene los
valores iniciales que servirán de entrada para obtener el reporte de
Choferes del ACCESS CONTROL SYSTEM (ACS) con el servicio web
“WebServicesN4C”. Después de recibir los valores de entrada se
inicializa una variable que contará la cantidad de registros devueltos
del servicio web con el fin de validar que la llamada al servicio web no
devuelva registro alguno. Una vez obtenidos los registros, BizTalk
mediante los adaptadores de envío y la orquestación consumirán el
Servicio Web, estos datos serán transformados y enviados a través de
los mensajes, para generar un archivo SNX y XML personalizado, los
que a su vez serán llevados a una ruta donde se insertarán los datos
en el sistema NAVIS N4 y DBIS COMMTRAC a través de la rutina de
carga automática.
El archivo SNX es enviada a la ruta especificada
\\10.51.12.99\customers_snx\driver y el xml personalizado es enviado
a la ruta \\10.51.12.99\customers_snx\truck.
Finalmente se actualiza los parámetros de entrada para la siguiente
llamada al servicio web con la fecha del último proceso ejecutado
correctamente con el procedimiento BTSPRCDRIUPD001, en la tabla
BTSTBLPRCDRI001. Asimismo se almacena los parámetros de
entrada con las que se invocó el servicio web en la tabla
Log_BTSACSaN4CommtracDriver.
Si se presentara algún error durante el proceso, dentro de la
orquestación se cuenta con un manejador de excepciones, donde el
error generado será enviado en un mail a los correos configurados en
el puerto. La orquestación detallada de la interfaz se muestra en el
gráfico N° 3.5, donde el inicio del flujo de la interfaz es a través del
procedimiento almacenado BTSPRCDRIGET001, culminando con el
envío de información a los sistemas NAVIS N4 y DBIS COMMTRAC.
72
Gráfico N° 3.6:
Flujo de proceso de la interfaz de choferes
Begin
Recibir
JOB de Drivers
(BTSPRCDRIGET001)
Inicializa variable
iContador=0
Transformación
BTSPRCDRIGET001 a
WebServiceN4.WsLastUpdated(ACS)
Data of Interest
NAME TYPE MAX LEN
Obtener los lista de Drivers
WebServiceN4.LastUpdate(ACS)
Conteo de registros
iContador = N° de registros devueltos por el WS
Transformación
BTSPRCDRIGET001 a BTSPRCDRIUPD001
Decide
iContador>0
Else
Transformación
WebServiceN4.LastUpdate(ACS) a
DriversN4 (N4)
Archivo generado DriversN4.xml

Se deja en la ruta establecida
Transformación
DriversDBIS (DBIS)
Archivo generado DriversDBIS .txt

Transformación
BTSPRCDRIGET001 a LogDriver
Se obtiene el
Transformación BTSPRCDRIGET001, LogDriver a

Log_BTSACSaN4CommtracDriver
Se inserta el log de proceso

Log_BTSACSaN4CommtracDriver (BTS)
Se actualiza el parametro inicial Fecha

BTSPRCDRIUPD001 (BTS)
Catch
Se captura el error
Transformación
BTSPRCDRIGET001 a CorreoErrorDri
End

73
Consideraciones:
El llamado al servicio web “WebServicesN4C” se realiza con los
parámetros obtenidos de la tabla de control BTSTBLPRCDRI001
donde:
Fecha de Proceso: Indica la última fecha de ejecución exitosa del
servicio web.
Delay del Proceso: Es el tiempo que se le descuenta a la última fecha

de proceso registrado para la siguiente ejecución.
Tipo de registro: Es un parámetro que indica que la lista que se está

solicitado es la de choferes.
Asimismo cabe resaltar que el máximo tamaño de los mensajes es

1,001,023 (bytes) que se encuentra configurado para el puerto que es
usado por el servicio web, que tiene el siguiente nombre
DRI_wsLastUpdated_WCFBasicHttp.
3.2.1.7. Flujo de la interfaz de camiones

Este flujo se encargará de replicar la información de los datos de
Camiones desde el sistema ACS (Access Control System – On Guard)
hacia el sistema NAVIS N4 y DBIS COMMTRAC.
El proceso se inicia cuando el demonio (propio de BizTalk) ejecuta el
procedimiento almacenado BTSPRCTRUGET001, que obtiene los
valores iniciales que servirán de entrada para obtener el reporte de
camiones del ACCESS CONTROL SYSTEM (ACS) con el servicio
web “WebServicesN4C”. Después de recibir los valores de entrada se
inicializa una variable que contará la cantidad de registros devueltos
del servicio web con el fin de validar que la llamada al servicio web no
devuelva registro alguno. Una vez obtenidos los registros, BizTalk®
mediante los adaptadores de envío, la orquestación consumirá el
Servicio Web, estos datos serán transformados y enviados a través de
los mensajes, para generar un archivo SNX y XML personalizado, los
que a su vez serán llevados a una ruta donde se insertarán los datos
74
en el sistema NAVIS N4 y DBIS COMMTRAC a través de la rutina de
carga automática.
El archivo SNX es enviada a la ruta especificada
\\10.51.12.99\customers_snx\truck y el xml personalizado es enviado
a la ruta \\10.51.12.99\customers_snx\truck .
Finalmente se actualiza los parámetros de entrada para la siguiente
llamada al servicio web con la fecha del último proceso ejecutado
correctamente con el procedimiento BTSPRCTRUUPD001, en la
tabla BTSTBLPRCTRU001. Asimismo se almacena los parámetros de
entrada con los que se invocó al WebService en la tabla
Log_BTSACSaN4CommtracTrucks.
Si se presentara algún error durante el proceso, dentro de la
orquestación se cuenta con un manejador de excepciones, donde el
error generado será enviado en un mail a los correos configurados en
el puerto.
Consideraciones:
El llamado al servicio web “WebServicesN4C” se realiza con los
parámetros obtenidos de la tabla de control BTSTBLPRCTRU001,
donde:
Fecha de Proceso: Indica la última fecha de ejecución exitosa del
servicio web.
Delay del Proceso: Es el tiempo que se le descuenta a la última fecha

de proceso registrado para la siguiente ejecución.
Tipo de registro: Es un parámetro que indica que la lista que se está

solicitado es la de camiones.
La orquestación detallada de la interfaz se muestra en el gráfico N°

3.6, donde el inicio del flujo de la interfaz es a través del procedimiento
almacenado BTSPRCTRUGET001 y culmina con el envío de los
archivos generados a la ruta definida por el usuario, teniendo en
cuenta que en caso de presentarse algún tipo de error, será notificado
a través de un mail.
75
Gráfico N° 3.7:
Flujo de proceso de la interfaz de Camiones
Begin
Recibir
JOB de Trucks
(BTSPRCTRUGET001)
Inicializa variable
iContador=0
Transformación
BTSPRCTRUGET001 a
WebServiceN4.WsLastUpdated(ACS)
Data of Interest
NAME TYPE MAX LEN
Obtener los lista de Trucks
WebServiceN4.LastUpdate(ACS)
Conteo de registros
iContador = N° de registros devueltos por el WS
Transformación
BTSPRCTRUGET001 a BTSPRCDRIUPD001
Decide
iContador>0
Else
Transformación
TrucksN4 (N4)
Archivo generado TrucksN4.xml

Transformación
TrucksDBIS (DBIS)
Archivo generado TrucksDBIS .txt

Transformación
BTSPRCTRUGET001 a LogTrucks
Se obtiene el
Transformación BTSPRCTRUGET001, LogTrucks a

Log_BTSACSaN4CommtracTrucks
Se inserta el log de proceso

Log_BTSACSaN4CommtracTrucks(BTS)
Se actualiza el parametro inicial Fecha

BTSPRCTRUUPD001 (BTS)
Catch
Se captura el error
Transformación
BTSPRCTRUGET001 a CorreoErrorTru
End

76
3.2.2. ANÁLISIS Y DISEÑO DE DATOS
El motor de una orquestación provee una arquitectura para integrar o
intercambiar mensajes, estos mensajes pueden ser transformados al pasar del
sistema origen hacia el sistema destino de forma directa o ciertos cambios de
acuerdo al formato requerido por el destinatario, esta transformación se logra
a través de componentes internos de Biztalk Server, que se adaptan al uso que
se le puede asignar.
Una orquestación coordina y planifica el procesamiento de los mensajes y
realiza la lógica compleja sobre ellos a medida que pasan por un flujo definido.
A continuación se especifica los mensajes creados para el intercambio de
información, además la transformación de los esquemas por cada interfaz.
3.2.2.1. Interfaz de horarios

La orquestación diseñada para la interfaz de horarios cuenta con los
siguientes mensajes y transformaciones, que forman parte del flujo de
trabajo:
A. MENSAJES:
 El objeto de nombre BTSPROCSELHOR001, es un
procedimiento almacenado de la base de datos “Bd_Nombrada”,
que obtiene la lista de los trabajadores, por su diseño y
funcionalidad no posee entradas, pero si contiene los campos de
salida tal como se muestra en la Tabla N° 3.9
Tabla N° 3.9:
Campos contenidos en el mensaje Btsprocselhor001
Nombre del Objeto : BTSPROCSELHOR001

Tipo de objeto : Store Procedure
Base de Datos : Bd_Nombrada
Nombre del Paquete : DBO
Campos de Entrada:
Campo Tipo Dato Long. Detalle
Campos de Salida:
DNI String Número de documento de identificación.
Fecha_de_Inicio_Turno String Fecha de activación del nivel de acceso.
Formato “YYYY-MM-DD”
77
Hora_de_Inicio_Turno String Hora de activación del nivel de acceso.
Formato “(HH24:MM:SS)”
Fecha_de_Fin_Turno String Fecha de desactivación del nivel de
acceso. Formato “YYYY-MM-DD”
Hora_de_Fin_Turno String Hora de desactivación del nivel de
acceso. Formato “(HH24:MM:SS)”
CodTurno Int Código del turno
FechaTurno String Fecha del turno

De la tabla mostrada se observa que los campos de salida

contienen los datos de los estibadores, está información será
obtenida en cada uno de los tres turnos establecidos, para
verificar el acceso de un estibador a sus labores.
 El objeto de nombre BTSPROCUPDESTREG001, es un

procedimiento almacenado de la base de datos “Bd_MIDBiztalk”,
que actualiza el estado del registro con los campos que se
muestran en la tabla N° 3.10
Tabla N° 3.10:
Campos contenidos en el mensaje Btsprocupdestreg001
Nombre del Objeto : BTSPROCUPDESTREG001

Tipo de objeto : Store Procedure
Base de Datos : Bd_MIDBiztalk
Campos de Entrada:
FechaTurno Datetime Fecha de turno
CodTurno Int Código de turno
DNI String 20 Número de DNI
Valor Int Estado de envío (0,1,2)
Campos de Salida:
ReturnValue Int Respuesta del procedimiento


contienen los datos de los estibadores, esta información será
78
obtenida en cada uno de los tres turnos establecidos, para
verificar el acceso de un estibador a sus labores.
 El objeto de nombre BadgeActivation, es uno de los métodos del

servicio web “WebServiceNombrada”, al invocar este método se
activa el acceso en el sistema ACS para cada estibador, con los
campos de entrada que contiene la información requerida, tal
como se observar la tabla N°3.11
Tabla N° 3.11:
Campos contenidos en el mensaje BadgeActivation
Nombre del Objeto : BadgeActivation

Tipo de objeto : WEB SERVICE
Nombre del Servicio : WebServiceNombrada
Campos de Entrada:
inDNI string Número de DNI del estibador.
FechaInicio datetime Fecha de inicio de marcación del
estibador. Formato “MM-DD-YYYY”
HoraInicio string Hora de inicio de marcación de
estibador. Formato (HH24:MM)
FechaFinal datetime Fecha final de marcación del estibador.
Formato “MM-DD-YYYY”
HoraFinal string Hora final de marcación de estibador.
Formato (HH24:MM)
IDNivel int ID del nivel de acceso correspondiente.
De acuerdo a la Descripción de Nivel:
Estibadores  “2”
Campos de Salida:
Valor:
BadgeActivationResult INT
 Error 0
 Éxito 1

De la tabla mostrada se observa que el método BadgeActivation

del servicio web tiene como salida dos valores, estos valores son
establecidos de acuerdo al resultado obtenido puede ser éxito o
error.
 El objeto de nombre Msg_Btsprcselhor001_Res_Intermedio, es

un esquema intermedio con la estructura similar al objeto
79
Btsprcselhor001, la estructura de este mensaje se muestra en la
tabla N°3.12
Tabla N° 3.12:
Campos contenidos en el mensaje Msg_Btsprcselhor001_Res_Intermedio
Nombre del Objeto : Msg_Btsprcselhor001_Res_Intermedio.xsd

Tipo de objeto : xml (schema)

DNI String Número de documento de identificación.
Fecha_de_Inicio_Turno String Fecha de activación del nivel de acceso.

Hora_de_Inicio_Turno String Hora de activación del nivel de acceso.

Fecha_de_Fin_Turno String Fecha de desactivación del nivel de

Hora_de_Fin_Turno String Hora de desactivación del nivel de

FechaTurno String Fecha del turno
De la tabla mostrada se puede resaltar que este esquema es

considerado como un mensaje de apoyo para disgregar cada
registro de la lista que se obtiene al invocar al procedimiento
almacenado BTSPROCSELHOR001, los cuales serán
enviados como parámetro de entrada al servicio web en la
interfaz de Horarios.
 El objeto de nombre InsertLog_BTSNombradaACSService, es

una tabla de la base de datos “Bd_MIDBiztalk”, en esta tabla se
almacenarán el registro(log) de los datos enviados como
parámetros de entrada al servicio web, tal como se muestra en
la tabla N° 3.13.
80
Tabla N° 3.13:
Campos contenidos en el mensaje InsertLog_BTSNombradaACSService
Nombre del Objeto : InsertLog_BTSNombradaACSService

Tipo de objeto : Tabla
Campos de Entrada:
DNI string Número de documento de identificación.
Fecha_de_Inicio_Turno string Fecha de activación del nivel de acceso.
Hora_de_Inicio_Turno string Hora de activación del nivel de acceso.
Fecha_de_Fin_Turno string Fecha de desactivación del nivel de
Hora_de_Fin_Turno string Hora de desactivación del nivel de
FechaTurno string Fecha del turno
Fecha actual (auditoria)
FechaLog string
Id de la instancia de la orquestación.
IdInstance string
Campos de Salida:

En la tabla mostrada se puede observar dos campos adicionales

a los parámetros de entrada del servicio web, estos campos son
FechaLog (Fecha actual de ejecución del proceso) y IdInstance
(Nombre único de la instancia de la orquestación) no existe
campo de salida por ser una tabla de inserción.
 El objeto de nombre LogHora, es un esquema creado para

obtener la fecha y hora actual, además del ID de la instancia de
la orquestación, la estructura de este mensaje se muestra en la
tabla N°3.14.
81
Tabla N° 3.14:
Campos contenidos en el mensaje LogHora
Nombre del Objeto : LogHora


FechaLog String Fecha de Log
IdInstance String ID de instancia de la orquestación
De la tabla mostrada se puede indicar que la fecha y hora

obtenida es capturada en el instante que se está ejecutando la
orquestación, y como segundo campo se tiene el IdInstance, que
es el nombre que diferencia a cada una de las instancias
ejecutadas en la orquestación.
 El objeto de nombre CorreoError, es un esquema creado para

obtener los datos que forman parte del correo que se envía en
caso de alguna alerta de error en la interfaz de Horarios, la
estructura de este mensaje se muestra en la tabla N°3.15
Tabla N° 3.15:
Campos contenidos en el mensaje CorreoError
Nombre del Objeto : CorreoError

Campos para generar el correo para el manejo de errores en la interfaz de

Horarios.
Asunto String Asunto del correo
HoraError String Fecha y hora en que se suscitó el error
Error String Mensaje de error.
De la tabla mostrada se puede afirmar que existen diversas formas

de manejar errores, y una de ellas es través de un correo, donde
el usuario pueda saber en tiempo real los incidentes que se
suscitan mientras se ejecuta la interfaz Horarios.
82
B. TRANSFORMACIONES
 El mapa mostrado en la tabla N° 3.16, define la relación entre el
mensaje de entrada Btsprocselhor001 y el mensaje de salida
BadgeActivation, donde existen cinco conexiones directas que
no implican una transformación.
Tabla N° 3.16:
Mapa de transformación de Btsprocselhor001 a BadgeActivation
BTSPROCSELHOR001 (Bd_Nombrada) a WebServiceNombrada - BadgeActivation
(ACS)
Origen Transformación Destino
(BTSPROCSELHOR001) (WebServiceNombrada -
BadgeActivation)
Ninguno
DNI InDNI
Ninguno
Fecha_de_Inicio_Turno FechaInicio
Ninguno
Hora_de_Inicio_Turno HoraInicio
Ninguno
Fecha_de_Fin_Turno FechaFinal
Ninguno
Hora_de_Fin_Turno HoraFinal
CodTurno
FechaTurno
Valor Fijo Valor por defecto “ 2” IDNivel
Del mapa mostrado, el enlace entre los elementos es directo, a

excepción de elemento “Valor Fijo” al cual se le asigna un valor
por defecto.

CorreoError.
Tabla N° 3.17:
Mapa de transformación de Btsprocselhor001 a CorreoError
BTSPROCSELHOR001 (Bd_Nombrada) a CorreoError (BTS)

(BTSPROCSELHOR001) (CorreoError)
DNI
Fecha_de_Inicio_Turno
Hora_de_Inicio_Turno
Fecha_de_Fin_Turno
Hora_de_Fin_Turno
83
CodTurno
FechaTurno
Por defecto : Error en Biztalk
Asunto
Captura la fecha actual
HoraError
Error
Del mapa mostrado, se observa que no existen conexiones, solo

dos elementos de valores fijos y el elemento “HoraError” que
captura la fecha y hora actual del proceso de la interfaz de
Horarios.
LogHora.
Tabla N° 3.18:
Mapa de transformación de Btsprocselhor001 a LogHora
BTSPROCSELHOR001 (Bd_Nombrada) a LogHora (BTS)

(BTSPROCSELHOR001) (LogHora)
DNI
Fecha_de_Fin_Turno
Hora_de_Fin_Turno
CodTurno
FechaTurno
FechaLog
IdInstance

dos elementos, el primer elemento “FechaLog” que captura la
fecha y hora actual del proceso de la interfaz de Horarios y el
segundo elemento “IdInstance” el cual por el momento es un
elemento vacío.
84
 El mapa mostrado en la tabla N° 3.19, define la relación
entre dos mensajes de entrada Btsprocselhor001, LogHora y el
mensaje de salida InsertLog_BTSNombradaACSService, donde
existen nueve conexiones directas que no implican una
transformación.
Tabla N° 3.19:
Mapa de transformación de Btsprocselhor001, LogHora a
InsertLog_BTSNombradaACSService
BTSPROCSELHOR001 (Bd_Nombrada) y LogHora(BTS)

a InsertLog_BTSNombradaACSService (BTS)

(Btsprocselhor001, (InsertLog_BTSNombradaACSService)
LogHora)
Ninguno
DNI DNI
Ninguno
Fecha_de_Inicio_Turno Fecha_de_Inicio_Turno
Ninguno
Hora_de_Inicio_Turno Hora_de_Inicio_Turno
Ninguno
Fecha_de_Fin_Turno Fecha_de_Fin_Turno
Ninguno
Hora_de_Fin_Turno Hora_de_Fin_Turno
Ninguno
CodTurno CodTurno
Ninguno
FechaTurno FechaTurno
Ninguno
FechaLog FechaLog
Ninguno
IdInstance IdInstance
Del mapa mostrado, se observa que el enlace entre los

elementos es directo, esto se refiere a que no existe ningún tipo
de transformación o conversión de formato del sistema origen.

entre dos mensajes de entrada
Msg_Btsprcselhor001_Res_Intermedio, BadgeActivationResult
y el mensaje de salida Btsprocupdestreg001, donde existen seis
conexiones directas y conexiones que implican una
transformación.
85
Tabla N° 3.20: Mapa de transformación de
Msg_Btsprcselhor001_Res_Intermedio, BadgeActivationResult a
BTSPROCUPDESTREG001
Msg_Btsprcselhor001_Res_Intermedio(BTS), BadgeActivationResult(ACS) a
BTSPROCUPDESTREG001(Bd_MIDBiztalk)

(Msg_Btsprcselhor001_Res_ (BTSPROCUPDESTREG001)
Intermedio,
BadgeActivationResult)
Ninguno
DNI DNI
Ninguno
Ninguno
Ninguno
Fecha_de_Fin_Turno
Ninguno
Hora_de_Fin_Turno
Ninguno
CodTurno CodTurno
Formato origen: “YYYY-MM-
FechaTurno DD HH:MM:SS” FechaTurno
Formato destino: “YYYY-MM-
DD
Valida el resultado de Web
BadgeActivationResult Services: Valor
Si: Valor origen =1
Valor Destino=2
Si: Valor origen<>1
Valor Destino= Valor origen
Del mapa mostrado, existen dos elementos que serán transformados,

el primero “FechaTurno” donde se realiza un cambio de formato de
fecha, formato que será reconocido por el mensaje destino; el segundo
elemento “BadgeActivationResult”, donde se le asigna una validación
haciendo uso de un componente, de ello se obtiene el valor que será
enviado al esquema destino.
3.2.2.2. Interfaz de asistencia

La orquestación diseñada para la interfaz de Asistencia cuenta con los
trabajo:
A. Mensajes :
 El objeto de nombre BTSPRCASTGET002, es un procedimiento
almacenado de la base de datos “Bd_MIDBiztalk”, que obtiene los
parámetros de entrada e iniciales para iniciar el flujo, como se
muestra en la tabla N° 3.21.
86
Tabla N° 3.21:
Campos contenidos en el mensaje BTSPRCASTGET002
Nombre del Objeto : BTSPRCASTGET002

Tipo de objeto : Store procedure
Campos de Entrada:
Campos de Salida:
FechaIni string Fecha desde la que se desea obtener el
reporte.
HoraIni string Hora desde la que se desea obtener el
reporte.
FechaFin int Fecha hasta la que se desea obtener el
reporte.
HoraFin string Hora hasta la que se desea obtener el
reporte.
PanelID int Número de identificación interna del
panel.
ReaderID int Número de identificación interna de
lectora.
TypeID int Número de identificación interna del tipo
Badge del cual se desea obtener el
reporte.
FechaAudit string Fecha y hora que culmina el proceso con
éxito.
Flag int Estado del ingreso de Rangos de
FechaProcesoIni y FechaProcesoFin
El valor Flag =0 si:
 FechaProcesoIni =NULL
FechaProcesoFin = NULL
El valor Flag =1 si:
FechaProcesoIni <>NULL
FechaProcesoFin <> NULL
De la tabla mostrada se observa que para la ejecución del

procedimiento almacenado no es necesario parámetros de
entrada, y los parámetros de salida son los datos necesarios
para invocar el servicio web WebServicePlanilla dentro del flujo.
 El objeto de nombre Report, como parte del servicio web
WebServicePlanilla del sistema, que obtiene la lista de
asistencia de los trabajadores como de visualiza en la tabla N°
3.22.
87
Tabla N° 3.22:
Campos contenidos en el mensaje Report
Nombre del Objeto : Report

Tipo de objeto : Web Services
Nombre de Servicio : WebServicePlanilla
Campos de Entrada:
FechaInicio datetime Fecha desde la que se desea obtener el
reporte.
reporte.
FechaFinal datetime Fecha hasta la que se desea obtener el
reporte.
reporte.
ReaderID int Número de identificación interna del
panel.
PanelID int Número de identificación interna de
lectora.
reporte.
Campos de Salida:
String – Index 1 string Fecha de Transacción.
String – Index 2 string Descripción de Transacción
String – Index 3 string Nombre de Lectora
String – Index 4 string Apellidos
String – Index 5 string Nombres
String – Index 6 string DNI
String – Index 7 string Número de Badge

contienen campos de tipo “string” con la información de la
marcación de asistencia de los trabajadores.
 El esquema con el nombre AsistenciaIntermedio, es un

mensaje interno de apoyo que es usado para disgregar cada
registro de la lista que se obtiene al invocar al servicio web
WebServicePlanilla, los cuales serán enviados como
parámetro de entrada al procedimiento almacenado
BTSPROCINSAST001. Los campos de este esquema se
muestran en la tabla N° 3.23.
88
Tabla N° 3.23:
Campos contenidos en el mensaje AsistenciaIntermedio
Nombre del Objeto : AsistenciaIntermedio


String – Index 1 string Fecha de transacción o marcación
String – Index 2 string Descripción de transacción o lugar de
marcación.
String – Index 3 string Nombre de Lectora
String – Index 4 string Apellidos del estibador.
String – Index 5 string Nombres del estibador.
String – Index 6 string DNI del estibador.
String – Index 7 string Número de Badge

De la tabla anterior se observa que los campos son de tipo String

que contienen la información de la Asistencia, proveniente del
servicio web.
 El objeto de nombre AsistenciaIntermedioIni, es un mensaje

interno de apoyo que se usa para invocar al servicio web, los
campos se muestran en la tabla N° 3.24.
Tabla N° 3.24:
Campos contenidos en el mensaje AsistenciaIntermedioIni
Nombre del Objeto : AsistenciaIntermedioIni

FechaIni datetime Fecha desde la que se desea obtener el
reporte.
reporte.
FechaFin datetime Fecha hasta la que se desea obtener el
reporte.
reporte.
panel.
lectora.
reporte.
89
FechaAudit datetime Fecha y hora que culmina el proceso con
éxito.
FechaProcesoIni y FechaProcesoFin.

De la tabla anterior se visualiza que los campos contienen fechas

y horas, los mismos que son enviados para obtener la asistencia
del sistema ACS. Este esquema almacena un par de registros,
donde básicamente se diferencia porque hacen referencia a una
determinada puerta de ingreso.
 El objeto de nombre BTSPROCINSAST001, es un

procedimiento almacenado de la base de datos “BdNombrada”,
que actualiza la asistencia del estibador en el sistema
Nombrada. Los campos se detallan en la tabla N° 3.25.
Tabla N° 3.25:
Campos contenidos en el mensaje BTSPROCINSAST001
Nombre del Objeto : BTSPROCINSAST001

Tipo de objeto : Procedimiento Almacenado
Campos de Entrada:
DNI string Número de documento de identificación.
Fecha_Hora_Acceso datetime Hora de acceso del trabajador
Campos de Salida:
ReturnValue string Confirmación de actualización de datos.
 0  Error
 1  Satisfactorio
De la tabla anterior, se observa que los datos de entrada son el

DNI y la hora de ingreso del estibador, este procedimiento es
ejecutado en el Sistema Nombrada, y tiene como salida “1”,
cuando la ejecución fue exitosa y “0” si hubo algún error.
90
 El objeto de nombre BTSPRCASTUPD001, es un procedimiento
almacenado de datos “Bd_MIDBiztalk” y tiene los siguientes
campos que se detallan en la tabla N° 3.26.
Tabla N° 3.26:
Campos contenidos en el mensaje BTSPRCASTUPD001
Nombre del Objeto : BTSPRCASTUPD001(AstProcedure)
Campos de Entrada:
FechaProcExt string Fecha del último proceso con éxito
FechaProcesoIni y FechaProcesoFin.
Campos de Salida:

De la tabla anterior, se puede apreciar que almacena datos de

fechas de procesos y estados, pues con la ayuda de este objeto
se llega a actualizar los datos de la última ejecución con éxito de
la orquestación, en la tabla BTSTBLPRCASIST002, que servirán
de control para la siguiente ejecución de la orquestación –
registro de asistencia.
 El objeto de nombre Log_BTSACSaNombradaAsist, es una

tabla que se encuentra en la base de datos “Bd_MIDBiztalk” y
tiene los siguientes campos que se detallan en la tabla N° 3.27.
Tabla N° 3.27:
Campos contenidos en el mensaje Log_BTSACSaNombradaAsist
Nombre del Objeto : Log_BTSACSaNombradaAsist
Campos de Entrada:
FechaIni string Fecha desde la que se desea obtener el
reporte.
91
reporte.
FechaFin string Fecha hasta la que se desea obtener el
reporte.
reporte.
lectora.
panel.
reporte.
FechaLog string
IdInstance string
Campos de Salida:

De la tabla anterior, se puede observar que los campos de

entrada son los mismos que son usados para invocar el servicio
web. Este mensaje permite guardar un log de datos que son
enviados para cada ejecución del servicio web.
 El esquema de nombre CorreoErrorAst, posee los siguientes
campos mostrados en la tabla N° 3.28.
Tabla N° 3.28:
Campos contenidos en el mensaje CorreoErrorAst
Nombre del Objeto : CorreoErrorAst
Campos para generar el correo para el manejo de errores en la interfaz de Asistencia.


De la tabla mostrada, se aprecia que guarda la estructura del

correo que es enviado cuando se presenta algún error en el
proceso de ejecución de la orquestación.
92
 El esquema de nombre LogAsistencia, es un objeto de apoyo,
sus campos se detallan en la tabla N° 3.29.
Tabla N° 3.29:
Campos contenidos en el mensaje LogAsistencia
Nombre del Objeto : LogAsistencia
Mensaje de apoyo para la creación del log de proceso en la interfaz de Asistencia.


De la tabla anterior se observa que se almacena la fecha del log y

así mismo el Id de la instancia de la orquestación, que finalmente
será usado al momento de guardar el log de ejecuciones del flujo
de proceso como un historial.
B. TRANSFORMACIONES:
mensaje de entrada AsistenciaIntermedioIni y el mensaje de
salida WebServicePlanilla-Report.
Tabla N° 3.30:
AsistenciaIntermedioIni (BTS) a WebServicePlanilla-Report (ACS)

(AsistenciaIntermedioIni) (WebServicePlanilla-Report)
Ninguno
FechaIni FechaInicio
Ninguno
HoraIni HoraIni
Ninguno
FechaFin FechaFinal
Ninguno
HoraFin HoraFin
Ninguno
PanelID ReaderID
Ninguno
ReaderID PanelID
Ninguno
TypeID TypeID
FechaAudit
Flag

93
Del mapa mostrado, se detalla que el pase de datos en lineal sin
alguna conversión de ningún tipo, salvo la estructura, donde se
transfieren los valores para invocar el servicio web.

mensaje de entrada AsistenciaIntermedio y el mensaje de
salida BTSPROCINSAST001.
Tabla N° 3.31:
AsistenciaIntermedio(BTS) a BTSPROCINSAST001(Bd_Nombrada)

(AsistenciaIntermedio) (BTSPROCINSAST001)
String – Index 1 Conversión de string a Fecha_Hora_Acceso
Datetime
String – Index 2
String – Index 3
String – Index 4
String – Index 5
Ninguno
String – Index 6 DNI
String – Index 7
Del mapa mostrado, se detalla que en el pase de datos se realiza

una sola conversión de tipo de datos, y se transfieren solo los
campos fecha y DNI. Este mapa participa en el registro de
Asistencia.

mensaje de entrada BTSPRCASTGET002 y el mensaje de
salida CorreoErrorAst.
Tabla N° 3.32:
BTSPRCASTGET002 (Bd_MIDBiztalk) a CorreoErrorAst (BTS)
(BTSPRCASTGET002) (CorreoErrorAst)
FechaIni
HoraIni
FechaFin
HoraFin
94
PanelID
ReaderID
TypeID
FechaAudit
Flag
Por defecto : Error Biztalk -
Asistencia Asunto
Captura la fecha actual HoraError

Por defecto : Error Error
Del mapa mostrado, se observa que no hay pase de datos del

mensaje de entrada, pero si se captura la fecha actual, y el error
generado en para el proceso de Asistencia.

mensaje de entrada BTSPRCASTGET002 y el mensaje de salida
LogAsistencia.
Tabla N° 3.33:
BTSPRCASTGET002 (Bd_MIDBiztalk) a LogAsistencia (BTS)
(BTSPRCASTGET002) (LogAsistencia)
FechaIni
HoraIni
FechaFin
HoraFin
PanelID
ReaderID
TypeID
FechaAudit
Flag
Captura la fecha actual FechaLog
IdInstance
Del mapa mostrado, se observa que no hay pase de datos del

mensaje de entrada, pero si se captura la fecha actual, y el Id de
la instancia del proceso de Asistencia, esto es para guardar un
log de procesos.
95
salida BTSPRCASTUPD001.
Tabla N° 3.34:
BTSPRCASTGET002 (Bd_MIDBiztalk) a BTSPRCASTUPD001 (Bd_MIDBiztalk)

(BTSPRCASTGET002) (BTSPRCASTUPD001)
FechaIni
HoraIni
FechaFin
HoraFin
PanelID
ReaderID
TypeID
FechaAudit
Ninguno
Flag Flag
Captura la fecha actual FechaProcExt
Del mapa mostrado, se puede decir que se guardar un flag y la

fecha del llamado al servicio web, esto para manejar la siguiente
ejecución.

salida Log_BTSACSaNombradaAsist.
Tabla N° 3.35:
BTSPRCASTGET002 (Bd_MIDBiztalk), LogAsistencia(BTS) a
Log_BTSACSaNombradaAsist (BTS)

(Btsprcastget002, (Log_BTSACSaNombradaAsist)
LogAsistencia)
Ninguno
FechaIni FechaIni
Ninguno
HoraIni HoraIni
Ninguno
FechaFin FechaFin
Ninguno
HoraFin HoraFin
Ninguno
PanelID PanelID
Ninguno
ReaderID ReaderID
Ninguno
TypeID TypeID
FechaAudit
96
Flag
Ninguno
FechaLog FechaLog
Ninguno
Del mapa mostrado, se observa que los datos pasan de forma lineal,
sin ninguna transformación de datos. Este mapa tiene la finalidad de
guardar un log de los datos procesados y la fecha de proceso, así
como el Id de instancia del proceso o Id de instancia de la
orquestación.
3.2.2.3. Interfaz de choferes

La orquestación diseñada para la interfaz de choferes cuenta con los
trabajo:
A. Mensajes:
 El objeto de nombre BTSPRCDRIGET001, es un procedimiento
almacenado de la base de datos “Bd_MIDBiztalk”, que obtiene los
valores iniciales para ejecutar el flujo de proceso de la interfaz
camiones. Los campos del mensaje se muestran en la tabla
N°3.36.
Tabla N° 3.36:
Campos contenidos en el mensaje BTSPRCDRIGET001
Nombre del Objeto : BTSPRCDRIGET001
Campos de Entrada:
Campos de Salida:
FECHA String Fecha del último proceso
HORA String Hora del último proceso
Tipo Int Tipo de registro

97
Del gráfico mostrado se observa que la ejecución del
procedimiento almacenado trae la fecha y hora de la última
ejecución del proceso, esto para iniciar el flujo a partir de estos
valores iniciales.
 El objeto de nombre BTSPRCDRIUPD001, es un procedimiento
almacenado de la base de datos “Bd_MIDBiztalk” y tiene los
siguientes campos que se detallan en la tabla N° 3.37.
Tabla N° 3.37:
Campos contenidos en el mensaje BTSPRCDRIUPD001
Nombre del Objeto : BTSPRCDRIUPD001
Campos de Entrada:
Fecha de inicio de llamada al webService.
FechaProceso DateTime
Campos de Salida:

De la tabla mostrada, se observa que se captura la fecha del

proceso, que permitirá la actualización de la fecha de ejecución
del servicio web “WebServicesN4C.LastUpdate” en la tabla de
control.
 El objeto de nombre Log_BTSACSaN4CommtracDriver, es un

procedimiento almacenado de datos “Bd_MIDBiztalk” y tiene los
Tabla N° 3.38:
Campos contenidos en el mensaje Log_BTSACSaN4CommtracDriver
Nombre del Objeto : Log_BTSACSaN4CommtracDriver

Campos de Entrada:
98
Fecha de inicio - parámetro de entrada
FechaIni String del servicio web.
Hora de inicio - parámetro de entrada del
HoraIni String servicio web.
Tipo de registro - parámetro de entrada
TipoReg Int del servicio web.
FechaLog String
IdInstance String
Campos de Salida:

De la tabla mostrada se puede apreciar el esquema que se usa

en la ejecución del procedimiento almacenado que guardara un
log de los datos enviados al servicio web de ACS.
 El objeto de nombre WebServicesN4C.LastUpdate, es un

procedimiento almacenado de datos “Bd_MIDBiztalk” y tiene los
Tabla N° 3.39:
Campos contenidos en el mensaje WebServicesN4C.LastUpdate
Nombre del método : LastUpdate

Nombre del Servicio : WebServicesN4C
Campos de Entrada:
Fecha desde la que se desea obtener el
FechaIni DATETIME reporte de cambios realizados.
Hora desde la que se desea obtener el
HoraIni STRING reporte cambios realizados.
Número de identificación interna del tipo
TipoReg INT de registro Chofer del cual se desea
obtener el reporte.
 Choferes 10019
Campos de Salida:
String STRING DNI del chofer.
String STRING Apellidos del chofer.
String STRING Nombre del chofer
String STRING Número de licencia
String STRING Ciudad de la licencia
String STRING Estado del Registro
String STRING Fecha de expiración de la licencia.
99
String STRING Nombre de la Compañía.
String STRING Numero de Tara.
String STRING Fecha de cambio.
De la tabla anterior se visualiza los datos de entrada y salida del

servicio web, que devuelve la lista de choferes, para ello se envía
el rango de fecha y hora de donde se desea obtener el reporte.
 El esquema de nombre DriverDBIS, es objeto que será usado

por el sistema DBIS, y tiene los siguientes campos que se
detallan en la tabla N° 3.40.
Tabla N° 3.40:
Campos contenidos en el mensaje DriverDBIS
Nombre del Objeto : “DriverDBIS_YYYY-MM-DDTHHMMSS-0500”

Tipo de objeto : CSV
Ruta : \\10.51.12.99\customers_snx\driver

Nombre String Nombre y apellidos del chofer.
Compania String Nombre de la Compañía.
Archive String Estado del Registro
Brevete String Número de brevete

De la tabla anterior se observa los datos de choferes que serán

enviados al sistema DBIS COMMTRAC. Este esquema de datos
será convertido en un archivo plano que será guardado en la
ruta: \\10.51.12.99\customers_snx\driver y luego el sistema
DBIS COMMTRAC lo capturará automáticamente.
 El esquema de nombre DriverN4, es objeto que será usado por

el sistema NAVIS N4, y tiene los siguientes campos que se
detallan en la tabla N° 3.41.
100
Tabla N° 3.41:
Campos contenidos en el mensaje DriverN4
Nombre del Objeto : “DriverN4_YYYY-MM-DDTHHMMSS-0500”

Tipo de objeto : xml personalizado
Ruta : \\10.51.12.99\customers_snx\driver

Name String Nombre y apellidos del chofer.
license-nbr String Número de licencia
status String Estado del Registro
life-cycle-state String Estado

De la tabla anterior se observa los datos de choferes que serán

enviados al sistema NAVIS N4. Este esquema de datos será
convertido en un archivo plano que será guardado en la ruta:
\\10.51.12.99\customers_snx\driver y luego el sistema NAVIS N4
lo capturará automáticamente.
 El esquema de nombre CorreoError, que es usado en el envío

de correo con el log de errores del proceso, y tiene los siguientes
campos que se detallan en la tabla N° 3.42.
Tabla N° 3.42:
Campos contenidos en el mensaje CorreoError
Nombre del Objeto : CorreoError


De la tabla mostrada, se aprecia la estructura del correo que es

enviado cuando se presenta algún error en el proceso de
ejecución de la orquestación de choferes.
 El esquema de nombre LogDriver, es un objeto de apoyo, sus

campos se detallan en la tabla N° 3.43.
101
Tabla N° 3.43:
Campos contenidos en el mensaje LogDriver
Nombre del Objeto : LogDriver



De la tabla anterior se observa que se almacena la fecha del log

y así mismo el Id de la instancia de la orquestación, que
finalmente será usado al momento de guardar el log de
ejecuciones del flujo de proceso como un historial.

mensaje de entrada BTSPRCDRIGET001 y el mensaje de salida
WebServicesN4C - LastUpdate.
Tabla N° 3.44:
BTSPRCDRIGET001 (BTS) a WebServicesN4C - LastUpdate (ACS)
(Btsprcdriget001) (LastUpdate)
Ninguna
FECHA FechaIni
Ninguna
HORA HoraIni
Ninguna
Tipo TipoReg
De la tabla anterior, se detalla que el pase de datos es lineal sin

ningún tipo de conversión, donde se transfieren los valores para
invocar el servicio web.

BTSPRCDRIUPD001.
102
Tabla N° 3.45:
BTSPRCDRIGET001 (BTS) a BTSPRCDRIUPD001 - (BTS)
(Btsprcdriget001) (Btsprcdriupd001)
FECHA
HORA
Tipo
FechaProceso
De la tabla anterior, se observa que no hay transferencia de

datos del mensaje de entrada, pero si se captura la fecha actual
de la ejecución del servicio web.

mensaje de entrada WebServicesN4C y el mensaje de salida
DriverdN4_FECHA.
Tabla N° 3.46:
WebServicesN4C (ACS) a – DriverdN4_FECHA (N4)
(Btsprcdriget001) (LastUpdate)
String – index 1
Concatenación
String – index 2 Name
String – index 3
Ninguno
String – index 4 license-nbr
String – index 5
Si es “10021”, status es Activo.
String – index 6 Si es “10022”, status es Status
Inactivo.
Si fuera otro valor, status es
Inactivo.
String – index 7
String – index 8
String – index 9
String – index 10
Por defecto “ACT”
life-cycle-state
De la tabla anterior, se detalla que el mensaje de entrada

contiene los datos devueltos del servicio web, que contiene la
lista de choferes, tales como el nombre, licencia y estado al
sistema Navis N4.
103
mensaje de entrada WebServicesN4C - WebServicesN4C y el
mensaje de salida DriverdDBIS _FECHA.
Tabla N° 3.47:
WebServicesN4C (ACS) a DriverdDBIS _FECHA (DBIS)
(WebServicesN4C) (DriverdDBIS)
String – index 1
Concatenación
String – index 2 Nombre
String – index 3
Ninguno
String – index 4 Brevete
String – index 5
Si es “10021”, status es Activo.
String – index 6 Si es “10022”, status es Archive
Inactivo.
Si fuera otro valor, status es
Inactivo.
String – index 7
Ninguno
String – index 8 Compañía
String – index 9
String – index 10


lista de choferes, tales como el nombre, brevete y estado al
sistema DBIS COMMTRAC.

LogDriver.
Tabla N° 3.48:
BTSPRCDRIGET001 (BTS) a LogDriver (BTS)
(Btsprcdriget001) (Btsprcdriupd001)
FECHA
HORA
Tipo
FechaLog
104
De la tabla anterior, se observa que no hay transferencia de
datos del mensaje de entrada, pero si se captura la fecha actual
de la ejecución del servicio web.

mensaje de entrada BTSPRCDRIGET001 y LogDriver, y el
mensaje de salida Log_BTSACSaN4CommtracDriver.
Tabla N° 3.49:
Btsprcdriget001 (BTS), LogDriver (BTS) a Log_BTSACSaN4CommtracDriver (BTS)

(Btsprcdriget001, (Log_BTSACSaN4CommtracDriver)
LogDriver)
Ninguno
FECHA FechaIni
Ninguno
HORA HoraIni
Ninguno
Tipo TipoReg
Ninguno
FechaLog FechaLog
Ninguno
Del mapa mostrado, se observa los datos que pasan de forma

lineal, sin ninguna transformación de datos. Este mapa tiene la
finalidad de guardar un log de los datos de envío al servicio web
y la fecha de proceso, así como el Id de instancia del proceso.

CorreoErrorDri.
Tabla N° 3.50:
BTSPRCDRIGET001 (BTS) a CorreoErrorDri (BTS)

(Btsprcdriget001) (CorreoErrorDri)
FECHA
HORA
Tipo
Por defecto : BizTalk Error -
Driver Asunto
HoraError
Error
105
De la tabla anterior, se observa el mapa que captura los datos
para el envío de correo con el log de errores, los datos son: el
Asunto, la fecha del error y el mensaje de error.
3.2.2.4. Interfaz de camiones

La orquestación diseñada para la interfaz de camiones cuenta con los
trabajo:
A. Mensajes:
 El objeto de nombre Btsprctruget001, es un procedimiento
almacenado de la base de datos “Bd_MIDBiztalk”, el que da
inicio a la orquestación y se muestra en la tabla N° 3.51.
Tabla N° 3.51:
Campos contenidos en el mensaje Btsprctruget001
Nombre del Objeto : BTSPRCTRUGET001

Campos de Entrada:
Campos de Salida:
FECHA String Fecha del último proceso
HORA String Hora del último proceso
Tipo Int Tipo de registro

En la tabla se muestra que el objeto tiene como campos de salida

tres elementos, los cuales serán los parámetros de entrada para
invocar el servicio web “WebServicesN4C”.
 El objeto de nombre Btsprctruupd001, es un procedimiento

almacenado de la base de datos “Bd_MIDBiztalk”, que realizará
una actualización al objeto Btsprctruget001, la estructura de este
mensaje se muestra en la tabla N°3.52.
106
Tabla N° 3.52:
Campos contenidos en el mensaje Btsprctruupd001
Nombre del Objeto : BTSPRCTRUUPD001
Campos de Entrada:
Fecha de inicio de llamada al servicio
FechaProceso String web.
Campos de Salida:

De la tabla, se muestra que este objeto tiene un parámetro de

entrada, el cual será necesario para actualizar los campos del
objeto Btsprctruget001, esto sucede cada vez que la
orquestación de la interfaz de choferes resulte exitosa.
 El objeto de nombre Log_BTSACSaN4CommtracTrucks, es una

tabla de la base de datos “Bd_MIDBiztalk”, en esta tabla se
almacenarán el registro de los datos enviados como parámetros
de entrada al servicio web, tal como se muestra en la tabla N°
3.53.
Tabla N° 3.53:
Campos contenidos en el mensaje Log_BTSACSaN4CommtracTrucks
Nombre del Objeto : Log_BTSACSaN4CommtracTrucks
Campos de Entrada:
Fecha de inicio - parámetro de entrada
FechaIni String del servicio web.
Hora de inicio - parámetro de entrada del
HoraIni String servicio web.
Tipo de registro - parámetro de entrada
TipoReg Int del servicio web.
FechaLog String
IdInstance String
Campos de Salida:
107
De la tabla mostrada se puede afirmar que contiene dos campos
adicionales a los parámetros de entrada del servicio web, estos
campos son FechaLog (Fecha actual de ejecución del proceso)
y el IdInstance (Nombre único de la instancia de la orquestación)
no existe campo de salida por ser una tabla de inserción.
 El objeto de nombre LastUpdate, es un método del servicio web

“WebServicesN4C”, al invocar este método con los parámetros
de entrada del objeto Btsprctruget001, se obtiene la información
de camiones, la estructura del objeto se observa en la tabla N°
3.54.
Tabla N° 3.54:
Campos contenidos en el mensaje LastUpdate

Campos de Entrada:
Fecha desde la que se desea obtener el
FechaIni DATETIME reporte de cambios realizados.
Hora desde la que se desea obtener el
HoraIni STRING reporte cambios realizados.
Número de identificación interna del tipo
TipoReg INT de registro Camión del cual se desea
obtener el reporte.
 Camión 10020
Campos de Salida:
String – index1 STRING Número de placa del Camión.
String – index2 STRING Tipo de Camión.
String – index3 STRING Razón social del transportista.
String – index4 STRING
String – index8 STRING Número de RUC del transportista.
String – index10 STRING Fecha de actualización.
108
contienen campos de tipo “string” con la información de los
camiones registrados.
 El objeto de nombre “TruckDBIS_YYYY-MM-DDTHHMMSS-

0500”, es el archivo “csv” que será generado y enviado a la ruta
establecida, la estructura de este mensaje se muestra en la tabla
N° 3.55.
Tabla N° 3.55:
Campos contenidos en el mensaje TruckDBIS_YYYY-MM-DDTHHMMSS-0500
Nombre del Objeto : “TruckDBIS_YYYY-MM-DDTHHMMSS-0500”

Tipo de objeto : CSV
Ruta : \\10.51.12.99\customers_snx\trucks
Campos para generar el archivo CSV para Camiones DBIS COMMTRAC

Placa String Número de placa del vehículo.
Compañia String Código de la empresa de transportes
(default=2).
Carreta String Número de chasis o plataforma del
camión.
TipoVehiculo String Código del tipo de vehículo (Default=1).
Active String Estado del registro activo (Default=YES).
FechaVencimiento String Fecha de expiración de la licencia.
Del gráfico mostrado se puede mencionar que el archivo

generado se deja en una ruta definida para la carga de rutina
automática y consumida exclusivamente por el sistema DBIS
COMMTRAC.
 El objeto de nombre “TruckN4_YYYY-MM-DDTHHMMSS-0500”,

es el archivo “xml” que será generado y enviado a la ruta
establecida, la estructura de este mensaje se muestra en la tabla
N°3.56.
109
Tabla N° 3.56:
Campos contenidos en el mensaje TruckN4_YYYY-MM-DDTHHMMSS-0500
Nombre del Objeto : “TruckN4_YYYY-MM-DDTHHMMSS-0500”

Tipo de objeto : xml personalizado
Ruta : \\10.51.12.99\customers_snx\trucks
Campos para generar el archivo CSV para Camiones NAVIS N4
Id String Número de chasis del camión (Similar al
nombre de la licencia).
license-nbr String Nombre de la licencia.
license-state String Ciudad donde se emitió la licencia.
license-expiration DateTime Fecha de expiración de la licencia.
bat-nbr String Número de BAT (similar al nombre de la
licencia).
Status String Estado del camión “OK”.
trucking-co-id Long RUC de la empresa de transportes.
is-internal String Valor constante=“N”
life-cycle-state String Valor constante =”ACT”
Del gráfico mostrado se puede mencionar que el archivo

generado se deja en una ruta definida para la carga de rutina
automática y consumida exclusivamente por el sistema NAVIS
N4.
 El objeto de nombre CorreoErrorTru, es un esquema creado

para obtener los datos que forman parte del correo que se envía
en caso de alguna alerta de error en la interfaz de camiones, la
estructura de este mensaje se muestra en la tabla N°3.57.
Tabla N° 3.57:
Campos contenidos en el mensaje CorreoErrorTru
Nombre del Objeto : CorreoErrorTru
Campos para generar el correo par-a el manejo de errores en la interfaz de camiones


110
De la tabla mostrada se puede afirmar que existen diversas
formas de manejar errores, y una de ellas es través de un correo,
donde el usuario pueda saber en tiempo real los incidentes que
se suscitan mientras se ejecuta la interfaz de camiones.
 El objeto de nombre LogTruck, es un esquema creado para

obtener la fecha y hora actual, además del ID de la instancia de
la orquestación, la estructura de este mensaje se muestra en la
tabla N°3.58
Tabla N° 3.58:
Campos contenidos en el mensaje LogTruck
Nombre del Objeto : LogTruck
Mensaje de apoyo para la creación del log de proceso en la interfaz de camiones.

FechaLog String Fecha de log

De la tabla mostrada se puede indicar que la fecha y hora

obtenida es capturada en el instante que se está ejecutando la
orquestación, y como segundo campo se tiene el IdInstance,
que es el nombre que diferencia a cada una de las instancias
ejecutadas en la orquestación de la interfaz de camiones.
B. Transformaciones
mensaje de entrada Btsprctruget001 y el mensaje de destino
LastUpdate, donde existen tres conexiones directas que no
implican una transformación.
Tabla N° 3.59:
Mapa de transformación de Btsprctruget001 a LastUpdate
BTSPRCTRUGET001 (BTS) a WebServicesN4C - LastUpdate (ACS)

(Btsprctruget001) (LastUpdate)
Ninguna
FECHA FechaIni
111
Ninguna
HORA HoraIni
Ninguna
Tipo TipoReg
De la tabla mostrada se observa el enlace entre los elementos

de forma directa, donde los campos enviados son parámetro de
entrada del servicio web.

mensaje de entrada Btsprctruget001 y el mensaje de destino
Btsprctruupd001.
Tabla N° 3.60:
Mapa de transformación de Btsprctruget001 a Btsprctruupd001
BTSPRCTRUGET001 (BTS) a BTSPRCTRUUPD001- (BTS)

(Btsprctruget001) (Btsprctruupd001)
FECHA
HORA
Tipo
FechaProceso
El mapa muestra que no existen conexiones, pero se establece

de esta forma con el fin de capturar el valor de la fecha actual
para actualizar los campos del objeto Btsprctruget001, al finalizar
el proceso de la interfaz de camiones.

mensaje de entrada LastUpdate y el mensaje de destino
TruckN4_Fecha (N4), para poder generar el archivo xml.
Tabla N° 3.61:
Mapa de transformación de LastUpdate a TruckN4_Fecha (N4)
WebServicesN4C - WebServicesN4C (ACS) a – TruckN4_FECHA (N4)

(LastUpdate) (TruckN4_FECHA (N4)
112
Ninguno
String – index 1 ID, LICENSE-NBR, BAT-NBR
Ninguno
String – index 2
Ninguno
String – index 3
Ninguno
String – index 4
Ninguno
String – index 5
Ninguno
String – index 6
Ninguno
String – index 7
Ninguno
String – index 8 TRUCKING-CO-ID
Ninguno
String – index 9
Ninguno
String – index 10 LICENSE-EXPIRATION
Valor por defecto “LIM”
Valor Fijo LICENSE-STATE
Valor por defecto “OK”
Valor Fijo STATUS
Valor Fijo Valor por defecto “N” IS-INTERNAL
Valor Fijo Valor por defecto “ACT” LIFE-CYCLE-STATE
Del mapa mostrado se puede observar que del mensaje origen

solo se requiere de tres elementos y los cuatro elementos
adicionales son valores por defecto.

mensaje de entrada LastUpdate y el mensaje de destino
TruckDBIS_Fecha (DBIS), para poder generar el archivo CSV.
Tabla N° 3.62:
Mapa de transformación de LastUpdate a TruckDBIS_Fecha (DBIS)
WebServicesN4C - WebServicesN4C (ACS) a – TruckDBIS _FECHA (DBIS)

(LastUpdate) (TruckDBIS _FECHA (DBIS))
String – index 1
Ninguno Tipo vehículo
String – index 2
Ninguno Carreta
String – index 3
Ninguno Placa
String – index 4
String – index 5
String – index 6
Ninguno Fecha vencimiento
String – index 7
Ninguno Compañía
String – index 8
String – index 9
String – index 10
ACT por defecto Active
113
lista de camiones, de los cuales se envía el nombre, brevete y
estado al sistema DBIS COMMTRAC.

mensaje de entrada Btsprctruget001 y el mensaje de salida
LogTruck.
Tabla N° 3.63:
Mapa de transformación de Btsprctruget001 a LogTruck
BTSPRCTRUGET001 (BTS) a LogTruck (BTS)

(Btsprctruget001) (LogTruck)
FECHA
HORA
Tipo
FechaLog

dos elementos, el primer elemento “FechaLog” que captura la
fecha y hora actual del proceso de la interfaz de camiones.

entre dos mensajes de entrada Btsprctruget001, LogTruck y el
mensaje de salida Log_BTSACSaN4CommtracTrucks.
Tabla N° 3.64:
Mapa de transformación de Btsprctruget001, LogTruck a
BTSPRCTRUGET001 (BTS), LogTruck (BTS) a Log_BTSACSaN4CommtracTrucks (BTS)

(Btsprctruget001, (Log_BTSACSaN4CommtracTrucks)
LogTruck)
Ninguno
FECHA FechaIni
Ninguno
HORA HoraIni
Ninguno
Tipo TipoReg
Ninguno
FechaLog FechaLog
114
Ninguno
Del mapa mostrado, se observa que el enlace entre los

elementos es directo, esto se refiere a que no existe ningún tipo
de transformación o conversión de formato del sistema origen.

mensaje de entrada Btsprctruget001 y el mensaje de salida
CorreoErrorTruck.
Tabla N° 3.65:
Mapa de transformación de Btsprctruget001 a CorreoErrorTruck
BTSPRCTRUGET001 (BTS) a CorreoErrorTruck (BTS)

(Btsprctruget001) (CorreoErrorTruck)
FECHA
HORA
Tipo
Por defecto : BizTalk Error
– Truck Asunto
HoraError
Error

dos elementos de valores fijos y el elemento “HoraError” que
captura la fecha y hora actual del proceso de la interfaz de
camiones.
3.2.3. Análisis y diseño de la interfaz

Los componentes principales son las orquestaciones donde se implementa el
flujo del proceso. Entonces para cada interfaz se implementó una orquestación,
a continuación se definen los nombres de las orquestaciones:
 Orquestación interfaz horarios: orch_Horarios

 Orquestación interfaz asistencia: orch_InterfazAsistencia
 Orquestación interfaz choferes: orch_InterfazDrivers
 Orquestación interfaz camiones: orch_InterfazTrucks
115
En la orquestación se usan esquemas y mapas para el manejo y transformación
de los datos, que se definieron en el análisis y diseño de datos, es así que se
desarrolló los siguientes componentes: esquemas, mapas y pipelines.
El componente pipeline sirve para trasformar mensajes xml al formato deseado,

es así que se usa algunos pipelines para obtener archivos planos o CSV y se
listan a continuación:
 Interfaz choferes: SndDriDBIS
 Interfaz choferes: SndDriN4
 Interfaz camiones: SndTruDBIS
 Interfaz camiones: SndTruN4
Estos componentes son desarrollados e integrados en un ambiente de

desarrollo de BizTalk Server 2013, que provee las herramientas necesarias
para orquestar procesos y conectarse a diversas fuentes de datos.
Para planificar el desarrollo de la interfaz se ha definido el uso de componentes

de datos o servicios que se consumen alrededor de la orquestación, tales como
procedimientos almacenados y servicios web.
A. Interfaz de horarios
En cada interfaz se hace uso de diversos componentes, estos componentes

inician el flujo partiendo desde el sistema origen “NOMBRADA” hasta el
resultado final en el sistema destino “ACS”. En el gráfico N° 3.8 de la interfaz
de horarios se muestra el flujo del proceso que se ejecuta en Biztalk Server.
116
Gráfico N° 3.8:
Flujo de la Interfaz de Horarios
Interfaz Horarios
NOMBRADA ACS
BTSPROCSELHOR001
EstadoEnvioOnGuard = 1
Seleccionado
Log_BTSNombradaACS Bd_MIDBiz
talk Servidor BizTalk Web
2013 Service
Lista Trabajadores
IntermedioHor
Mensaje errado
EstadoEnvioOnGuard = 2
BTSPROCUPDESTRG001 Procesado
Envío mail
BTSPROCUPDESTRG001 EstadoEnvioOnGuard = 3
Error

Del gráfico anterior se describe el flujo de los mensajes que son procesados
en Biztalk, estos mensajes provienen de procedimientos almacenados y
servicios web, dando vida al flujo.
B. Interfaz de asistencia
inician el flujo partiendo desde el sistema origen “ACS” hasta el resultado
final en el sistema destino “NOMBRADA”. En el gráfico N°3.9 de la interfaz
de asistencia se muestra el flujo del proceso que se ejecuta en Biztalk
Server.
117
Gráfico N° 3.9:
Flujo de la interfaz de asistencia
Interfaz Asistencia
NOMBRADA
ACS
Servidor BizTalk
Bd_MIDBTSPRCASTGET002 2013
Biztalk
BTSPROCINSAST001
Web
Service
Asistencia
Asistencia Intermedio
IntermedioIni
Mensaje Errado
Log_BTSACSaNombradaAsist
BTSPRCASTUPD001 Envío mail

C. Interfaz de choferes
final en los sistemas destino “NAVIS N4” y “DBIS COMMTRAC”. En el
gráfico N° 3.10 de la interfaz de choferes se muestra el flujo del proceso
que se ejecuta en Biztalk Server.
118
Gráfico N° 3.10:
Flujo de la Interfaz de Choferes
Interfaz Choferes
ACS
NAVIS N4
BTSPRCDRIGET001
Servidor BizTalk
2013
Bd_MID
Biztalk
Web
Service SndDriN4xml
Mensaje con DBIS

valores
COMMTRAC
iniciales
SndDriDBIScsv
Almacena
fecha de Mensaje Errado
proceso
BTSPRCDRIUPD001
Envío mail

D. Interfaz de camiones

final en los sistemas destino “NAVIS N4” y “DBIS COMMTRAC”. En el
gráfico N°3.11 de la interfaz de Choferes se muestra el flujo del proceso
que se ejecuta en Biztalk Server.
119
Gráfico N° 3.11:
Flujo de la Interfaz de Camiones
Interfaz Camiones
ACS
NAVIS N4
BTSPRCTRUGET001
Servidor BizTalk
2013
Bd_MID
Biztalk
Web
Service SndTruN4xml
Mensaje con DBIS

valores
COMMTRAC
iniciales
SndTruDBIScsv
Almacena
fecha de Mensaje Errado
proceso
BTSPRCTRUUPD001
Envío mail

3.3. CONSTRUCCIÓN
En esta fase se genera los componentes de las interfaces que forman parte del servicio
de integración, se desarrollan todos los procedimientos de operación y seguridad, y se
elaboran los manuales de usuario con el objetivo de asegurar el correcto funcionamiento
de las interfaces para su posterior implementación.
Para conseguir el objetivo de esta fase se toma la información obtenida en la fase de

diseño, se prepara el entorno o ambiente de desarrollo, se generan los esquemas,
mapas y orquestación de las interfaces, a medida que se vaya finalizando la
construcción, se lleva a cabo las pruebas unitarias e integrales.
120
3.3.1. Desarrollo de infraestructura
La infraestructura es la primera actividad que se debe llevar a cabo para dar
inicio al desarrollo, donde se verificará a nivel de hardware y software los
requerimientos de parte del equipo de desarrollo, donde se debe contar con un
servidor con Windows Server 2008 R2, que debe encontrarse en la red de APM
Terminals.
En dicho servidor se debe instalar un ambiente de desarrollo para BizTalk
Server 2013.
A. Instalación de Microsoft Biztalk:

Se instalará un ambiente de desarrollo y producción con el software
Microsoft BizTalk Server 2013, la versión a instalar será el Estándar de
acuerdo al análisis realizado previamente.
El software base de la solución está compuesta de la siguiente manera:
 Sistema Operativo Windows Server 2008 R2 SP1 (Servidor de
aplicaciones y base de datos)
 Internet Information Server 7.5 de 64 bits. (Servidor de Aplicaciones)
 SQL Server 2008 R2 de 64 bits con SP1 (Servidor de Base de datos)
 BizTalk Server Standard 2013 de 64 bits. (Servidor de Aplicaciones).
Previo a la instalación de Biztalk Server se debe tener en cuenta los
siguientes pasos:
- Instalar las actualizaciones de Windows
- Instalar Microsoft Office Excel
- Instalar Visual Studio 2012
- Configuración del DTC entre los servidores de base de datos y el
servidor de BizTalk.
Luego de haber ejecutado los pasos mencionados se procede con la instalación

de la herramienta de BizTalk y para mayor detalle se ha elaborado un manual
de instalación6.
3.3.2. Desarrollo de datos

En esta fase se crean los objetos tales como procedimientos almacenados y
servicios web, que harán posible el flujo y almacenamiento de la información.
6 Ver Anexo A: Manual de Instalación Biztalk Server 2013
121
A. Interfaz de horarios:
Nombre del Objeto : BTSPROCSELHOR001
Base de Datos : Bd_ Nombrada
Gráfico N° 3.12:
Procedimiento Almacenado BTSPROCSELHOR001

Nombre del Objeto : BTSPROCUPDESTREG001
122
Gráfico N° 3.13:
Procedimiento Almacenado BTSPROCUPDESTREG001

Nombre del Objeto : Log_BTSNombradaACS

Gráfico N° 3.14:
Tabla Log_BTSNombradaACS

123
Nombre del Objeto : BadgeActivation
Tipo de objeto : Servicio web
Nombre del Servicio : WebServiceNombrada
Gráfico N° 3.15:
Método BadgeActivation del servicio web WebServiceNombrada

B. Interfaz de asistencia
Nombre del Objeto : BTSPRCASTGET002
Gráfico N° 3.16:
Procedimiento Almacenado BTSPRCASTGET002

124
Nombre del Objeto : BTSPROCINSAST001
Gráfico N° 3.17:
Procedimiento Almacenado BTSPROCINSAST001

Nombre del Objeto : BTSPRCASTUPD001

Gráfico N° 3.18:
Procedimiento almacenado BTSPRCASTUPD001

125
Nombre del Objeto : Log_BTSACSaNombradaAsist
Gráfico N° 3.19:
Tabla Log_BTSACSaNombradaAsist

Nombre del Objeto : Report

Nombre de Servicio : WebServicePlanilla
Gráfico N° 3.20:
Método Report del servicio web WebServicePlanilla

C. Interfaz de choferes
Nombre del Objeto : BTSPRCDRIGET001
126
Gráfico N° 3.21:
Procedimiento almacenado BTSPRCDRIGET001

Nombre del Objeto : BTSPRCDRIUPD001

Gráfico N° 3.22:
Procedimiento almacenado BTSPRCDRIUPD001

127
Nombre del Objeto : Log_BTSACSaN4CommtracDriver
Gráfico N° 3.23:
Tabla Log_BTSACSaN4CommtracDriver


Gráfico N° 3.24:
Método LastUpdated del servicio web WebServicesN4C

D. Camiones
Nombre del Objeto : BTSPRCTRUGET001
128
Gráfico N° 3.25:
Procedimiento almacenado BTSPRCTRUGET001

Nombre del Objeto : BTSPRCTRUUPD001

Gráfico N° 3.26:
Procedimiento almacenado BTSPRCTRUUPD001

129
Nombre del Objeto : Log_BTSACSaN4CommtracTrucks
Gráfico N° 3.27:
Tabla Log_BTSACSaN4CommtracTrucks


Gráfico N° 3.28:
Método LastUpdated del servicio web WebServicesN4C

130
3.3.3. Desarrollo de procesos
En esta etapa se detalla el proceso de desarrollo de cada una de las interfaces
que harán posible la implementación del servicio de integración del proceso de
control de accesos. A continuación se describe cada uno de los componentes
creados para desarrollar la orquestación por cada interfaz.
3.3.3.1. Desarrollo de la interfaz de horarios

En el nuevo ambiente de desarrollo se procede a crear el proyecto
“BizTalk Project” con el nombre de BTSInterfazHorarios, como se
observa en el gráfico N° 3.29.
Gráfico N° 3.29:
Creación del proyecto BTSInterfazHorarios

Para el proyecto se crearán los esquemas de datos o mensajes, los

mapas para las trasformaciones de los mensajes y finalmente se
unirán estos elementos a la orquestación.
A. Esquemas
En este paso se desarrollan los esquemas de los mensajes,
básicamente se estructuran los mensajes, indicando los tipos de
datos provenientes de la base de datos o servicios web, el
lenguaje que usa BizTalk Server es la estructura en XML. A
continuación se lista los esquemas del proyecto
BTSInterfazHorarios.
131
 Btsprocselhor001Hor.xsd
 CorreoErrorHor.xsd
 InsertLog_BTSNombradaACSService_1.xsd
 IntermedioHor.xsd
 J1ProcedureResultSet.dbo
 BTSPROCUPDESTREG001.xsd
 J1TypedProcedure.dbo.xsd
 LogHora.xsd
 LogSimpleTypeArray.xsd
 LogTable.dbo.xsd
 PropertySchema.xsd
El grafico N° 3.30 muestra al esquema Btsprocselhor001Hor.xsd

donde en la sección izquierda se visualiza la estructura conforme al
diseño elaborado en la etapa de diseño, y en la sección derecha se
tiene el xml construido automáticamente al insertarse cada elemento
y sus propiedades.
Gráfico N° 3.30:
Esquema de la interfaz horarios

Como se visualiza en el gráfico anterior se ha construido los

esquemas, y para este caso, Btsprocselhor001Hor.xsd, tiene siete (7)
elementos, que en conjunto representan los datos enviados al servicio
web. El esquema soporta un dato por cada elemento y es referenciada
en la orquestación por el targetNamespace que se encuentra en la
cabecera del XML, http://APMTerminals/EAI/HOR/Nombrada.
132
B. Mapas
Se procede con el desarrollo de mapas con el de fin de trasformar
los mensajes (esquemas) dentro del flujo de la orquestación. Se
muestra la lista de mapas para el proyecto:
 Btsprocselhor001_To_CorreoErrorHor.btm
 Btsprocselhor001_to_LogHora.btm
 Btsprocselhor001_To_LogInsertHorario.btm
 IntermedioHor_to_WsBadgeActivation.btm
 IntermedioHorWsBadgeActivation_to_Btsprocupdestreg
001Hor.btm
Los mapas creados se encuentran dentro del mismo proyecto. En

el gráfico N° 3.31 se muestra uno de los mapas desarrollados.
Gráfico N° 3.31:
Mapa de la interfaz horarios

En el gráfico anterior, se visualiza el mapa

Btsprocselhor001_To_LogInsertHorario.btm, que posee dos
esquemas de entrada (Btsprocselhor001Hor.xsd y LogHora.xsd)
y uno de salida. Se efectúa el paso de los datos, y además tiene
un Loop Functoide, que permite pasar una lista de datos.
133
C. Orquestación
En este paso se utiliza el diseñador de orquestaciones para
implementar el flujo de proceso de la interfaz. Para agregar una
orquestación seleccionar con el botón secundario
BTSInterfazHorarios, luego agregar nuevo elemento, creándose
una nueva orquestación que es nombrada Orch_Horarios.Oxd,
tal como se muestra en el grafico N° 3.32.
Gráfico N° 3.32:

El diseñador de orquestaciones es un entorno de diseño donde se

pueden crear representaciones visuales de los procesos de
negocio. El área de diseño es un lienzo de trabajo donde se van
depositando distintas figuras de la caja de herramientas, tales
como mensajes (esquemas) y transformaciones (mapas).
En la siguiente grafica se muestra la orquestación de la interfaz
de horarios.
Gráfico N° 3.33:

134
En el grafico anterior se muestra la representación visual del proceso
que comunica al sistema Nombrada con el sistema ACS, con el apoyo
de los componentes de BizTalk.
3.3.3.2. Desarrollo de la interfaz de asistencia

“BizTalk Project” con el nombre de BTSInterfazAsistencia, como se
Gráfico N° 3.34:
Creación del proyecto BTSInterfazAsistencia

Para el proyecto se crearán los esquemas de datos o mensajes, los

mapas para las trasformaciones de los mensajes y finalmente se unirán
estos elementos en la orquestación.
A. Esquemas
En este paso se desarrollan los esquemas de los mensajes, básicamente
se estructuran los mensajes, indicando los tipos de datos provenientes
de la base de datos o servicios web. A continuación se lista los esquemas
del proyecto BTSInterfazAsistencia.
 AsistenciaIntermedio.xsd
 AsistenciaIntermedioIni.xsd
135
 AstDataSetSchema.xsd
 AstProcedure.dbo.xsd
 Btsprcastget002Ast.xsd
 Btsprcastupd001Ast.xsd
 CorreoErrorAst.xsd
 Log_BTSACSaNombradaAsist.xsd
 LogAsistencia.xsd
 WsReportAst.xsd
El grafico N° 3.35 muestra al esquema Btsprcastget002Ast.xsd donde en

la sección izquierda se visualiza la estructura conforme al diseño
elaborado en la etapa de diseño, y en la sección derecha se tiene el XML
construido automáticamente al insertarse cada elemento y sus
propiedades.
Gráfico N° 3.35:
Esquema de la interfaz asistencia

Como se visualiza en el gráfico anterior se ha construido el mensaje

de datos Btsprcastget002Ast.xsd, el cual tiene nueve (9) elementos,
que en conjunto representan los datos enviados al servicio web. El
esquema soporta un dato por cada elemento y en la orquestación es
referenciado por el targetNamespace que se encuentra en la cabecera
del XML, http://APMTerminals/EAI/AST/BTS.
136
B. Mapas
Se procede con el desarrollo de mapas con el fin de trasformar los
mensajes dentro del flujo de la orquestación. A continuación se muestra
la lista de mapas para el proyecto:
 AsistenciaIntermedio_To_Btsprocinsast001Ast_Req.btm
 AsistenciaIntermedioIni_To_WsReportAst_Req.btm
 Btsprcastget002Ast_To_Btsprcastupd001Ast.btm
 Btsprcastget002Ast_To_CorreoErrorAst.btm
 Btsprcastget002Ast_To_Log_BTSACSaNombradaAsist.btm
 Btsprcastget002Ast_To_LogAsistencia.btm
La creación de mapas se realiza dentro del mismo proyecto, en el gráfico

N° 3.36 se muestra uno de los mapas desarrollados
Gráfico N° 3.36:
Mapa de la interfaz asistencia

En el gráfico anterior, se tiene uno de los mapas del proyecto,

AsistenciaIntermedioIni_To_WsReportAst_Req.btm, que posee un
esquema de entrada (.AsistenciaIntermedioIni.xsd) y uno de salida
(WsReportAst.Report.xsd). Además posee dos (2) scripting functoide,
que se implementó para la conversión de tipo de datos DateTime a String,
lo cual se observa en el gráfico N° 3.37.
137
Gráfico N° 3.37:
Configuración de scripting functoide

En el grafico anterior, se puede observar que es posible usar

componentes como los Functoides que permiten el desarrollo de manera
personalizada, es así que se codificó un método que convierte datos de
entrada de tipo DateTime a String, debido a que el servicio web tiene sus
parámetros de entrada de tipo de dato string.
C. Orquestación
En este paso se utiliza el diseñador de orquestaciones para implementar
el flujo de proceso de la interfaz. Para agregar una orquestación
seleccionar con el botón secundario BTSInterfazAsistencia, luego
agregar nuevo elemento, creándose una nueva orquestación que es
nombrada Orch_InterfazAsistencia.Odx, tal como se muestra en el
grafico N° 3.38.
138
Gráfico N° 3.38:

El diseñador de Orquestaciones es un entorno de diseño en donde se

pueden crear representaciones visuales de los procesos de negocio. El
área de diseño es un lienzo de trabajo donde se van depositando distintas
figuras de la caja de herramientas, tales como mensajes (esquemas) y
transformaciones (mapas).
En el siguiente grafico se muestra la orquestación de la interfaz de
asistencia.
Gráfico N° 3.39:

139
En el grafico anterior se muestra la representación visual del proceso que
comunica al sistema ACS con el sistema Nombrada, con el apoyo de los
componentes de BizTalk.
3.3.3.3. Desarrollo de la interfaz de choferes

“BizTalk Project” con el nombre de BTSInterfazDrivers, como se
Gráfico N° 3.40:
Creación del proyecto BTSInterfazDrivers

Para el proyecto se crearon los esquemas de datos o mensajes, los

estos elementos a la orquestación.
A. Esquemas
Para desarrollar los esquemas de los mensajes, básicamente se
estructuran los mensajes, indicando los tipos de datos provenientes
de la base de datos o servicios web. A continuación se lista los
esquemas del proyecto BTSInterfazDrivers.
 Btsprcdriget001Dri.xsd
 Btsprcdriupd001Dri.xsd
 CorreoErrorDri.xsd
 Log_BTSACSaN4CommtracDriver.xsd
 LogDriver.xsd
 DriverDbis.xsd
 DriversN4.xsd
140
El grafico N° 3.41 muestra al esquema Btsprcdriget001Dri.xsd
donde en la sección izquierda se visualiza la estructura conforme al
diseño elaborado, y en la sección derecha se tiene el xml construido
automáticamente por BizTalk, al insertarse cada elemento y sus
propiedades.
Gráfico N° 3.41:
Creación del proyecto Btsprcdriget001Dri

Como se visualiza en el gráfico anterior se ha construido los

mensajes en esquemas, y para este caso, Btsprcdriget001Dri.xsd,
tiene tres (3) elementos, que en conjunto representan los datos
enviados como parámetro de entrada al servicio Web. El
esquema soporta un dato por cada elemento y en la
orquestación es referenciada con el targetNamespace
http://APMTerminals/EAI/DRI/BTS.
B. Mapas
Se procede con el desarrollo de mapas con el fin de transformar
mensajes en las orquestaciones. Se muestra la lista de mapas
para el proyecto:
 Btsprcdriget001Dri_to_Btsprcdriupd001Dri.btm
 Btsprcdriget001Dri_to_CorreoErrorDri.btm
 Btsprcdriget001Dri_to_Log_BTSACSaN4CommtracDriver
.btm
 Btsprcdriget001Dri_to_LogDriver.btm
 Btsprcdriget001Dri_to_WsLastUpdated_Req.btm
 WsLastUpdated_Res_to_DriverN4.btm
 WsLastUpdated_Res_to_DriversDBIS.btm
141
Gráfico N° 3.42:
Mapa WsLastUpdated_Res_to_DriversDBIS

En el gráfico mostrado se observa el mapa denominado
WsLastUpdated_Res_to_DriversDBIS, el cual tiene como esquema
origen al servicio web y esquema destino al archivo generado para
ser enviado al sistema DBIS COMMTRAC, donde se presentan dos
transformaciones, de concatenación y validación.
C. Orquestación
BTSInterfazDrivers, luego agregar nuevo elemento, creándose una
nueva orquestación que es nombrada Orch_InterfazDrivers.oxd, tal
como se muestra en el grafico N° 3.43.
Gráfico N° 3.43:
Inicio de Orquestación Orch_InterfazDrivers.odx

En base al gráfico anterior se inicia con el desarrollo de la

orquestación, haciendo uso de las diferentes herramientas que
proporciona Biztalk, como se puede observar en el gráfico N° 3.44.
142
Gráfico N° 3.44:
Orquestación de la interfaz de Choferes

El gráfico anterior muestra parte del flujo completo de la
orquestación, en el cual se observa el inicio del flujo de proceso,
haciendo uso de los puertos lógicos de entrada y salida, lo cual es
usado para obtener la respuesta del servicio web
“WebServiceN4C”.
D. Pipelines
En la interfaz de choferes se debe obtener un archivo snx (xml
personalizado), para ello se hace uso de un puerto de canalización
denominado pipeline, el cual le da el formato específico de salida
requerido.
Gráfico N° 3.45:
Pipeline SndDriN4snx

143
En el gráfico mostrado se crea el canal para obtener el archivo que
es enviado al sistema NAVIS N4, de la misma forma se procede a
crear un canal para generar el archivo csv que es enviado al
sistema DBIS COMMTRAC, tal como se muestra en el gráfico N°
3.46.
Gráfico N° 3.46:
Pipeline SndDriDBIScsv

En el gráfico mostrado se puede visualizar que se hace uso del

componente Flat file assembler, a través de este se convierte el
mensaje a un formato de archivo plano.
3.3.3.4. Desarrollo de la interfaz de camiones

“BizTalk Project” con el nombre de BTSInterfazTrucks, como se
144
Gráfico N° 3.47:
Creación del proyecto BTSInterfazTrucks

Para el proyecto se crearon los esquemas de datos o mensajes, los

estos elementos a la orquestación.
A. Esquemas
En este paso se desarrollan los esquemas de los mensajes.
Básicamente se estructuran los mensajes, indicando los tipos de
datos provenientes de la base de datos o servicios web. A
continuación se lista los esquemas del proyecto
BTSInterfazTrucks.
 Btsprctruget001Tru.xsd
 Btsprctruupd001Tru.xsd
 CorreoErrorTru.xsd
 Log_BTSACSaN4CommtracTrucks.xsd
 LogTrucks.xsd
 TrucksDbis.xsd
 TrucksN4.xsd
El grafico N° 3.48 muestra el esquema TrucksDbis.xsd donde en

la sección izquierda se visualiza la estructura conforme al diseño
145
elaborado en el punto anterior, y en la sección derecha se tiene
el xml construido automáticamente por BizTalk, al insertarse cada
elemento y sus propiedades.
Gráfico N° 3.48:
Creación del proyecto BTSInterfazTrucks

Como se visualiza en gráfica anterior se ha construido el

esquema TrucksDbis.xsd, que tiene seis (6) elementos, que en
conjunto representan los datos enviados al archivo plano que
será generado. El esquema soporta un dato por cada elemento y
en la orquestación es referenciada con el targetNamespace
http://APMTerminals/EAI/TRU/BTS.
B. Mapas
Se procede con el desarrollo de mapas con el fin de trasformar
mensajes en las orquestaciones. Se crearon los siguientes
mapas.
 Btsprctruget001Tru_To_Btsprctruupd001Tru.btm
 Btsprctruget001Tru_To_CorreoErrorTru.btm
 Btsprctruget001Tru_To_Log_BTSACSaN4CommtracTru
cks.btm
 Btsprctruget001Tru_To_LogTrucks.btm
 Btsprctruget001Tru_To_WsLastUpdated_Req.btm
 WsLastUpdated_Res_To_TrucksDbis.btm
 WsLastUpdated_Res_To_TrucksN4.btm
146
Gráfico N° 3.49:
Mapa de la interfaz de Camiones

En el gráfico mostrado se observa el mapa denominado

Btsprctruget001Tru_To_Log_BTSACSaN4CommtracTrucks, el
cual tiene dos esquemas de entrada y un esquema de salida, con
una conexión directa, sin ningún tipo de trasformación.
C. Orquestación
BTSInterfazTrucks, luego agregar nuevo elemento, creándose
una nueva orquestación que es nombrada
Orch_InterfazTrucks.oxd, tal como se muestra en el grafico N°
3.50.
Gráfico N° 3.50:
Inicio de Orquestación Orch_InterfazTrucks.odx

147
En base al gráfico anterior se inicia con el desarrollo de la
orquestación, haciendo uso de las diferentes herramientas que
proporciona Biztalk, como se puede observar en el gráfico N°
3.51.
Gráfico N° 3.51:
Orquestación de la interfaz de camiones

El gráfico muestra parte del flujo completo de la orquestación, en

el cual se observa el inicio del flujo del proceso, haciendo uso de
los puertos lógicos de entrada y salida, lo cual es usado para
obtener la respuesta del servicio Web “WebServiceN4C”.
D. Pipelines
En la interfaz de camiones se debe obtener un archivo snx (xml

personalizado), para ello se hace uso de un puerto de
canalización denominado Pipeline. Este componente se visualiza
en el siguiente gráfico.
148
Gráfico N° 3.52:
Pipeline de la interfaz de Choferes

En el gráfico mostrado se crea el canal para obtener el archivo

que es enviado al sistema NAVIS N4, de la misma forma se
procede a crear un canal para generar el archivo CSV que es
enviado al sistema DBIS COMMTRAC, tal como se muestra en
el gráfico N° 3.53.
Gráfico N° 3.53:
Pipeline de la interfaz de Choferes

En el gráfico mostrado se puede visualizar que se hace uso del

componente Flat file assembler, a través de este se convertirá el
mensaje a un formato de archivo plano.
149
Para cumplir con los requerimientos del usuario donde indica que cada interfaz
debe contar con el manejo y tratamiento de errores, después del análisis
respectivo se diseña el desarrollo de un log de errores que se da a nivel de
BizTalk Server, específicamente en la consola de administración, donde un
usuario administrador, con permisos, puede darle seguimiento a las ejecuciones.
Asimismo se cuenta con un servicio de envío de correos con el log de errores de
un proceso en BizTalk, el diseño se muestra en el gráfico N° 3.54. Los
destinatarios son configurables por interfaz, y el remitente es una cuenta de
correo único para el servicio de integración, BiztalkInterfases@apm.com
Gráfico N° 3.54:
Modelo correo con log de errores

La figura anterior muestra el correo con el log de errores, el remitente y

destinatario configurado. Para el funcionamiento del servicio de correo se ha
configurado el servidor de correos de APM Terminals. La estructura de un
modelo del log de errores enviado a través de un correo se muestra en el gráfico
N° 3.55.
Gráfico N° 3.55:
Modelo correo con log de errores

150
De la figura se observa el log de errores que se envía adjunto en formato XML,
y está conformado por tres secciones: asunto, hora y error. Cabe resaltar que
para la interfaz de horarios se envía además los números de DNI de los
estibadores que no pudieron ser registrados debido a un error en el flujo.
Esta estructura de manejo de errores se implementó para cada uno de los
procesos.
3.3.4. Generando el instalador MSI

Después de desarrollar, compilar y desplegar las interfaces, se procede a
generar los instaladores, a través de la consola de administración de BizTalk
Server, donde al exportar una aplicación genera un archivo (.msi) de Windows
Installer que contiene la aplicación con todos los componentes.
En el gráfico N° 3.56 se genera el instalador para la interfaz de asistencia. Se
hace clic con el botón secundario en la aplicación de Asistencia, se
elige Exportar y, a continuación se hace clic en Archivo MSI.
Gráfico N° 3.56:
Exportando la aplicación Asistencia

Luego se muestra la página Asistente para exportación de archivos MSI, se

hace clic en “Next”, tal como se muestra en el gráfico N° 3.57.
151
Gráfico N° 3.57:
Ventana de Asistente de Exportación de archivos

El siguiente paso es la página Seleccionar recursos, donde se selecciona los

artefactos que se van a exportar al archivo .msi y se hace clic en “Next”, esto se
muestra en el gráfico N° 3.58.
Gráfico N° 3.58:
Ventana de Seleccionar Recursos

A continuación se muestra la página Dependencias, donde se revisan las

dependencias de la aplicación y se hace clic en “Next”, tal como se observa en
el gráfico N° 3.59.
152
Gráfico N° 3.59:
Ventana de Dependencias

El siguiente paso al gráfico mostrado es la página Destino, donde se ubica la ruta

del archivo .msi que se va a generar, se hace clic en Export donde se guardará
el instalador generado y se coloca el nombre del instalador, en este caso
“Asistencia”, como se observa en el gráfico N° 3.60
Gráfico N° 3.60:
Ventana de Destino

Después de indicar la ruta tal como se muestra en el gráfico anterior, se generará

el instalador de la aplicación seleccionada y posterior a ello se muestra el
resultado de la exportación, como se observa en el gráfico N° 3.61.
153
Gráfico N° 3.61:
Ventana de Resumen

De lo anterior se observa la forma de cómo generar los archivos MSI para el

despliegue en el ambiente de producción. En la siguiente figura se muestra el
MSI generado de la interfaz de asistencia.
Gráfico N° 3.62:
Instalador de la interfaz asistencia

Después de generar el instalador se finaliza el proceso de exportación, se realizó

el mismo procedimiento para generar los instaladores de las interfaces de
horarios, camiones y choferes. Ahora se puede continuar con la etapa de
pruebas, para verificar la funcionalidad de las interfaces de acuerdo a los
requerimientos.
154
3.4. PRUEBAS
En esta fase se tomó a cada interfaz para probarlo como un conjunto y su relación con
otro sistema con el que se está comunicando. Estas pruebas, que pueden verse como
un subconjunto de las pruebas de integración, se ejecutaron después de finalizado el
desarrollo de la versión entregable del sistema, se hacen las pruebas y sus respectivas
correcciones hasta lograr que la integración se ejecute sin errores.
Las pruebas de sistema permiten verificar las especificaciones funcionales como las
técnicas validando que cumplan con el requerimiento. Además, si el entorno en el que
se realizan estas pruebas es equivalente al de producción, permiten obtener una visión
sobre su comportamiento.
3.4.1. Interfaz horarios

Para mostrar el resultado del flujo de la interfaz de Horarios, descrito en el
capítulo anterior, se verifica la tabla boletanombradadetalle, actualmente se
encuentra sin procesar, tal como se muestra en el gráfico N° 3.63.
Gráfico N° 3.63:
Valores de tabla boletanombradadetalle

Después de verificar la lista que será actualizada al final del proceso, se muestra
la información obtenida en el sistema Nombrada, lo cual es invocado a través de
un procedimiento almacenado cada ocho horas, iniciando a las 6:00 a.m. una
hora antes del inicio de cada turno.
En el gráfico N° 3.64 se muestra información que inicia la orquestación, donde
inserta los datos de los estibadores que tendrán acceso en el primer turno.
155
Gráfico N° 3.64:
Información obtenida del sistema origen - Nombrada

La información del gráfico anterior será enviado al sistema de ACS, para ello se
da inicio a la interfaz de horarios, a través de la consola de Biztalk Server., como
se muestra en el gráfico N° 3.65
Gráfico N° 3.65:
Iniciando interfaz de Horarios

156
Después de iniciar el proceso como se muestra en el gráfico anterior, el sistema
habilita los componentes necesarios para ejecutar el proceso completo., tal como
se muestra en el gráfico N° 3.66
Gráfico N° 3.66:
Iniciando componentes de la orquestación

Después de dar inicio a la interfaz y culminar con el proceso de la orquestación,

en el gráfico N° 3.67 se observa los datos insertados de los estibadores que
tendrán acceso sólo para el primer turno.
Gráfico N° 3.67:
Estibadores autorizados para el ingreso

Luego de culminar con el proceso de integración y enviar la información al

sistema destino, se procede a verificar el registro de log, con los parámetros de
entrada que invocan al servicio web tal como se muestra en el gráfico N° 3.68.
157
Gráfico N° 3.68:
Valores de tabla Events de la Base de Datos Access Control

El registro mostrado en el gráfico anterior se realiza con el fin de tener un control

sobre posibles errores que se pueden generar.
3.4.2. Interfaz asistencia

Para mostrar el resultado del flujo de la interfaz de asistencia, descrita en el
capítulo anterior, se verifica la tabla BTSTBLPRCASIST001, que contiene los
parámetros de entrada para invocar al servicio web, esto datos darán inicio a la
orquestación, tal como se muestra en el gráfico N° 3.69.
Gráfico N° 3.69:
Valores de tabla BTSTBLPRCASIST001

La información obtenida de la tabla mostrada en el gráfico anterior, fue

consumida a través de un adaptador de Biztalk. En el gráfico N° 3.70 se muestra
la lista de la marcación de los estibadores en los tres horarios.
158
Gráfico N° 3.70:
Valores de tabla Events de la Base de Datos Access Control

La información del gráfico anterior será enviado al sistema de Nombrada, para

ello se da inicio a la interfaz de asistencia, a través de la consola de Biztalk
Server, como se muestra en el gráfico N° 3.71
Gráfico N° 3.71:
Inicio de la interfaz de Asistencia

159
Después de dar inicio a la interfaz, en el gráfico N°3.72 se muestra la ejecución
del proceso registro de asistencia a través de la orquestación.
Gráfico N° 3.72:
Proceso de ejecución de la orquestación

Al finalizar con el proceso de la orquestación, uno de los resultados obtenidos

será la respuesta del servicio web, tal como se muestra en el gráfico N° 3.73
Gráfico N° 3.73:
Datos de estibadores como respuesta del servicio web

La información obtenida en el gráfico anterior será enviada al sistema de

Nombrada, lo cual se puede observar en el gráfico N°3.74
160
Gráfico N° 3.74:
Información actualizada en el sistema Nombrada

En el gráfico mostrado se observa que el campo Asistencia se encuentra

actualizado con el valor “SI”, lo que indica que sólo esos estibadores asistieron
en esa fecha y a la hora que muestra en la tabla boletanombradadetalle.
Gráfico N° 3.75:
Información actualizada en el sistema Nombrada

Del grafico anterior se muestra el log de ejecución de la orquestación y el llamado

al servicio web en la interfaz de asistencia.
161
3.4.3. Interfaz Choferes
Para mostrar el resultado del flujo de la interfaz de Choferes, descrito en el
capítulo anterior, se verifica la tabla BTSTBLPRCDRI001 de la Base de Datos
Bd_MIDBiztalk, que contiene los parámetros de entrada para invocar al servicio
web, esto datos darán inicio a la orquestación, tal como se muestra en el gráfico
N° 3.76.
Gráfico N° 3.76:
Valores de tabla BTSTBLPRCDRI001

Del grafico anterior el campo FechaProceso, es la última fecha que la interfaz se

procesó con éxito, el campo DelayProceso, es un intervalo de tiempo que se
considera como tiempo de espera, antes que el proceso finalice.
consumida a través de un adaptador de Biztalk, el cual invoca al servicio web
http://localhost/SWN4COMMTRAC/DeployN4C/WebService1.asmx, que
devuelve una lista que se muestra en el siguiente gráfico.
Gráfico N° 3.77:
Resultados del servicio web: Lista de choferes

162
De lo anterior se puede observar un archivo xml con arreglos de string, resultado
del servicio web del sistema ACS. Con el uso de componentes de biztalk se
obtiene los archivos de salida para los sistemas Navis N4 y DBIS Commtrac.
Gráfico N° 3.78:
Archivo de salida Sistema DBIS COMMTRAC

Del grafico anterior, se observa un archivo CSV con los datos de choferes de tal
manera que el sistema DBIS COMMTRAC pueda asimilarlo. Este archivo es
dejado en la siguiente ruta \\10.51.12.99\customers_snx\driver.
Para el caso del sistema Navis N4, se requiere un archivo xml con la siguiente
estructura para la asimilación de datos de choferes.
Gráfico N° 3.79:

163
Del grafico anterior, se observa un archivo XML con los datos de choferes y es
dejado en la siguiente ruta \\10.51.12.99\customers_snx\driver.
También se actualiza el campo fechaProceso en la tabla BTSTBLPRCDRI001

para dar inicio al próximo proceso.
Gráfico N° 3.80:
Valores actualizados en la tabla BTSTBLPRCDRI001

Finalmente se guarda un log en la tabla Log_BTSACSaN4CommtracDriver de

con los datos enviados al servicio web en la tabla siguiente.
Gráfico N° 3.81: Log de proceso en la tabla


De lo anterior de visualiza que los datos enviados al servicio web fueron

registrados, así como la fecha del registro y el Id Instance de la orquestación que
ejecutó el proceso.
3.4.4. Interfaz camiones

Para mostrar el resultado del flujo de la interfaz de choferes, descrito en el
capítulo anterior, se verifica la tabla BTSTBLPRCTRU001 de la base de datos
Bd_MIDBiztalk, que contiene los parámetros de entrada para invocar al servicio
web, esto datos darán inicio a la orquestación, tal como se muestra en el gráfico
N° 3.82.
Gráfico N° 3.82:
Valores de tabla BTSTBLPRCTRU001

164
Del grafico anterior el campo FechaProceso, es la última fecha que la interfaz se
procesó con éxito, el campo DelayProceso, es un intervalo de tiempo que se
considera como tiempo de espera, antes que el proceso finalice.
consumida a través de un adaptador de Biztalk, el cual invoca al servicio web
http://localhost/SWN4COMMTRAC/DeployN4C/WebService1.asmx, que
devuelve una lista que se muestra en el siguiente gráfico.
Gráfico N° 3.83:
Resultados del servicio web: Lista de camiones

De lo anterior se puede observar un archivo XML con arreglos de string,

resultado del servicio web del sistema ACS. Entonces con el uso de
componentes de biztalk se obtiene los archivos de salida para los sistemas Navis
N4 y DBIS COMMTRAC.
Gráfico N° 3.84:
Archivo de salida Sistema Navis N4

165
Del grafico anterior, se observa un archivo XML con los datos de choferes de tal
manera que el sistema Navis N4 pueda asimilarlo. Este archivo es dejado en la
siguiente ruta \\10.51.12.99\customers_snx\trucks.
Para el caso del sistema DBIS Commtrac, se requiere un archivo CSV con la
siguiente estructura para la asimilación de datos de choferes.
Gráfico N° 3.85:

Del grafico anterior, se observa un archivo CSV con los datos de choferes y es
dejado en la siguiente ruta \\10.51.12.99\customers_snx\trucks.
También se actualiza el campo FechaProceso en la tabla BTSTBLPRCDRI001
para dar inicio al próximo proceso.
Gráfico N° 3.86:
Valores actualizados en la tabla BTSTBLPRCDRI001

Finalmente se guarda un log en la tabla Log_BTSACSaN4CommtracTrucks con

los datos enviados al servicio web tal como se observa en el gráfico siguiente.
Gráfico N° 3.87:
Log de proceso en la tabla Log_BTSACSaN4CommtracTrucks

166
De lo anterior se visualiza que los datos enviados al servicio web fueron
registrados, así como la fecha del registro log y el Id Instance de la orquestación
que ejecutó el proceso.
3.5. PRODUCCIÓN Y MANTENIMIENTO

Durante la puesta en marcha del servicio de integración, el equipo de desarrollo realiza
la instalación y configuración de cada una de las interfaces en el ambiente de
producción, para que inicie el proceso de integración. Además proporciona la
documentación necesaria para los administradores de aplicaciones y base de datos que
se encargaran del servicio. La capacitación también es una parte importante de la fase
de producción, para que los usuarios puedan conocer y administrar el servicio de
integración más adelante.
3.5.1. Despliegue en producción

Al finalizar las pruebas respectivas y generación de instaladores se procede a
instalar las interfaces en el ambiente de producción.
En el gráfico N° 3.87 se visualiza la importación del MSI File, el cual fue generado
desde el ambiente de desarrollo.
Se hace clic con el botón secundario en la aplicación de Asistencia, se
elige “Importar” y, a continuación se hace clic en Archivo MSI.
Gráfico N° 3.88:
Importación de MSI File

Ubicar el instalador de la aplicación (Asistencia) en la siguiente ruta.

“D:\Instaladores\Instaladores\MsiAsistencia.msi” presionar el botón Next para
continuar.
167
Gráfico N° 3.89:
Ventana Import MSI Wizard

Luego de ubicar el archivo, presionar “Next” y se mostrará la ventana “Import

MSI Wizard”.
Gráfico N° 3.90:

168
En la siguiente ventana seleccionar la configuración que adoptará la interface,
en este caso es “Prod”. Luego presionar el botón “Next” para continuar con la
importación del instalador.
Gráfico N° 3.91:
Ventana Import MSI Wizard - Asistencia

Presionar el botón “Import” para iniciar con la instalación.
Gráfico N° 3.92:
Ventana Import MSI Wizard - Asistencia

169
Finalmente presionar el botón “Finish”, para terminar.
Gráfico N° 3.93:

En la siguiente figura se muestra la interfaz de Asistencia desplegada en el

ambiente de producción lista para iniciar.
Gráfico N° 3.94:
Interfaz de Asistencia en el ambiente de producción

Al culminar satisfactoriamente la importación de los instaladores generados, se

puede dar inicio a la interfaz, ya que contiene la configuración para un ambiente
170
de producción para los puertos de entrada, salida, pipeline. Cabe resaltar que
este procedimiento se realiza para todas las interfaces.
En el gráfico N° 3.95 se muestra la Consola de Administración de Biztalk donde
se encuentran desplegadas las cuatro interfaces, y se observar que se
encuentran con estado iniciado o “Started”.
Gráfico N° 3.95:
Consola de Administración de Biztalk

Las interfaces ya se encuentran operativas e internamente hay envío y recepción

de mensajes, y se generan instancias de las orquestaciones como se visualiza
en el gráfico N° 3.96.
Gráfico N° 3.96:
Consola de Administración de Biztalk

171
En el gráfico N° 3.97 se observa las interfaces que se están ejecutando en
simultáneo, a través de la consola de administración. Se muestran todas las
instancias del servicio en progreso, y se van ejecutando de acuerdo a los
mensajes de entrada que llegan a través de los puertos.
Gráfico N° 3.97:
Interfaces en ejecución

3.5.2. Mantenimiento
En la fase de mantenimiento, el servicio de integración pasa a un estado
operativo. El equipo de implementación controla el sistema para asegurar su
funcionamiento en el ambiente de producción. Además realiza el mantenimiento
periódico en el servidor de Biztalk Server para revisar algunos parámetros de
rendimiento, reconfigurar algunos parámetros conforme a un diagnóstico y
eliminar datos temporales. El equipo de soporte también proporciona asistencia
al servidor y resuelve los problemas reportados.
A los treinta (30) días del pase a producción del servicio de integración de
sistemas, se realizó el mantenimiento respectivo a los servidores de base de
datos y de aplicación de BizTalk durante los días 23 y 24 de octubre del 2013,
obteniendo el resultado que se detalla a continuación.
172
3.5.2.1. Diagnóstico de los servidores
A. Servidor de bases de datos

Para el diagnóstico del servidor de base de datos BizTalk se realiza
lo siguiente:
 Se verifica la diferencia horaria entre el servidor de Bases de
Datos de BizTalk con respecto al servidor de Bases de Datos
SQL, tiene una diferencia de treinta 30 (segundos).
 Se muestra la siguiente configuración del servidor de Base de
Datos SQL, en la tabla N° 3.66.
Tabla N° 3.66:
Configuración del servidor de Base de Datos
Nombre SCRBBTKPECAL001
IP 10.51.12.71
Rol BD
Disco C GB 19.2
Disco C (Libre) GB 28.5
Disco D GB 40.6
Disco D (Libre) GB 62.1
RAM GB 12
Paginación C GB 2-4gb
Paginación D GB NO
BizTalkDTADb Disp 424.94
BizTalkDTADb TOT 1757
AutoCreateStatics&Update False
BizTalkMgmtDb Disp 0.26
BizTalkMgmtDb Tot 19
AutoCreateStatics&Update True
BizTalkMsgBoxDb Disp 725.85
BizTalkMsgBoxDb Tot 2779
BTSDataAdapterConfig Dat 3243
BTSDataAdapterConfig Log 2
BTSDataAdapterConfig Disp 8.49
BTSDataAdapterConfig Tot 3245
SSODB Disp 1024.05
SSODB Tot 1029
En la tabla mostrada se detalla las características del servidor de

Base de Datos de SQL, sobre todo el espacio disponible en disco y
en la base de datos que es importante revisar ya que BizTalk trabaja
sobre base de datos que se encuentran en constante crecimiento si
la propiedad de almacenar el Tracking(seguimiento) está activo.
173
B. Servidor de Aplicación
Para el diagnóstico del servidor se muestra la tabla N° 3.67 con las
características del servidor de aplicaciones.
Tabla N° 3.67:
Configuración del servidor de Aplicación
IP 10.51.12.84
Rol Aplicaciones
Disco C GB 11.9
Disco D GB 10.8
RAM GB 12
Paginacion C GB 1-2
Paginacion D GB 16-16
Paginación Current 17.3
Paginación Recomendada 18.4

En la tabla mostrada se detalla las características del servidor de

aplicaciones Biztalk, donde se observa que el espacio consumido es
considerable, pero aún se cuenta con espacio suficiente. En
comparación al servidor de base de datos, el espacio consumido no
tiende a incrementarse.
3.5.2.2. Ejecución del mantenimiento
A. Servidor de bases de datos

 Se ejecutó el script TunningBizTalkOctubre2013-BD.reg, que
agrega o modifica algunos parámetros en el regedit. Este archivo
se encuentra en la ruta: \\10.51.12.71\d$\Instaladores.
 Se ha liberado el espacio en la Base de Datos.
 Se ha deshabilitado el parámetro AutoCreateStatics&Update en
la base de datos para mejorar el performance.
Tabla N° 3.68:
Configuración del servidor de Base de Datos
IP 10.51.12.71
Rol BD
Disco C GB 18.5
Disco D GB 30.3
RAM GB 12
Paginacion C GB 2-4
Paginacion D GB NO
174
BizTalkDTADb Disp MB 1
BizTalkDTADb TOTN MB 117
BizTalkMgmtDb Disp MB 0
BizTalkMgmtDb Tot MB 17
BizTalkMsgBoxDb Disp MB 2
BizTalkMsgBoxDb Tot MB 93
BTSDataAdapterConfig Disp 8
MB
BTSDataAdapterConfig Tot 11
MB
SSODB Disp MB 0
SSODB Tot MB 4
B. Servidor de Aplicación
 Se ejecutó el script TunningBizTalkOctubre2013-APv2.reg, que
agrega o modifica algunos parámetros de configuración en el
regedit. Este archivo se encuentra en la ruta:
\\10.51.12.84\d$\Instaladores.
 Se reconfiguró los host de BizTalk para lograr un mejor
rendimiento. Ver la tabla N° 3.69.
Tabla N° 3.69:
Configuración del host del servidor de Aplicación
Receive Application Planillas Tracking

Max # messa engine threads p cpu 1 20 20 20
Internal mess queue size 100 100 100 100
DataBase connec p cpu 0 0 0 0
threads p cpu 0 0 0 0
inProcess messa p cpu 100 1,000 1,000 1,000
messa count in db 100 50,000 50,000 50,000
physi memory usage 0 0 0 0
process memory usage 25 25 25 25
publishing min # samples 30 100 100 100
publishin sample win dura (milisec) 2,500 15,000 15,000 15,000
publising rate overdrive factor (percent) 107 125 125 125
publising max throttling delay (milisec) 3,600,000 300,000 300,000 300,000
processing min # samples 100 100 100 100
processing sample win dura (milisec) 15,000 15,000 15,000 15,000
processing rate overdrive factor (percent) 125 125 125 125
processing maxthrottling delay (milisec) 300,000 300,000 300,000 300,000
175
3.5.2.3. Documentos procesados por día
En el gráfico N° 3.98 se muestra la cantidad de documentos procesados

del día 23/10/2013 - 1:00 pm para la interfaz de Asistencia, donde se
registró que 1809 trabajos habían sido procesados por BizTalk en el
servidor SCRBBTKPECAL001.
Gráfico N° 3.98:
Cantidad de trabajos realizados para el día 23/10/2013

En el gráfico N° 3.98 se muestra la cantidad de documentos procesados

del día 24/10/2013 - 12:00 pm para la interfaz de Asistencia, donde se
registró que 1791 trabajos habían sido procesados por BizTalk en el
servidor SCRBBTKPECAL001.
Gráfico N° 3.99:
Cantidad de trabajos realizados para el día 24/10/2013

176
3.5.2.4. Contador de rendimiento
Para un adecuado monitoreo del servidor se verifica el estado de envío
y publicación de mensajes, como se puede observar en el gráfico N°
3.100.
Gráfico N° 3.100:
Interfaz de Asistencia en el ambiente de producción

Del gráfico anteriormente mostrado, se resalta dos parámetros

importantes que se mantienen en cero, lo cual indica que el servidor no
presenta ningún problema para procesar solicitudes de transferencia de
información. Así también se observa el uso de memoria se encuentra al
mínimo.
3.5.2.5. Resumen de mantenimiento del servidor de BizTalk

Después de realizar las diferentes actividades de mantenimiento y
performance de servidores, se realizó un informe con los resultados
mostrados en la tabla N° 3.70.
Tabla N° 3.70:
Resumen del mantenimiento de los servidores del servicio de integración
Acciones Después del Mantenimiento
Cada base de datos de BizTalk almacena Servidor de aplicaciones y de base de
datos temporales, que con el tiempo van datos depurados. Se redujo un 90% en
acumulándose, entonces se ejecutó un promedio, el tamaño de las Bases de
plan de depuración bajo ciertas Datos.
condiciones.
Se desactivó el AutoCreateStatics&Update La base de datos de BizTalk tiene
en la base de datos de BizTalk. Las desactivado el AutoCreateStatics&Update.
estadísticas relentizan las bases de datos
en lugar de aumentar el rendimiento.
177
Se reconfiguró los puertos de entrada de Luego de la adecuada configuración de los
trabajos de cada interfaz en el servidor de puertos de entrada, se obtuvo un mejor
BizTalk para mantener un estándar. equilibrio entre las interfaces, donde el
nivel de ahogamiento es 0.
Se ha configurado los parámetros de No se presenta ahogamientos o
ahogamiento conforme a los cambios encolamientos de mensajes luego de la
realizados en el servidor de aplicaciones ejecución del mantenimiento de los
de BizTalk servidores de BizTalk.

En este capítulo se ha presentado de forma detallada la implementación del servicio de

integración con el uso de la metodología de desarrollo que ha permitido diseñar el servicio de
integración de las aplicaciones para los siguientes sistemas ACS, DBIS COMMTRAC, NAVIS
N4 Y NOMBRADA de APM Terminals, facilitando el flujo de la información y la automatización
de los procesos de control de accesos.
178
CAPÍTULO IV
EVALUACIÓN Y DISCUSIÓN DE RESULTADOS
En el presente capítulo se muestran los resultados de la investigación, el cual comprende la

presentación y la discusión de resultados. Donde se analizará el impacto que tiene la
implementación del servicio de integración en el proceso de control de accesos de APM
Terminals. La integración será capaz de comunicar, controlar e intercambiar información entre
los sistemas existentes en APM Terminals, esto conlleva a monitorear y controlar a los
estibadores (trabajadores de APM Terminals), además de brindar un mejor servicio a sus
clientes mediante el control de choferes y camiones que ingresan a las instalaciones del
terminal portuario.
Esta evaluación mostrará el análisis de las variables definidas en el capítulo I, haciendo una
comparación entre el antes y después de la situación actual a través de los resultados
obtenidos con la automatización de procesos, lo cual permitirá validar la importancia de este
servicio con el objetivo planteado.
4.1. PRESENTACIÓN DE RESULTADOS

Para realizar el análisis pertinente se va considerar las variables analizadas
anteriormente en cada situación, es decir en cada escenario presentado y cómo este ha
variado. Estos valores resultantes vistos a través de gráficos y dentro de un rango de
datos demuestran que gracias a la integración de sistemas se puede automatizar los
procesos de forma óptima.
Para iniciar se presentará resultados estadísticos obtenidos después de la
implementación del servicio de integración en APM Terminals. Se mostrará los
resultados de las variables analizadas en capítulos anteriores, cuyo análisis logró
evidenciar deficiencia operativa en el terminal portuario.
179
4.1.1. Número de aplicativos o sistemas integrados
Con este indicador se contabiliza los sistemas que se encuentran haciendo uso
del servicio de integración que permite la automatización del proceso de control
de accesos.
Gráfico N° 4.1:
Numero de sistemas o aplicativos integrados
Sistemas integrados
4
3.5
3
Título del eje
2.5
2
1.5
1
0.5
0
N° SISTEMAS INTEGRADOS
N° Sistemas integrados
Sistemas integrados 4
Fuente: Hoja de pase a producción del servicio de integración en APM Terminals

La gráfica muestra que se han integrado cuatro sistemas que se encuentran

desplegados en el ambiente de producción. Es así que la información fluye entre
estos sistemas de forma automática, siendo más segura y confiable. Esto
permite que los procesos de control de acceso se encuentren automatizados.
4.1.2. Capacitación para la administración del servicio

La capacitación para la administración del servicio es el indicador que permite
saber cuántas personas del departamento de Tecnologías de Información están
capacitadas para administrar o dar soporte a las interfaces y al servidor de Biztalk
Server.
180
Gráfico N° 4.2:
Cantidad de personal capacitado
1 Administrador sistema DBIS

COMMTRAC y NAVIS N4
2
Administrador de Base de Datos
1
Personal de Infraestructura
Administrador sistema de
Control de Accesos
2
Fuente: Registro de capacitación en APM Terminals SAC.
Siendo importante conocer este indicador para saber cuan preparado está el
personal encargado de la administración de sistemas y base de datos, y por
ende el servicio de integración, para así dar seguimiento al funcionamiento de
las interfaces en el ambiente de producción y hacer frente a algunos incidentes
que se puedan presentar por diversos motivos en el servicio de integración de
sistemas y los sistemas involucrados de APM Terminals.
4.1.3. Pruebas de certificación
La prueba de certificación es el indicador que da a conocer la cantidad de

pruebas realizadas por cada interfaz. Durante la prueba de certificación el
sistema se emplea de manera experimental para asegurarse de que el servicio
no tenga fallas, es decir, que funcione de acuerdo a los requerimientos y la forma
en que se espera.
181
Gráfico N° 4.3:
Pruebas de certificación
Cantidad de pruebas certificadas

6
Cantidad de pruebas exitosas 5.8
5.6
5.4
5.2
5
4.8
4.6
4.4
HORARIOS ASISTENCIA CHOFERES CAMIONES
Horarios Asistencia Choferes Camiones

Series1 6 6 5 5
Fuente: Informe de pruebas de Calidad de APM Terminals SAC.

El gráfico N° 4.3 evidencia que se realizaron seis pruebas para las interfaces de
horarios y asistencia y cinco pruebas para las interfaces de choferes y camiones,
estas pruebas consistieron en validar los tipos de datos, la información que
recibe el sistema destino y la información que fluye sobre los objetos usados en
la integración (procedimientos almacenados, servicios web, etc.), así como del
cumplimiento de los requerimientos planteados inicialmente. El resultado exitoso
de las pruebas realizadas indica que el funcionamiento del servicio de integración
es el adecuado.
4.1.4. Nivel de automatización de los procesos

Para medir el nivel de automatización de los procesos, se obtiene el detalle de
las actividades, y de esta manera se efectúan los cálculos respectivos.
Para realizar dichos cálculos se debe conocer primero las actividades que se
realizan de forma manual y las actividades que realiza el sistema, una vez
definido se procede con los cálculos respectivos.
Para medir el nivel de automatización en el proceso de registro de horarios se
detalla las actividades que se muestran en la tabla N° 4.1.
182
Tabla N° 4.1:
Nivel de automatización del proceso de registro de horarios
MANUAL
Enviar lista de Manual Total # de actividades = 5
estibadores # Actividades x Sistema = 3
Proceso de Autorizar lista por Manual Nivel de = 3*100/5=60%
registro de gerente automatización
horarios. Ingresar datos de Manual/Sistema
horarios a
Nombrada
Enviar lista a ACS Sistema
Recepción de lista Sistema
Se observa que se ha automatizado algunos procesos con la implementación del

servicio de integración, principalmente en el envío de lista de horarios del sistema
origen “Nombrada” al sistema destino ACS.
Para medir el nivel de automatización en el proceso de control de asistencia se
detalla las actividades en la tabla N° 4.2. Donde se define las actividades que se
efectúan manualmente o lo realiza el sistema.
Tabla N° 4.2:
Nivel de automatización del proceso de control de accesos
MANUAL
Presentar Manual
Documentos de
identificación
Validar identidad Sistema
Verificar en lista de Sistema Total # de actividades = 9
horarios # Actividades x Sistema = 6
Proceso de Registrar Sistema Nivel de automatización =
control de asistencia 6*100/9 = 66.67%
asistencia. Permitir ingreso Sistema
Enviar solicitud de Manual
ingreso
Recepciona Manual
solicitud
Autorizar ingreso Manual/Sistema
Recepción de Sistema
autorización
Nivel de automatización 66.67%
183
Del gráfico anterior se observa que se ha automatizado algunas actividades del
proceso de control de asistencia, logrando un 66.67% de automatización de este
proceso.
Para medir el nivel de automatización en el proceso de registro de choferes y
camiones se detalla las actividades en la tabla N° 4.3. De donde se define las
actividades que se efectúan manualmente o lo realiza el sistema.
Tabla N° 4.3:
Nivel de automatización del proceso de registro de choferes y camiones
PROCESO ACTIVIDADES SISTEMA O CÁLCULOS
MANUAL
Enviar documentos choferes Manual
y vehículos
Recepcionar documentos de Manual Total # de actividades = 5
choferes y vehículos # Actividades x Sistema = 2
Proceso de Validar documentos Manual Nivel de automatización =
control de Registrar datos en Navis N4 Sistema *100/5 = 40%
asistencia. Registrar datos en DBIS Sistema
COMMTRAC
De la tabla anterior se observa el detalle y cálculo de las actividades que se

encuentran automatizadas para el proceso de registro de choferes y camiones,
es así que, el cálculo del nivel de automatización resulta el 40%.
El siguiente gráfico muestra un resumen del nivel de automatización de los
procesos involucrados en el control de acceso.
Gráfico N° 4.4:
Nivel de automatización en los procesos de control de accesos
70%
60%
50%
Título del eje
40%
30%
20%
10%
0%
HORARIOS ASISTENCIA CHOFERES Y
CAMIONES
Horarios Asistencia Choferes y camiones

Procesos de control de accesos 60% 66.67% 40%

184
Del gráfico anterior mostrado, se obtiene un nivel de automatización promedio
del 55.56%, reduciendo labores manuales, siendo así más eficiente en el
manejo de información entre los sistemas comprendidos.
3.6. EVALUACIÓN DE RESULTADOS Y PRUEBA DE HIPÓTESIS

Para evaluar la variable independiente: Servicio de integración de sistemas, se
muestra un resumen en la tabla 4.4.
Tabla N° 4.3:
Comparativo de variables, antes y después
Indicadores ANTES AHORA
No se contaba con sistemas Se cuenta con cuatro sistemas

Número de aplicativos o integrados. integrados.
sistemas integrados
Falta de capacitación Personal de administración de

de capacitación respecto a sistemas, aplicaciones, base
administración de servicios de datos e infraestructura
Capacitación acerca de de integración. capacitados en
la administración del administración de servicios de
servicio integración al 100%.
- Pruebas de certificación
superadas con éxito al 100%
Pruebas de certificación
La tabla indica que la implementación del servicio se realizó con éxito, superando las
pruebas de certificación en cada una de las interfaces, asimismo se concluyó con la
capacitación a las personas encargadas de la administración de sistemas,
aplicaciones y bases de datos.
Para la variable dependiente: Automatización de los procesos de control se presenta la
evaluación de los indicadores, que son, incidencias ocurridas por errores humanos y
nivel de automatización de los procesos, que se observan en los gráficos N° 4.5 y 4.6
La incidencia ocurrida por error humano es un indicador importante que tiene como
objetivo la eliminación de las fuentes de error y la disminución de sus consecuencias.
En el gráfico N° 4.5 se muestra un comparativo de la cantidad de errores registrados
entre la situación previa a la implementación y la situación posterior a la
implementación.
185
Gráfico N° 4.5:
Comparativo de registro de incidencias por error humano
18
16
14
13
12 12
10
9 Procesos no integrados
8
7 Procesos integrados
6
4
2
1 1 1
0 0 0
1 2 3 4 5
Fuente: Oficina de Control de Accesos APM Terminals SAC.

El gráfico anterior explica que el promedio de la cantidad de errores registrados previa

a la implementación es de 11.4 errores humanos y el promedio de errores registrados
posterior a la implementación es de 0.6 errores humanos, de acuerdo a este resultado
en el cual señala que se ha disminuido considerablemente el número de incidencias
debido a que el porcentaje de reducción es de 94.8%, demostrando que el servicio de
integración de sistemas influye positivamente frente al tipo de error que se está
analizando.
Gráfico N° 4.6:
Nivel de automatización en los procesos de control de accesos
60%
2013 - DESPUES,
56%
50%
40%
Título del eje
30%
20%
2012 -ANTES, 7%
10%
0%
NIVEL D E AUTOMATIZACION DE PROCESOS DE CONTROL DE ACCESOS

186
El gráfico mostrado evidencia que se ha incrementado el nivel de automatización gracias
a la implementación del servicio de integración de sistemas, de la misma forma se
reduce el número de errores humanos, logrado además obtener la información en
tiempo real.
Entonces se puede decir que se ha llegado a cumplir el objetivo de la investigación
donde se determina que el servicio de integración de sistemas influye positivamente en
la automatización de procesos de APM Terminals.
“Por lo tanto se concluye que la Hipótesis es verdadera”.
187
CONCLUSIONES
1. El terminal portuario APM Terminals cuenta con diversos sistemas que trabajaban de
forma independiente, almacenando información que no era compartida entre estos
sistemas, lo cual implicaba la presencia de inconsistencia de datos generando
incomodidad en los estibadores y los usuarios, además esto generaba demoras en ciertas
actividades como es el caso del proceso de control de asistencia.
2. Se ha determinado que el servicio de integración de sistemas, influye de manera positiva

en la automatización de los procesos de control de acceso, reduciendo las actividades
manuales y repetitivas, de forma que disminuye las incidencias ocurridas por errores
humanos, del mismo modo el acceso de la información se da en tiempo real y de manera
confiable.
3. La Metodología Estructurada y el modelo de Integración de Aplicaciones Empresariales

(EAI), a través del uso de la herramienta tecnológica de BizTalk Server hicieron factible
la implementación del servicio de integración de sistemas, habiéndose diseñado y
desarrollado cuatro interfaces que pasaron por pruebas de calidad y finalmente siendo
desplegadas en un ambiente de producción, cumplieron con los requerimientos
inicialmente definidos.
4. La situación actual respecto a la situación inicial tienen un margen de diferencia positivo,

porque a raíz de la implementación del servicio de integración se automatizó los procesos
de control de accesos en un 56%, disminuyendo el número de incidencias por errores
humanos en un 94.8%, permitiendo un control adecuado en el ingreso y salida de los
estibadores, choferes y camiones a las instalaciones de APM Terminals.
188
RECOMENDACIONES
1. Se recomienda hacer seguimiento a los procesos que tienen un bajo nivel de

automatización para ser añadidos al servicio de integración de sistemas, ya que este
servicio busca crear nuevos paradigmas con el objetivo de conectar las aplicaciones
individuales, asegurando que la información en varios sistemas sea consistente y crear
ventajas competitivas futuras para el terminal portuario.
2. Se recomienda realizar el mantenimiento a los servidores de aplicación y base de datos

cada doce meses, para evitar posibles ahogamientos en la ejecución de los procesos
internos de Biztalk y depurar las bases de datos de tracking de Biztalk que almacena la
información desusada de los procesos ejecutados.
3. Se recomienda el uso del Modelo Estructurado y la Integración de Aplicaciones

Empresariales (EAI), en el desarrollo de servicios de integración, ya que su enfoque está
orientado a la necesidad de la organización para el cumplimiento de sus objetivos,
estableciendo fases que van desde la definición de requerimientos hasta la
implementación de un servicio de integración, utilizando la herramienta tecnológica de
Microsoft denominada Biztalk Server 2013, facilitando la implementación de este tipo de
servicios.
189
REFERENCIAS
REFERENCIAS BIBLIOGRÁFICAS
1. Linthicum, D.S. Enterprise Application Integration. Addison-Wesley, Boston-
USA;2000.
2. Sampieri Hernández, Roberto, Collado Fernández, Carlos y Lucio Baptista,
Pilar (2006). Metodología de la Investigación. 4ª Edición. McGraw-
Hill Editores. MéxicoD.F.
3. Brian Loesgen, Charles Young, Jan Eliasen, Scott Colestock, Anush Kumar, Jon
Flanders (2011). Microsoft Biztalk Server 2010 Unleashed. 1ª Edición. Sams
Publishing. Estados Unidos.
4. Kent Weare, Thiago Almeida, Richard Seroter, Carl Darski, Sergei Moukhnitski(2011).
Microsoft Biztalk 2010: Line of Business Systems Integration. 1ª Edición. Packt
Publishing. Estados Unidos.
REFERENCIAS ELECTRÓNICAS
1. Infosys – Powered for intellect, Driven for value (2011). Microsoft Biztalk Server:
Making the Right Choice for Enterprise Integration.
Disponible en: http://www.infosys.com/BPM-EAI/resource-
center/Documents/enterprise-integration.pdf
Accesado el: [31 de enero de 2014]
2. SOA, ESB, BPM, EAI con Microsoft BizTalk Server 2010 (2009).
http://kb.esds.co.in/soa-esb-bpm-eai-with-microsoft-biztalk-server-2010/
Accesado el: [30 de enero de 2014]
3. Dr. Eduardo Suger C. Integración de aplicaciones utilizando XML y Herramientas B2B

(2001). Guatemala: Universidad Francisco Marroquin.
Disponible en: http://msdn.microsoft.com/es-es/library/aa578175.aspx
Accesado el: [01 de febrero de 2014]
190
4. Jeffry Agüero Cordero. Metodología para administrar proyectos de tecnología basados
en arquitectura orientada a servicios (2012). San José, Costa Rica: Universidad para
la Cooperación Internacional.
Accesado el: [01 de febrero de 2014].
Disponible en: http://www.uci.ac.cr/Biblioteca/Tesis/PFGMAP1116.pdf
5. Edison Muñoz Recuay. Integración de Sistemas Heredados, Una Solución para la

Integración de Información (2007). Lima, Perú: Universidad Ricardo Palma; 2007
Disponible en: http://cybertesis.urp.edu.pe/urp/2007/munoz_ef/pdf/munoz_ef-TH.1.pdf
6. Microsoft. Tutorial 1: Integración de aplicaciones de negocios (2006)
Disponible en: http://msdn.microsoft.com/es-es/library/aa578030.aspx
191
ANEXO A
Manual de Instalación de Biztalk Server 2013
192

Implementación y Evaluación Del Servicio PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Implementación y Evaluación Del Servicio PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DEL

CENTRO DEL PERU

FACULTAD DE INGENIERÍA DE SISTEMAS

IMPLEMENTACIÓN Y EVALUACIÓN DEL SERVICIO DE

BELITO SUBILETE, Carmen

DR. HECTOR HUAMÁN SAMANIEGO

A NUESTROS MAESTROS DE LA FIS

A NUESTRO ALMA MATER

Dedicada a nuestros padres, que hicieron

A continuación se presenta el siguiente trabajo de Tesis titulado: Implementación y

Es así que con la metodología de desarrollo de Sistemas y la herramienta tecnología BizTalk

La integración de aplicaciones es un tema importante, debido a la proliferación de distintas

La presente tesis titulada “Implementación y Evaluación del servicio de Integración de

En el tercer capítulo contempla la Intervención Metodológica, se plantea la propuesta

En el cuarto y último capítulo se realiza la validación de la hipótesis y la presentación de los

Finalmente se plasma las conclusiones y recomendaciones suscitadas durante el desarrollo

El presente capítulo abordará el planteamiento del problema, con un breve análisis de la

1.1. PLANTEAMIENTO DEL PROBLEMA

1.1.1. El crecimiento de una organización y su dependencia tecnológica.

En paralelo, las exportaciones continuarían incrementándose aproximadamente

Fuente: Cámara de Comercio Exterior.

Fuente: Fundación Valenciaport

La creciente demanda para el uso del servicio de descarga de las importaciones

Fuente: Fundación Valenciaport.

De lo anterior se visualiza que la estimación de las exportaciones en toneladas

1.1.3. Procesos involucrados en el control de accesos

1.1.3.1. Proceso de gestión de horarios de estibadores

Fuente: APM Terminals – Área de RR.HH.

De la tabla mostrada se detalla que en APM Terminals se manejan tres

Reclamos en el proceso de gestión de

Fuente: APM Terminals – Oficina de reclamos de trabajadores portuarios

En el gráfico mostrado, según fuentes de la oficina de reclamos se

1.1.3.2. Proceso de control de asistencia de Estibadores

Fuente: APM Terminals – Área de Accesos y Seguridad.

En el gráfico mostrado se da referencia al tiempo donde los estibadores

1.1.3.3. Proceso de registro y control de choferes y camiones

1.1.4. Sistemas de información involucrados en APM Terminals

 Access Control System LENEL On Guard (ACS): Aplicación de control de

El sistema ACS (Access Control System) se encuentra en implementación, y

Fuente: Documento del set de aplicaciones de APM Terminals

1.2. FORMULACIÓN DEL PROBLEMA

1.3. OBJETIVOS DE LA INVESTIGACIÓN

1.4. JUSTIFICACIÓN DEL PROYECTO

1.4.2. Justificación Metodológica

1.5.2. Variables e Indicadores de las Hipótesis

Unidad de Instrumento de Fuentes de

Fuente: Documentación del proyecto de integración en APM Terminals

1.6. METODOLOGÍA DE LA INVESTIGACIÓN

1.6.3. Sistema de referencia

Este capítulo se concentra esencialmente en describir y plantear el problema, así como

El proceso de conectar las aplicaciones unas para intercambiar información operativa o

La integración de aplicaciones empresariales es el proceso de vinculación de este tipo de

D. Karin Zaida Acero Navarrete, Danny Humberto Escalante Gallardo (2012).

2.2.1. Un modelo conceptual para la integración empresarial

Fuente: Enfoques de Automatización e Integración de Sistemas Heterogéneos.

a. Nivel 1: Integración basada en redes

La integración en este nivel se realiza mediante la transferencia de

c. Nivel 3: Integración de procesos

En este nivel, dos o más aplicaciones pueden compartir su lógica de

Resuelto el problema de la interacción entre los diferentes equipos, la

e. Nivel 5: Integración empresarial

Persigue la integración de los procesos de decisión, control y manejo

Permite que los procesos de negocios de una empresa se comuniquen