I recently faced a problem with FTP adapter in BizTalk 2013.
I configured send adapter to send files to ftp server, files are picked up from folder (file transfer) and "passthroutransmit" to send port ftp adapter.
My problem is that file never end in send location (folder on ftp server) however I do not get any error in Biztalk.
I try to unenlist send port and then i get error no subscriber.
I ran out of options, I do not know where to look for error.
Have you guys any idea what it could be?
(as per comments/responses above)
If there are no errors reported and nothing is showing as suspended, it might well be that the files made it to their destination...and were perhaps moved/deleted by something on the target machine (e.g. an automated task or virus checking software).
Related
I want to write a CLLE Program to transfer Files from the IFS to a Webserver.
The Webserver is registered in the Hosttable from the Iseries.
(commandline: CFGTCP -> Option 10 -> Scroll to the Webserver IP)
Current CLLE Program: (only the ftp-access)
PGM
OVRDBF FILE(INPUT) TOFILE(CMDDTAR7_2/US9FIP) OVRSCOPE(*JOB)
OVRDBF FILE(OUTPUT) TOFILE(CMDDTAR7_2/US9FOP) +
OVRSCOPE(*JOB)
FTP RMTSYS('10.1.2.99')
ENDPGM
After i call my Program i get some results in a PF-File.
The Results are in German but i translated shortly for you.
The Connection is unavalable to 10.1.2.99 on Port 21. Try it again later.
[...]
My Question at the end.
Do you have some solutions for me to transfer xml files to my Webserver from the iseries?
You're writing about a web server and you want to transfer files by ftp. Perhaps you're mixing up protocols here. I'll concentrate to resolve your apparent ftp connection problem.
Seems that the destination host 10.1.2.99 doesn't accept connections on Port 21.
Please make sure, there's no firewall or other stuff blocking your request to the destination host. Moreover, on the host 10.1.2.99 try telnet 10.1.2.99 ftp or ftp 10.1.2.99 in a command window, depending on OS and installed components.
Before automating, just test manually if you can successfully connect and log in via standard command line: ftp 10.1.2.99.
Transferring data by FTP is just fine in a local LAN. Beware that any data including username and password will be transferred in clear text and thus can be possibly read by others as the intended hosts.
Following up to your comment: Actually there are many possibilities to copy files. If you're running a recent version of IBM i, I'd opt for using scp. It's encrypted and thus safe for running outside of local LANs. Great to automate by utilizing Key-Authentication instead of passwords. And many web hosting companies offer scp/sftp access.
When using "revert -a" through P4V it waits for a few minutes and throws this error back at me.
RpcTransport: partial message read
TCP receive failed.
read: socket: WSAECONNRESET
The server status returns fine and there are no locked database files.
I suspect this problem is local to this computer as others don't have the same issue. Issueing the same command through the command prompt just has the command prompt sit there indefinitly.
Other commands such as submit and add will have the visual client sit there indefinitely but does not throw and error.
The files are stored on a local drive. This happens with multiply depots/workstations.
The 'WSAECONNRESET' error is issued by Windows, when a network socket is forcibly closed.
Regular occurrences of this error can indicate network problems.
More information is available here:
http://answers.perforce.com/articles/KB/2968/
Hope this helps,
Jen!
I got the same on windows machine. I guess in my case it was caused by corrupted config settings and because of popup error message I had no chance to set it correctly via GUI.
The command line SET command helped to set port and host name again:
p4 set P4PORT=<portnum>
This command reenables the GUI config dialog
A few years late, but for those still facing this:
I faced this error when fetching files from a large repo. I believe what caused this for me was low internet upload speeds due to which - even though I had high a download speed - the TCP acknowledgment from my computer was not getting sent, causing a connection failure.
Perform an upload speed test to determine if it is very low (in my case it had dropped to less than 0.1 Mbps). Fixing upload speeds is a separate topic, but in case it helps try restarting your router as a first step.
Apologies if this is a pretty simple question, but I'm pretty new to IWS.
When ever I startup IWS (it's running on Microsoft Server that I remote desktop into) and enter my login details I get this message:
Failed to start TCP/IP Server, please check if the TCP port is already in use
During this same session I will also get the message below whenever I try to change tags in my trend sheets:
WARNING: Tag changes in any trend group will only take place in the next day history file.
It seems any changes I make in relation to tags and driver sheets are ignored and I want to know if this is related to the above error messages and how do I go about debugging/fixing this?
Note: I do not get these messages in other IWS sessions on other servers and I don't experience these problems.
Projects running the TCP/IP Server task use a TCP Port that is defined in the InduSoft Project Settings - Communication tab. By default, InduSoft uses port 1234. The error message you mention can occur if another process binds to that port before InduSoft has started the TCP/IP Server task.
Change the TCP Port. 1234 is the standard Port for Indusoft.
Try to Map your useds Ports before chosing some.
Or kill the process that are using the Port 1234, as explained in the link.
https://receitasdecodigo.com.br/java/listar-e-matar-processo-pela-porta-em-uso-no-windows-pelo-cmd
When trying to receive a (large, approx. 100MB) file using an FTP adapter in BizTalk 2006, we run into the following problem, which causes the file to be processed over and over again.
Retrieving the file succeeds; it is placed into the MessageBox and processed properly
When the FTP adapter issues the DELE statement, it never reaches the FTP server the file is on (we have verified this by taking a look at the FTP server's logs)
there are no signs of timeouts on the FTP server; the FTP server log does not mention a timeout occurring
After the interval time set on the adapter expires, the FTP server will still find the large file that we have already processed in the previous run, because the DELE statement failed
The event log in BizTalk states that ‘The connection to the FTP server was broken prematurely’. That is why we think there is a timeout issue.
We have seen that retrieval of the file takes around 35 minutes. The FTP server timeout is set to 1 hour. no problems there I guess.
Then we found the following article: http://www.ncftp.com/ncftpd/doc/misc/ftp_and_firewalls.html#FirewallTimeouts. It states that a firewall / routing device might be responsible for the timeouts. The team managing our firewalls and routers told us that there were no timeouts set here.
Which leaves us in the dark on the cause of our problem. Does anyone of you have any suggestions? Or even better, the solution!!
Have you tried the solutions in this article?
I avoid using the FTP adapter. Instead I use a third party utility to retrieve files and move the transferred file to a file adapter receive location. Third party utilities allow you to configure rules, recovery actions etc, freeing BizTalk from having to manage the transfer.
I'm battling a really weird problem here. I have a Windows 2008 R2 server with Message Queueing installed. On another machine, running Windows 2003 is a service that is set up to send messages to a public queue on the 2008 server. However, messages never show up on the server.
I've written a small console app that just sends a "Hello World" message to a test queue on the 2008 machine. Running this app on XP or 2003 results in absolutely nothing. However, when I try running the app on my Windows 7 machine, a message is delivered just fine.
I've been through all sorts of security settings, disabled firewalls on all machines etc. The event log shows nothing of interest, and no exceptions are being thrown on the clients.
Running a packet sniffer (WireShark) on the server reveals only a little. When trying to send a message from XP or 2003 I only see an ICMP error "Port Unreachable" on port 3527 (which I gather is an MQPing packet?). After that, silence. Wireshark shows a nice little stream of packets when I try from my Win7 client (as expected - messages get delivered just fine from Win7).
I've enabled MSMQ End2End logging on the server, but only entries from the messages sent from my Win7 machine are appearing in the log.
So somehow it seems that messages are being dropped silently somewhere along the route from XP or 2003 to my 2008 server.
Does anyone have any clues as to what might be causing this mysterious behaviour?
A fellow named John Breakwell (http://blogs.msdn.com/johnbreakwell/default.aspx) answered to my tweets on this and pointed me to one of my own clues, namely the ICMP "Port Unreachable" one.
He referred me to a technet article that tells you how to re-enable the ping service running on port 3527. A simple registry hack was all it took (and a restart of MSMQ) and now my Win2008 server is happily receiving messages :-)