Are you running the Remote option, or IFS managed cloud offering? FTP is only supported in the Remote option.

Hello Mathias,

We are running Remote option. IFS Cloud is hosted in private data center

Regards

Pankaj

Thanks! And which version?

The reason I ask is that I heard there is a fix of a third party library used by the containers, which solves a FTP network problem that we have seen.

Hello Mathias,

thanks for your quick response. We are using 21r2. 

please suggest

Regards

Pankaj

Hi again,

I had a look and there is a framework fix that is/well be part of 21R2 SU3 that has at least fixed another FTP issue. It’s hard to say it will fix this one or not.

Which SU are you on?

Also, you say the upload does not give any errors, but is the file stored in the FTP server?

Hello Mathias,

We are on SU - 21R2SU2

1. we can view the existing documents which were added in previous version
2. When we create new document. it does not add in FTP but does not give error

Please suggest

Regards

Pankaj

Hi Mathias,
thank you for your inputs. We have upgraded to SU2 recently and we found there is little bit different behavior on SU2. It seems the document is loaded and stored to FTP, but can not be opened in IFS application. Moreover there is slightly different behavior/issues when you have IFS Aurena Agent installed. Pls. see the attached document on this case.
Ticket Form for Case - IFS Customer Support
This is go/live critical issue for us and we need to get all the issues fixed with SU3. I appreciate you support and prioritization on this.
BR Jan

 

@ORFJAN I think we should continue discuss your particular issues in support, since we started there (and I would not want us repeat the same things here as we do in support, or the other way around). I am sure the “2nd line” people there are working hard to help you and they will take help from us at R&D when they need to.

The Aurena Agent can for sure change the behavior the user see, but it should neither make the FTP support work better or worse. What we have seen though, when working with Shared repos, is that you can actually get more error details from the server when running with the Aurena Agent, which is often helpful when trouble shooting these kinds of issues (it helped us in a recent customer issue).

So I guess that can be a tip for both you and @pgupta . Use the Document Revision page. Create a document of a class that uses FTP storage. Then check in a file with the Aurena Agent enabled. Hopefully you might see more details than (“The document repository does not work”, or whatever that standard message say)

Hi Mathias,
thanks for coming back on this. Of course it’s not worth to do any double work, however sometimes there is a long way (and time) to get the case to R&D for the correction. 

Since we are going live with IFS Cloud 21R2 in 03/22 and this is critical functionality, we need to fix the issues with SU3, SU4 latest, so I would like to ask you to prioritize the case within R&D because it’s obvious there is a bug when opening the document in IFS.

I would like to highlight that on 21R2SU2 there is no issue to upload the file to FTP repository, the file is there and if you download the file via a FTP client the file is ok, the only issue is to open the document in IFS (error message is given).

IFS Azure Agent should improve the functionality but my perception is totally opposite when trying to upload the document.

• drag and drop is not available
• only limited file extensions are available for upload (pdf is missing)
• poor performance (it takes longer to load the file)

Let’s hope the FTP problem can be sorted out. It’s most probably not a problem with Docman, but a problem with “the container”. Not that it helps you when I say that… :)

As for the drag and drop support, we have good reasons to disable it when the Aurena Agent is enabled. The short story is that current web browsers stops us from having the close interaction we would need for both of those “things” to work together. It is impossible, for example, to use the agent to upload a file that was selected using drag and drop. That, in turn, means we will not be able to execute any check in macros, or bring with us any view copies, since both those features require the agent.

If all registered file extensions is not there when using the aurena agent, we need to fix that. Could be that we missed to add file extensions that are of the Document Type VIEW. You might be able to workaround that by allowing all file extensions (type *.* in the file selection dialog).

Did you compare the file download or upload times with and without the agent? The agent takes sometimes up to a second to run, and has some other small overhead as well, but the actual uploads and download time happens via the same channels. For really small files I am sure there can be a difference.

Hi Mathias,
thanks for the follow up and explanation on Aurena Agent limitations.
Do you think we can still get the POD issue corrected with SU3 to be able to preview documents in IFS application? 
Aurena Agent issues does not seems to be live critical, but the problem with the file extensions should be definitely fixed once you reach the priority.
Thanks Jan

Do you think we can still get the POD issue corrected with SU3 to be able to preview documents in IFS application? 

Since I have not yet been involved in these issues, can you explain what mean with “the POD issue”? Do you refer to the FTP problem or something else?

Also, when you say “preview”, do you refer to the built-in image viewer in IFS and viewing documents there? Or normal document download?

By the way, since we have recent experience and know this works for other customers running IFS Cloud using the Remote option, would you consider using a Shared repository if the FTP issue takes longer time to sort out than what we want? This could be a temporary solution or a permanent one. The other customer I am thinking about like the Shared repository option a lot and was happy when they could get it to work in IFS Cloud as well (I think they used IFS Apps 9 and IEE earlier).

Sorry by POD I meant the “the container” issue you was mentioning in the previous post.
The preview of the document is giving error, pls. see screenshots below.
The download is making the file download, but the file can not be opened since it’s having 0 size.
Regarding the Shared repository workaround proposal, I can not see that feasible. We have thousands of docs stored on the FTP related to Product Development.
However I have to say we also use DB repository for some document classes and those documents are working well too.  

 

