Question

IFS Cloud - Document Management

  • 17 January 2022
  • 39 replies
  • 1109 views


Show first post

39 replies

Userlevel 7
Badge +30

@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)

 

Userlevel 3
Badge +7

Hi Mathias,
pls. find new document attachment to the case with my findings. I used curl to retrieve the pdf file from FTP. I run the command from:
1. MTS Ubuntu OS - works fine, ending with status 226
2. oData container in K8s - does not work, ending with status 550, despite K8s firewall disabled

I would like to highlight also screenshot with FTP log for both scenarios, for scenario #2 it seems the Data Channel is closed with status 258. And I noticed that  the IP address of the client is missing on these lines. It seems the Data Channel communication is not somehow routed back to K8s cluster. Or any other idea?
Thanks Jan

Userlevel 3
Badge +7

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

Userlevel 3
Badge +7

Hi Mathias,
yesterday we were trying to monitor the network traffic from linux box to FTP server with using tcpdump  and we were trying to see the difference between upload and download.
We recognized there is no traffic initiated to FTP server on the port where the download is supposed to happen.
While you are investigating we can also try to use another FTP server (with newer OS then WS2012) whether we see the same behavior.  
BR Jan
 

Userlevel 3
Badge +7

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)
Userlevel 3
Badge +7

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

Userlevel 7
Badge +30

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).

 

Userlevel 3
Badge +7

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

Userlevel 7
Badge +30

Thanks for the update. If you can, add the same information on the case/ticket so we have the full information there. I can see that we have now got a comment from the other R&D team, in Jira. Not sure if it has yet reached you via ServiceNow. I will have a look at it now.

I would not expect the FTP server being the culprit here, given the tests that you have done, rather it is the container. It works “outside” the container, from the Linux machine that hosts the containers. It does not make sense to me that the FTP server should be causing the problems.

At the same time, it’s worth trying. I am often wrong :)

 

Userlevel 3
Badge +7

Hi Mathias,
thanks for update, I will post the update to the case too.
No new info/findings have arrived on this via case, so I appreciate to get any.
You are most probably right with the FTP server. So let’s see the finding you have.
Thanks Jan

Userlevel 3
Badge +7

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.  

 


  

 

Userlevel 3
Badge +7

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.

Userlevel 7
Badge +30

Got some questions from a colleague. I copied them to the case.

 

Userlevel 7
Badge +30

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.

 

Reply