Deprecation of the FTP and Shared repository types in Docman in 24R1 - a heads-up

Hi Mathias,

Regarding possible deprecation of the db option I am for the moment maybe too stuck in “old” pros we’ve been communication for a while now, to be able to see this is a good way to go. There are of course cons with db storage as well (like db size and recovery issues) but the pros I’m thinking of are;
- Easy copying of a prod environment to test retaining documents and connections,
- SOX (Sarbanes Oxley) support for tracking read and write activities on files,
- Strong security (Oracle as a container also for the documents).

Are there any means to mitigate or meet those arguments in a solution with only “external” storage?

Regards,
Erik

By having fewer repository options we will save time spent on maintaining them, and we can spend that time on "fun" things which will benefit customers. Also, FTP support is getting rather long in the tooth and does not provide much benefit over IFS Cloud File Storage, provided by the platform.

Hi!

A more technical question related to the subject. It is specific for Remote Deployment but also interested for Cloud Deployment.

The document files are temporarily stored in the Application Server when working with IFS Applications 10 and older (at least IEE version).

How does it work in IFS Cloud?
Will the documents be temporarily stored somewhere during the process or will they “only” pass by the Kubernetes Cluster on the way to the client? 

Best regards,
Stefan

Seems these options are there for ages. Thus, I’m a bit skeptic about the workload spent in support. We’ve been smart enough to let our customers choose between remote and Cloud hosting, which a differenciator from the competition. Even if Cloud hosting on Azure is in our favor from a business perspective of course. It’s like we want our customers choose the most expensive option with file storage or premium database.

Thanks, @william.klotz, I added a link to the technical documentation on IFS Cloud File Storage now. So, you are all good now, right? :-) 

Thanks @BytBeatbW 

We are aware of the fact that not all functionality that worked with a Database repository in Docman works with File Storage. I think there is a plan to handle each gap there.

As for the problem you mention (archiving reports in Docman), depending on your usage, it should not be a problem to keep those types of documents in the database, even if the bulk of your documentation reside in File Storage. I say "depending on your usage" because it might be that you are archiving so many documents that it becomes a problem with the database size growing too much. Archiving reports doesn't strike me as a process that should fill the database too much though, but then again I don't know how many reports your customers are archiving…

This issue has little to do with the deprecation of FTP and Shared repository types though, and much more to do with the long term focus on File Storage.

Although it's related, it's not the same thing. We have not decided to remove the Database repository type yet.

The data is never stored on disk in the "middle tier" (a Kubernetes cluster with multiple containers), but the data will of course go through it, via the network calls that streams the files from and to the backend storage.

@Mathias Dahl  @JohannesWittwer Correct.  Cloud storage for documents is not allowed for certain types of documentation in the US utility industry (sensitive documents that expose cyber security risks).  Also for companies that serve both commercial and defense industries that do not have a full requirement to be in gov cloud but do have some classes of documents that are ITAR (drawings) or have similar requirements.

The ability to have an on prem/noncloud  document vault/repository is a critical requirement.

It sounds like from your description that you will not support a cloud deployment with a non cloud external repository.  This is a problem not only with new cloud prospects, but preventing existing customers from moving to the IFS Cloud.

Dean

@Mathias Dahl  by number of releases you mean IFS Cloud.  because  this was supported up through IFS 10 and had been since I started working with IFS in 1997.    What you have essentially done is remove functionality that customers have been using for 20+ years and have now prevented them from using IFS in the Cloud.   

You have also hampered any efforts to sell IFS in the Cloud to any new customers that have regulatory requirements or the desire to store documents externally for other reasons i.e. size, network distribution, etc.  We will now need to either get them to pay the 30% premium to move into Gov Cloud or recommend they go on prem, which will probably get us eliminated from opportunities that are looking for cloud solutions.

If your goal is to get all of the customers into the IFS hosted cloud, this just worked against that.

This isnt about people who want more options and capabilities, it is about you taking away options and capabilities they already have with out asking.  and now you are also only enabling 1 external location?   You do realize that IFS is a multi country, multi company application?   we utilize the multiple location capabilities to segregate documents across companies in IFS as well.   

I am getting the feeling that R&D is not thinking through these changes or asking any of their customers or partner about the impact of removing functionality prior to doing so.

Dean

@Caleb Dahl   For companies that are commercial and sell to A&D, they may only have a few documents that are ITAR controlled, usually drawings or images of the part.   they cannot put those documents into a cloud repository whose infrastructure is not ITAR controlled or meets the stringent requirements that we see in the GOV cloud.  However, with an external repository that is secured and controlled,  they can still link those documents to objects in IFS.    That is the impact with respect to external repository.   The other issue is the limitation of the number of repositories, the limitation to one file storage repository is also problematic even if the customer is in the GOV cloud.  even with in the ITAR and defense requirements there are always requirements for encapsulation such that documents across programs are not co-mingled.  this is also a challenge for multi company, multi national companies that wish to keep physical documents segregated based on company or country.   Israel, France, China, Canada are all examples where you would want to segregate and regionalize the document repositories for security and performance reasons.

@Mathias Dahl the terminology and implications of this are incredibly confusing. what is the reason these options are going to be done from a technical standpoint? We have constant sales pressure to sell deals and storage options is discussed on almost every deal. Limiting options here could be lose deals in the multiple millions of dollars. The documentation implies to use anything other than Internal the customer needs to be using Remote (aka on-premise deployment) which IFS does NOT want to sell. 

@DeanBurell 

It seems your idea ended up as a new post in this forum. You need to post it in the Ideas section.

Thanks!