Erreur de connexion de l'adaptateur BizTalk DB2
https://stackoverflow.com/questions/24915
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Mes collègues tentent de connecter BizTalk 2006 R2 via l'adaptateur DB2/MVS à une base de données hébergée sur le mainframe z/OS.Lors du test des paramètres de connexion, ils obtiennent l'erreur suivante
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
Lorsque vous placez les paramètres dans une chaîne de connexion normale et que vous les ouvrez avec du code .NET, tout va bien.Je suis nouveau sur BizTalk et DB2.Quelqu'un peut-il suggérer ce qu'il faut surveiller lorsque cette erreur apparaît ?
24 août 08 :
Eh bien, si du code .NET normal avec une chaîne de connexion DB2 standard est utilisé, la connexion peut être établie et les requêtes soumises.Ce que cet adaptateur DB2 rapporte, c'est qu'il ne peut même pas établir une liaison de connexion appropriée, et encore moins soumettre des requêtes.Je ne suis pas sûr de quels sont les mécanismes réels impliqués pour établir une connexion DB2.
25 août 08 :
Selon cette publication sur les forums MSDN, cela semble être un problème de connexion.
J'ai vu cela et ce n'est pas le cas ici.Si nous mettons le nom d'utilisateur comme collection de packages, nous rencontrons toujours le même problème.
26 août 08 :
En raison de la rareté des informations concernant la connexion aux bases de données DB2 mainframe à partir des produits Microsoft, j'ai entrepris d'inspecter les paquets réseau bruts pour avoir une idée de ce qui se passe entre la connexion du fournisseur .NET DB2 (qui fonctionne) et l'adaptateur BizTalk 2006 DB2. (qui bombarde).J'ai observé que le trafic DB2 s'effectue à l'aide du protocole DRDA.Et finalement conclu que la méthode de l'adaptateur BizTalk échoue en raison de ce qui est enregistré dans le paquet SECCHKRM de réponse du serveur.
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
Pourquoi les mêmes informations d'identification échouent ici alors que le fournisseur .NET réussit me dépasse.À l'heure actuelle, ce que je peux observer, c'est une différence marquée entre chaque méthode en ce qui concerne la séquence de paquets transférés.
Fournisseur .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
Adaptateur 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
Il est intéressant de voir le fournisseur .NET émettre divers paquets de protocole DRDA dans un seul segment TCP.L'adaptateur BizTalk, en revanche, ne place qu'un seul paquet de protocole par segment TCP.Je ne sais pas pourquoi.Cependant, je pense pour le moment qu'il s'agit d'un faux-fuyant et que la véritable différence provoquant l'échec de l'authentification réside dans l'échange de données DRDA.Je ne connais pas le protocole DRDA, je devrai donc l'étudier avant de pouvoir lui donner plus de sens.
18 septembre 2008 :
À ce stade, le problème n’est toujours pas résolu, car la coopération de l’équipe DB2 DBA et l’aide de Microsoft se sont heurtées à de nombreux obstacles.
Ce que je veux signaler, c'est que j'ai observé peut-être une différence cruciale entre tous les cas de connexion réussie et ceux de tentative ratée :
L'adaptateur BizTalk DB2 utilise sous-jacente Pilote Microsoft ODBC pour DB2.Les autres tests logiciels qui réussissent utilisent PILOTE ODBC IBM DB2 ou PILOTE ODBC IBM DB2 – IBMCL1.La configuration des paramètres du pilote IBM est différente de celle du pilote Microsoft.Mais nous ne voyons aucune différence manifestement critique pouvant conduire à un échec d’authentification pour le pilote Microsoft.
La solution
Eh bien, il a certainement fallu assez de temps à Microsoft pour confirmer explicitement ceci :
les connexions proxy via DB2Connect ne sont pas prises en charge par l'adaptateur BizTalk DB2
Étant donné que la politique de notre client consiste à accéder uniquement aux bases de données DB2 via DB2Connect, l'adaptateur est hors de question.
PLUS D'INFORMATIONS GÉNÉRALES
La raison pour laquelle l'adaptateur DB2 fonctionne uniquement pour une connexion directe à un hôte mainframe z/OS est due à des restrictions légales.Techniquement, il est possible d'établir une connexion avec DB2Connect, mais IBM en a fait un nœud prioritaire et a empêché d'autres parties d'établir légalement la séquence DRDA correcte pour s'y connecter.
Autres conseils
Je n'ai jamais utilisé cet adaptateur sauf moi-même, donc je suppose, mais cela est peut-être dû au compte que BizTalk utilise pour se connecter ou à vos ports qui ne sont pas configurés correctement.
Selon cette publication sur les forums MSDN, cela semble être un problème de connexion.
