Skip to Content

How to test a FTP connectionÂ… with a generic PI Scenario

I was surprised by the topic of this Michal’s blog: “3 ways to check an FTP connection from PI” Michal’s PI tips: 3 ways to check an FTP connection from PI, as for me it was like an “easy” info, but he is right, maybe it’s not “easy” for everybody.


 So I would like to share with you a fourth method that I often use, and especially in production for the cut-over tasks that I do before the Go-Live of a new third-party / legacy (as I do not want to wait the 1st exchange of business data to discover that something is wrong). My “solution” is just to develop a tiny and generic Scenario in PI which can be used as a tool to test a FTP connection to a file server.


Thanks to this scenario, we will control:

–         the FTP connection from PI server itself (*) (like a Ping or a Telnet)

–         the FTP authorization / credential (logon user/password)

–         the FTP user’s rights (write / read / delete)

 (*) when you use FileZilla, you test the connection from your laptop. But if your laptop is not on the same network than this one of your PI server (!)… in fact you test nothing and you cannot say your “PI server <–> FTP server” connection is fully operational.


PI version: all (written in PI 7.0)



No need to define ESR objects. So it could be written directly in PI production… if there is an emergency to do such a control. Personally, I recommend you to define this flow in PI dev and transport it until PI prod.



As a file will be created in the file server of your third-party / legacy, do not forget to communicate with them!! Because maybe they have some restrictions about that, like a script which checks the format of all arrived files… Your goal is to test a connection, not to produce issue in your third-party system!


Detail of this Scenario:

Reminds: no I.R / ESR object.


Create a Scenario “_TOOLS_FileServerConnection” like that:



So on which we have:

Sender Business Component (Business Service)



Sender Communication Channel


(see detail below)

Sender Interface



Sender Namespace






Receiver Business Component (Business Service)



Receiver Communication Channel


(see detail below)

Receiver Interface



Receiver Namespace






Interface Determination



No Mapping…



(1) I use the same name for my sender and my receiver, because I use this flow in both direction “PI -> 3rd party” and “3rd party -> PI”.

(2) use what you want, as this object is not declared in ESR, but use the same name for the whole flow.

(3) as my sender / receiver interfaces do not the same name, I had to create an Interface Determination. If you use the same “dummy” name, Interface Determination is useless.


For the Communication Channel, I use the ASMA (Adapter-Specific Message Attributes) option to avoid managing filename. By this way, my target filename is the same and so it will be easy for me after that to delete it (see below the chapter “Exchanged flows”).


Sender Communication Channel:

To pick-up my test file from either a laptop or an internal file server (not the 3rd party).



Receiver Communication Channel:

To write my test file on my 3rd party file server.



As target is retrieved by ASMA, the file name scheme is unused. So write what you what.


Create a dummy test file.

Personally, inside my test file, I precise a sentence like that “This is a non-production file to test the connection servers. For any inconvenient, please contact xxx at xxx”.


Exchanged flows:

Thanks to this PI scenario, I will do the following tests, mainly to control the user’s rights (read / write / delete) of the folder(s) providen by my 3rd party for its FTP server.


For that I do three tests (three runs of my PI scenario after having change the sender/receiver hostname / folder / user account in my CC, without to change the rest of PI scenario):

  1. Move a file from our internal File Server (A) to the Legacy File Server (B) to be tested.
  2. Remove this created file to our File Server (A) by using option “Archive”. (without timestamp!)
  3. Remove this created file to our File Server (A) by using option “Delete”.


Thanks to these three simple tests, we check the connection, the user credential but also the user’s rights (read, write delete). Moreover, at the end of these three tests, our “test” file has been deleted…


Variant N°1:

If your third-party uses a SFTP connection, you can easily test it by doing the same with a SFTP adapter.


Variant N°2:

Coming soon in another blog…



By writing this blog, I clearly did not invent the wheel… but that could help some to have another alternative to check a FTP / SFTP connection, before a Go-Live, for instance.

1 Comment
You must be Logged on to comment or reply to a post.
  • Thank you for this excellent description. Unfortunately SAP does not provide a SFTP adapter.

    I can recommend AEDAPTIVe Solutions (www. adapter. Especially with the PGP module added will it bring your secure communication to a maximum level.