Erro de conexão do adaptador BizTalk DB2
https://stackoverflow.com/questions/24915
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Meus colegas estão tentando conectar o BizTalk 2006 R2 via adaptador DB2/MVS a um banco de dados hospedado no mainframe z/OS.Ao testar as configurações de conexão, eles estão recebendo o seguinte erro
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
Ao colocar as configurações em uma string de conexão normal e abrir com código .NET, tudo bem.Sou novo no BizTalk e no DB2.Alguém pode sugerir o que procurar quando esse erro surgir?
24 de agosto de 08:
Bem, se for usado código .NET normal com uma cadeia de conexão DB2 normal, a conexão poderá ser feita e as consultas enviadas.O que este adaptador DB2 está relatando é que ele não consegue nem mesmo fazer um handshake de conexão adequado, muito menos enviar consultas.Não tenho certeza de quais são os mecanismos reais envolvidos para fazer uma conexão com o DB2 acontecer.
25 de agosto de 08:
De acordo com esta postagem nos fóruns do MSDN, parece ser um problema de login.
Eu vi isso e não é o caso aqui.Se colocarmos o nome de usuário como Coleção de Pacotes, ainda teremos o mesmo problema.
26 de agosto de 08:
Devido à escassez de informações sobre a conexão com bancos de dados DB2 de mainframe de produtos Microsoft, assumi a tarefa de inspecionar pacotes de rede brutos para obter uma pista do que está acontecendo entre a conexão do provedor .NET DB2 (que funciona) e o adaptador BizTalk 2006 DB2 (que bombas).Observei que o tráfego do DB2 é feito usando o protocolo DRDA.E finalmente concluiu que o método do adaptador BizTalk falha devido ao que está registrado no pacote SECCHKRM de resposta do 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 que as mesmas credenciais falham aqui enquanto são bem-sucedidas no provedor .NET está além da minha compreensão.No momento, o que posso observar é uma diferença marcante entre cada método no que diz respeito à sequência de pacotes transferidos.
Provedor .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
É interessante ver o provedor .NET emitir vários pacotes do protocolo DRDA em um único segmento TCP.O adaptador BizTalk, por outro lado, coloca apenas um pacote de protocolo por segmento TCP.Não sei por que isso acontece.No entanto, no momento acho que isso é uma pista falsa e a verdadeira diferença que causa a falha na autenticação está na troca de dados DRDA.Não conheço o protocolo DRDA, então terei que estudá-lo antes de poder entendê-lo melhor.
18 de setembro de 08:
Neste estágio, o problema ainda não foi resolvido, pois a obtenção da cooperação da equipe do DB2 DBA e da ajuda da Microsoft encontrou muitos obstáculos.
O que quero relatar é que observei talvez uma diferença crucial entre todos os casos de conexão bem-sucedida e a tentativa fracassada:
O adaptador BizTalk DB2 está usando subjacentemente Driver Microsoft ODBC para DB2.Os outros testes de software bem-sucedidos fazem uso de CONTROLADOR ODBC IBM DB2 ou DRIVER IBM DB2 ODBC – IBMCL1.A configuração dos parâmetros do driver IBM é diferente do driver da Microsoft.Mas não vemos nenhuma diferença obviamente crítica que possa levar a uma falha na autenticação do driver da Microsoft.
Solução
Ora, certamente a Microsoft demorou tempo suficiente para confirmar isso explicitamente:
conexões proxy via DB2Connect não são suportadas pelo BizTalk DB2 Adapter
Como a política do nosso cliente é acessar somente bancos de dados DB2 via DB2Connect, o adaptador está fora de questão.
MAIS INFORMAÇÕES DE FUNDO
A razão pela qual o Adaptador DB2 funciona apenas para uma conexão direta com um host de mainframe z/OS é devido a restrições legais.Tecnicamente é possível trabalhar uma conexão com o DB2Connect, mas a IBM tornou-o um nó prioritário e impediu que outras partes estabelecessem legalmente a sequência DRDA correta para se conectar a ele.
Outras dicas
Eu nunca usei esse adaptador além de mim mesmo, então estou supondo, mas talvez tenha a ver com a conta que o BizTalk está usando para conectar ou suas portas não estão configuradas corretamente.
De acordo com esta postagem nos fóruns do MSDN, parece ser um problema de login.
