Biztalk adapter for FTP
Access minicomputers and troubleshootingAuthor: Zheng Zuo Date:
SummarySome time ago, when I implemented a BizTalk Server 2006 solution, some functional modules needed to access IBM minicomputers. As a result, I encountered problems when using BizTalk adapter for FTP, the cause is that the FTP receiving adapter has some problems and you have to adjust the data transmission mode locally. Due to the special problem, the author writes down the relevant information and provides a solution for the reference of technical personnel who encounter similar situations.
ExceptionAfter the FTP receiving adapter reads the packets on the minicomputer, it cannot delete the packets on the minicomputer's FTP server. However, the undeleted packets have been read and transmitted on the sending port, in addition, undeleted packets are continuously transmitted through the sending port. If you set a local temporary directory for the FTP adapter and view the temporary directory, you will see that there are packets in the directory that are not processed, and the number of messages cannot be deleted is the same.
Cause AnalysisCheck the running status and exceptions of BizTalk. I first thought of a problem with FTP authorization on the IBM minicomputer. After confirmation, this is not the reason, this is because you can use FTP commands to delete messages that cannot be deleted by the BizTalk FTP receiving adapter. By the way, there is a strange phenomenon that the FTP server connected to the IBM minicomputer via flashfxp 3.5 cannot see the packet file. The IBM minicomputer uses the OpenVMS v6.2 operating system. It seems that you can narrow down the search scope, open the corresponding receiving location in BizTalk, and open the FTP adapter Transmission Properties dialog box. Set the "log" attribute and specify a value to save the FTP operation command log of the FTP receiving adapter. As expected, the problem was found in the generated FTP log. Some log content is as follows:
| > Pwd <257 "edi_message: [MSG. EDI. XML] "is current directory.> type A <200 type set to ASCII.> port 200, <PORT command successful.> list *. log; * <150 opening data connection for edi_message: [MSG. EDI. XML] *. log; * (10.90.1.23, 3375) <directory edi_message: [MSG. EDI. XML] <strong; 2 <130/144 27-dec-2007 15:41:57 [edimsg] (rwed, rwed, re,) <edi_20071227140214.log; 1 <130/144 27-dec-2007 15:33:34 [edimsg] (rwed, rwed, re,) <edi_20071227152250.log; 1 <182/198 27-dec-2007 15:22:50 [edimsg] (rwed, rwed, re,) <total of 3 files, 442/486 blocks <226 List Directory transfer complete.> type I <200 type set to image.> port 200, <PORT command successful.> RETR edi_20071227140214.log <150 opening data connection for edi_message: [MSG. EDI. XML] edi_20071227140214.log; 2 (10.90.1.23, 3376) <226 transfer complete.> dele edi_20071227140214.log <550-failed to delete file edi_message: [MSG. EDI. XML] edi_20071227140214.log; <550 the file specification must contain a version number (even if wildcarded).> type I <200 type set to image.> port 200, <PORT command successful.> RETR edi_20071227140214.log <150 opening data connection for edi_message: [MSG. EDI. XML] edi_20071227140214.log; 2 (10.90.1.23, 3386) <226 transfer complete.> dele edi_20071227140214.log <550-failed to delete file edi_message: [MSG. EDI. XML] edi_20071227140214.log; <550 the file specification must contain a version number (even if wildcarded).> type I <200 type set to image.> port 200, <PORT command successful.> RETR edi_20071227152250.log <150 opening data connection for edi_message: [MSG. EDI. XML] edi_20071227152250.log; 1 (10.90.1.23, 3387) <226 transfer complete.> dele edi_20071227152250.log <550-failed to delete file edi_message: [MSG. EDI. XML] edi_20071227152250.log; <550 the file specification must contain a version number (even if wildcarded).> quit <221 goodbye. |
According to the executed FTP command:> DELE edi_20071227140214.log <550-failed to delete file edi_message: [MSG. EDI. XML] edi_20071227140214.log; <550 the file specification must contain a version number (even if wildcarded ). it can be seen that when the delete operation is executed, the file version number is not added, causing the deletion operation on the minicomputer to fail. If the FTP adapter itself does not provide a good solution, isn't this an FTP adapter bug? I have not found any information that the adapter itself does not support this method.
SolutionBased on the above analysis, there are many solutions. Here we will only introduce several solutions. 1. First thought of using the get and get settings provided on the FTP adapter property. Set the FTP name to be executed (use the Semicolon ";" to separate the names ). However, because it is a formal environment, I do not dare to test it on a minicomputer, and I have not studied it in depth. 2. The simplest implementation is to transmit packets from a minicomputer to a microcomputer server. Run an application on an IBM minicomputer and access the Windows-based FTP server through the application, so as to transmit packets to the Windows platform for further processing by BizTalk. 2. the ideal implementation is to use IBM WebSphere MQ and install IBM WebSphere MQ and BizTalk MQSeries agent on an intermediate window server. The WebSphere MQ on the Windows platform performs message exchange with WebSphere MQ on the minicomputer. Biztalk Server can use MQSeries adapters to access MQSeries on Windows and indirectly interact with minicomputers to support transactions throughout the entire process.
Other InstructionsWhen using the BizTalk FTP adapter to access the IBM minicomputer, you need to set the "representation" of the FTP adapter transmission attribute to "ASCII". If it is set to "binary ", I found that there may be some problems in Packet Exchange Between OpenVMS and windows, but after it is set to "ASCII", the Temporary Folder function of the FTP adapter will not be supported, if a temporary folder is set, you will receive an error message "you can use the Temporary Folder only when sending or receiving files of binary type.
