Errore di connessione dell'adattatore BizTalk DB2
https://stackoverflow.com/questions/24915
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
I miei colleghi stanno tentando di connettere BizTalk 2006 R2 tramite un adattatore DB2/MVS a un database ospitato sul mainframe z/OS.Durante il test delle impostazioni di connessione, viene visualizzato il seguente errore
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
Quando si inseriscono le impostazioni in una normale stringa di connessione e si apre con codice .NET, va bene.Sono nuovo in BizTalk e DB2.Qualcuno può suggerire a cosa prestare attenzione quando viene visualizzato questo errore?
24 agosto 08:
Bene, se viene utilizzato il normale codice .NET con una normale stringa di connessione DB2, è possibile stabilire la connessione e inviare le query.Ciò che segnala questo adattatore DB2 è che non riesce nemmeno a effettuare un corretto handshake di connessione, per non parlare dell'invio di query.Non sono sicuro di quali siano i meccanismi effettivi coinvolti per realizzare una connessione DB2.
25 agosto 08:
Secondo questo post sul forum MSDN, sembra che sia un problema di accesso.
L'ho visto e non è il caso qui.Se inseriamo il nome utente come raccolta di pacchetti, si verifica ancora lo stesso problema.
26 agosto 08:
A causa della scarsità di informazioni relative alla connessione ai database DB2 mainframe dei prodotti Microsoft, ho intrapreso il compito di ispezionare i pacchetti di rete non elaborati per avere un'idea di cosa sta succedendo tra la connessione del provider DB2 .NET (che funziona) e l'adattatore DB2 BizTalk 2006 (che bombe).Ho osservato che il traffico DB2 viene eseguito utilizzando il protocollo DRDA.E alla fine ha concluso che il metodo dell'adattatore BizTalk fallisce a causa di ciò che è registrato nel pacchetto SECCHKRM di risposta del server
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
Il motivo per cui le stesse credenziali falliscono qui mentre hanno successo nel provider .NET è oltre la mia comprensione.In questo momento, quello che posso osservare è una marcata differenza tra ciascun metodo per quanto riguarda la sequenza dei pacchetti trasferiti.
Fornitore DB2 .NET
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
Adattatore 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 osservare che il provider .NET emette vari pacchetti di protocollo DRDA all'interno di un singolo segmento TCP.L'adapter BizTalk invece inserisce un solo pacchetto di protocollo per segmento TCP.Non so perché sia così.Tuttavia, al momento penso che sia una falsa pista e la vera differenza che causa l'errore nell'autenticazione è nello scambio di dati DRDA.Non conosco il protocollo DRDA quindi dovrò studiarlo prima di poterne capire meglio.
18 settembre 08:
In questa fase il problema non è ancora risolto, poiché ottenere la collaborazione del team DBA di DB2 e l'aiuto di Microsoft ha incontrato molti ostacoli.
Quello che voglio segnalare è che ho osservato forse una differenza cruciale tra tutti i casi di connessione riuscita rispetto al tentativo fallito:
L'adattatore BizTalk DB2 sta utilizzando in modo sottostante Driver Microsoft ODBC per DB2.Vengono utilizzati gli altri test software che hanno successo DRIVER ODBC IBM DB2 O DRIVER ODBC IBM DB2 – IBMCL1.La configurazione dei parametri del driver IBM è diversa dal driver Microsoft.Ma non vediamo alcuna differenza evidentemente critica che possa portare ad un'autenticazione fallita per il driver Microsoft.
Soluzione
Perché, Microsoft ha impiegato sicuramente abbastanza tempo per confermarlo esplicitamente:
le connessioni proxy tramite DB2Connect non sono supportate da BizTalk DB2 Adapter
Poiché la politica del nostro cliente prevede l'accesso ai database DB2 solo tramite DB2Connect, l'adattatore è fuori questione.
ULTERIORI INFORMAZIONI DI BASE
Il motivo per cui l'adattatore DB2 funziona solo per una connessione diretta a un host mainframe z/OS è dovuto a restrizioni legali.Tecnicamente è possibile effettuare una connessione con DB2Connect, ma IBM lo ha reso un nodo prioritario e ha impedito ad altre parti di stabilire legalmente la sequenza DRDA corretta per connettersi ad esso.
Altri suggerimenti
Non ho mai usato questo adattatore tranne me stesso, quindi immagino, ma forse ha a che fare con l'account che BizTalk utilizza per connettersi o che le tue porte non sono configurate correttamente.
Secondo questo post sul forum MSDN, sembra che sia un problema di accesso.