Mathias, I just wanted to mention that I’m ok to have a screen sharing session if you like to demonstrate and discuss the issues.

Thanks!

Regarding the Shared repository workaround proposal, I can not see that feasible. We have thousands of docs stored on the FTP related to Product Development.

I see. Again, it could just be a workaround until the FTP problem has been sorted out.

You might not know or realize this, but it is also possible to “relocate” your current FTP files to a Shared repo with some file copying plus database table changes.

You “only” need to understand how the (very few) underlying tables are structured and you can with quite little effort copy the FTP files to a share and then update “the file and repository tables” to point to the share instead. We are talking directly updating the database tables here, which may sound scary but is not very much scary I recently replied to another post which describes the different tables that are involved:

Again, could be a workaround or a permanent solution. Good to be prepared for the worst, right? :)

And the above would assume you can get a Shared repo working first. We know it works but it can take time finding the correct set up.

Hi Mathias,
thanks for sharing, we will check the option further however seeing how many issues/gaps/redesigns is connected with the upgrade from IFS10 to IFS Cloud it’s another effort and complexity we adding here and not sure we have capacity for. If you see feasible to have FTP issue fixed with SU4 I would prefer to go that way.

Thanks Jan

I hear you… Let’s hope that we can recreate the FTP issue internally first, then try to find what the underlying problem can be.

As mentioned above, a fix was done in the container/POD area which fixed at least one specific FTP issue. What surprises me about your problem is that the upload goes well, that is something I don’t remember seeing when we have had FTP problems of our own.

@ORFJAN 

Hi again, I have tested FTP repositories now, in our internal environment:

• Latest IFS Cloud 21R2 (this is in our development environment)

• FileZilla FTP server (64 bit) installed on a Windows Server 2012 R2, username = guest, password = guest, virtual path = / mapped to c:\docman\ftp, with full read and write access

• I used the machine name and not the IP in the repository setup in Docman. Set / as path there. No port set (will default to 21 on the server).

Upload AND download works. In the FTP server log we can see both the upload and download that is done from the IFS Odata container working well.

The only problem is after the download is finished, the client aborts the connection and this shows as an error in the FTP server. The file downloads though, without any visible error on the client side.

If you try to download with the Aurena Agent enabled, do you get any detailed error message showing up in the toast in the lower right corner? By using the Document Revision page you should be able to see any server error. The client errors pasted earlier in this post does not give any clues unfortunately (this is often the case, that we want to see the server errors since the client error is sometimes just a side effect of the server error).

Some questions as well:

1. Which FTP server do you use?
2. Are there any logs you can look at there?
3. Have you enabled support for passive FTP on the server and in your firewall? IFS uses passive nowadays, while we used active before (a change we had to make due to moving into containers).

Thanks!

Also, do you use the IP address or machine name in the repository set up?

Hi @Mathias Dahl , let me reply on question #1 n the attached document, I will be coming with the rest of the points during the day. Jan

Ref. 1. we use FTP with IIS on Windows Server 2012, passive mode supported, proved with FTP client WinSCP in passive mode. Yes we use IP address for the repository.

Document with screenshots was attached to the case.
Ticket Form for Case - IFS Customer Support

Thanks, @ORFJAN Looks good, I think.

About this that you wrote:

I would like to highlight that on 21R2SU2 there is no issue to upload the file to FTP repository, the file is there

I am sometimes very paranoid when it comes to what information I get using technical investigations like these so I must ask: how do you see that the file has been uploaded correctly? If you look “in the FTP server”, then it’s fine. If you trusted Docman that the upload went well, because there were no errors, well, then it is not always the case that it went well :-p

So, assuming the upload works, it’s strange that the download does not, and I cannot explain it. My only theory is that there is a “communication problem” between the FTP library we use in Java inside the IFS Odata container, and the FTP server. What would be good to try is to run an FTP session from the same machine where the containers run, to the FTP server. And try both upload and download, using passive FTP. EVEN better is to try the same thing from INSIDE the OData container. We’ll see if it will come to that. We might need to test that because the container itself “has a network”, with settings and even a firewall I think. So even if the communication works on the machine where the container runs, it could still be that the communication does not work from inside the container.

With all that said, I will now await some more information from you :)

I am sometimes very paranoid when it comes to what information I get using technical investigations like these so I must ask: how do you see that the file has been uploaded correctly? If you look “in the FTP server”, then it’s fine. If you trusted Docman that the upload went well, because there were no errors, well, then it is not always the case that it went well :-p

Yep, I used WinSCP FTP client to connect to FTP server and I can see the file there. Pls. see screenshot in the last attachment. 

When you try to download the document, do you see any server errors? Please see what I wrote above on how you might be able to see some server errors, using the Aurena Agent and the Document Revision page.

Also, do you have any log information from the download that Docman does?

Hi @Mathias Dahl ,
I have uploaded following to the case.

• document with screenshots from my further testing
• FTP log - but no errors found with there
• dump from IFS application server

Unf. not too much error messages around, if needed we can have a screen sharing session to look at this together.
Thanks Jan

@Mathias Dahl I found some FTP related ERROR entries in the APP dump, attached to the case.