Error de conexión del adaptador BizTalk DB2
https://stackoverflow.com/questions/24915
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Mis colegas están intentando conectar BizTalk 2006 R2 a través del adaptador DB2 / MVS a una base de datos alojada en el mainframe z / OS. Al probar la configuración de conexión, reciben el siguiente error
Could not connect to data source 'New Data Source':
The network connection was terminated because the host failed to send any data.
SQLSTATE: 08S01, SQLCODE: -605
Al colocar la configuración en una cadena de conexión normal y abrirla con un código .NET, está bien. Soy nuevo en BizTalk y DB2. ¿Alguien puede sugerir qué buscar cuando surge este error?
24 de agosto de 08:
Bueno, si se usa un código .NET normal con una cadena de conexión de DB2 normal, la conexión puede realizarse y enviarse consultas. Lo que informa este adaptador de DB2 es que ni siquiera puede hacer un protocolo de enlace de conexión adecuado, y mucho menos enviar consultas. No estoy seguro de cuáles son los mecanismos reales involucrados para que se realice una conexión de DB2.
25 de agosto de 08:
De acuerdo con esta publicación en los foros de MSDN , parece ser un problema de inicio de sesión.
He visto eso y ese no es el caso aquí. Si ponemos el nombre de usuario como la colección de paquetes, sigue teniendo el mismo problema.
26 de agosto de 08:
Debido a la escasez de información con respecto a la conexión a las bases de datos de mainframe DB2 de los productos de Microsoft, asumí la tarea de inspeccionar los paquetes de red sin procesar para obtener una pista de lo que sucede entre la conexión del proveedor de .NET DB2 (que funciona) y el BizTalk. Adaptador de DB2 2006 (que bombardea). Observé que el tráfico de DB2 se realiza utilizando el protocolo DRDA. Y finalmente concluyó que el método del adaptador BizTalk falla debido a lo que está registrado en el paquete SECCHKRM de respuesta del servidor
DRDA (Security Check)
DDM (SECCHKRM)
Length: 55
Magic: 0xd0
Format: 0x02
0... = Reserved: Not set
.0.. = Chained: Not set
..0. = Continue: Not set
...0 = Same correlation: Not set
DSS type: RPYDSS (2)
CorrelId: 0
Length2: 49
Code point: SECCHKRM (0x1219)
Parameter (Severity Code)
Length: 6
Code point: SVRCOD (0x1149)
Data (ASCII):
Data (EBCDIC):
Parameter (Security Check Code)
Length: 5
Code point: SECCHKCD (0x11a4)
Data (ASCII):
Data (EBCDIC):
Parameter (Server Diagnostic Information)
Length: 34
Code point: SRVDGN (0x1153)
Data (ASCII): \304\331\304\301@\301\331z@\301\344\343\310\305\325\343\311\303\301\343\311\326\325@\206\201\211\223\205\204
Data (EBCDIC): DRDA AR: AUTHENTICATION failed
Por qué las mismas credenciales fallan aquí al tener éxito en el proveedor .NET me supera. En este momento, lo que puedo observar es una marcada diferencia entre cada método cuando se trata de la secuencia de paquetes transferidos.
Proveedor de .NET DB2
No. Time Source Destination Protocol Info
1 0.000000 [client IP] [DB2 server IP] TCP kpop > 50000 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=1
2 0.000399 [DB2 server IP] [client IP] TCP 50000 > kpop [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0
3 0.000414 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1 Ack=1 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
4 0.000532 [client IP] [DB2 server IP] DRDA EXCSAT | ACCSEC
5 0.038162 [DB2 server IP] [client IP] DRDA EXCSATRD | ACCSECRD
6 0.041829 [client IP] [DB2 server IP] DRDA ACCSEC | SECCHK | ACCRDB
7 0.083626 [DB2 server IP] [client IP] TCP 50000 > kpop [ACK] Seq=108 Ack=542 Win=65535 Len=0
8 0.190534 [DB2 server IP] [client IP] DRDA ACCSECRD | SECCHKRM | ACCRDBRM | SQLCARD
9 0.199776 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
10 0.293307 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
11 0.293359 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
12 0.293377 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=1444 Win=64092 [TCP CHECKSUM INCORRECT] Len=0
13 0.293404 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
14 0.293452 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
15 0.293461 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=2516 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
16 0.293855 [DB2 server IP] [client IP] TCP [TCP segment of a reassembled PDU]
17 0.293908 [DB2 server IP] [client IP] DRDA SQLDARD
18 0.293918 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=3588 Win=64464 [TCP CHECKSUM INCORRECT] Len=0
19 0.293957 [DB2 server IP] [client IP] DRDA QRYDSC
20 0.294008 [DB2 server IP] [client IP] DRDA QRYDTA
21 0.294017 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=870 Ack=4660 Win=65536 [TCP CHECKSUM INCORRECT] Len=0
22 0.294023 [DB2 server IP] [client IP] DRDA SQLCARD
23 0.295346 [client IP] [DB2 server IP] DRDA RDBCMM
24 0.297868 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
25 0.421392 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
26 0.456504 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA | ENDQRYRM | TYPDEFNAM | SQLCARD
27 0.456756 [client IP] [DB2 server IP] DRDA RDBCMM
28 0.488311 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
29 0.498806 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
30 0.630477 [DB2 server IP] [client IP] TCP 50000 > kpop [ACK] Seq=5157 Ack=1579 Win=65171 Len=0
31 0.788165 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA
32 0.788203 [DB2 server IP] [client IP] DRDA ENDQRYRM
33 0.788225 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1579 Ack=5815 Win=64380 [TCP CHECKSUM INCORRECT] Len=0
34 0.788648 [client IP] [DB2 server IP] DRDA RDBCMM
35 0.795951 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
36 0.807365 [client IP] [DB2 server IP] DRDA PRPSQLSTT | SQLATTR | SQLSTT | OPNQRY
37 0.838046 [DB2 server IP] [client IP] DRDA SQLDARD | OPNQRYRM | TYPDEFNAM | QRYDSC | QRYDTA | ENDQRYRM | TYPDEFNAM | SQLCARD
38 0.838328 [client IP] [DB2 server IP] DRDA RDBCMM
39 0.841866 [DB2 server IP] [client IP] DRDA ENDUOWRM | SQLCARD
40 0.973506 [client IP] [DB2 server IP] TCP kpop > 50000 [ACK] Seq=1906 Ack=6304 Win=65482 [TCP CHECKSUM INCORRECT] Len=0
Adaptador BizTalk DB2
No. Time Source Destination Protocol Info
1 0.000000 [client IP] [DB2 server IP] TCP 28165 > 50000 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2 0.002587 [DB2 server IP] [client IP] TCP 50000 > 28165 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0
3 0.010146 [client IP] [DB2 server IP] TCP 28165 > 50000 [ACK] Seq=1 Ack=1 Win=65536 Len=0
4 0.019698 [client IP] [DB2 server IP] DRDA EXCSAT
5 0.020849 [DB2 server IP] [client IP] DRDA EXCSATRD
6 0.034699 [client IP] [DB2 server IP] DRDA ACCSEC
7 0.036584 [DB2 server IP] [client IP] DRDA ACCSECRD
8 0.042031 [client IP] [DB2 server IP] DRDA SECCHK
9 0.046350 [DB2 server IP] [client IP] DRDA SECCHKRM
10 0.046642 [DB2 server IP] [client IP] TCP 50000 > 28165 [FIN, ACK] Seq=160 Ack=200 Win=65336 Len=0
11 0.053787 [client IP] [DB2 server IP] TCP 28165 > 50000 [ACK] Seq=200 Ack=161 Win=65536 Len=0
12 0.056891 [client IP] [DB2 server IP] DRDA ACCRDB
13 0.058084 [DB2 server IP] [client IP] TCP 50000 > 28165 [RST, ACK] Seq=161 Ack=295 Win=0 Len=0
Es interesante observar que el proveedor .NET emite varios paquetes de protocolo DRDA dentro de un solo segmento TCP. El adaptador de BizTalk, por otro lado, coloca solo un paquete de protocolo por segmento TCP. No sé por qué esto es así. Sin embargo, en este momento creo que es un arenque rojo y la verdadera diferencia que causa la falla en la autenticación está en el intercambio de datos DRDA. No conozco el protocolo DRDA, así que tendré que estudiarlo antes de que pueda darle más sentido.
18 de septiembre de 08:
En esta etapa, el problema aún no se resuelve, ya que la cooperación del equipo DBA de DB2 y la ayuda de Microsoft se han encontrado con muchos obstáculos.
Lo que sí quiero informar es que he observado quizás una diferencia crucial entre todos los casos de conexión exitosa versus el intento fallido:
El adaptador BizTalk DB2 está utilizando de manera subyacente Controlador ODBC de Microsoft para DB2 . Las otras pruebas de software que tienen éxito utilizan IBM DB2 ODBC DRIVER o IBM DB2 ODBC DRIVER & # 8211; IBMCL1 . La configuración de parámetros del controlador de IBM es diferente del controlador de Microsoft. Pero no vemos ninguna diferencia obviamente crítica que pueda conducir a una autenticación fallida para el controlador de Microsoft.
Solución
Por qué, ciertamente le tomó a Microsoft el tiempo suficiente para confirmar esto explícitamente:
las conexiones proxy a través de DB2Connect no son compatibles con BizTalk DB2 Adapter
Dado que la política de nuestro cliente es acceder solo a las bases de datos de DB2 a través de DB2Connect, el adaptador está fuera de discusión.
MÁS INFORMACIÓN DE ANTECEDENTES
La razón por la cual el Adaptador de DB2 solo funciona para una conexión directa a un host de mainframe z / OS se debe a restricciones legales. Técnicamente, es posible trabajar una conexión con DB2Connect, pero IBM lo ha convertido en un nodo prioritario e impidió que otras partes establezcan legalmente la secuencia DRDA correcta para conectarse a él.
Otros consejos
Nunca he usado este adaptador, pero yo mismo, así que supongo, pero quizás tenga que ver con la cuenta que BizTalk está utilizando para conectarse o si sus puertos no están configurados correctamente.
De acuerdo con esta publicación en los foros de MSDN , parece ser un problema de inicio de sesión.
