Skip to main content

Deprecation of the FTP and Shared repository types in Docman in 23R2 - a heads-up

 

This post is only relevant for Remote customer installations. For managed cloud customers, FTP and Shared document repositories are NOT supported.

 

This is a heads-up on IFS deprecating support for the FTP and Shared repository types in Docman in IFS Cloud 23R2, for complete removal in 24R1.

If you have customers using these two repository types today, you should plan for migrating to Database or File Storage.

If you are planning to implement this in Remote Deployment in IFS Cloud right now, you should reconsider, and use File Storage or Database.

In Remote deployment, File Storage will still have support for local/external storage (outside the database) by supporting SMB/network shares.

 

BACKGROUND

 

Back in the day, Docman started out with support for "external" file storage via our support for FTP and Shared (folders) as the only repository types. Later, Database storage was added upon request from customers. And, much later (IFS Cloud 21R2), IFS Cloud File Storage was added as yet another repository option where, initially, File Storage was limited to Cloud Deployment where Azure Storage is used as the backend.

Recently, IFS Cloud File Storage got support for Remote Deployment, where a shared network folder can be selected for storing files.

 

TODAY

 

We are now in a position where we can remove the support in Docman for FTP and Shared repositories since every customer, from IFS Cloud 23R2 and later, will have two options for document file storage: "internal(inside the database) and "external" (outside the database).

Read about the capabilities of IFS Cloud File Storage here, before you continue reading:

https://docs.ifs.com/techdocs/23r1/030_administration/210_cloud_file_storage/#introduction

Some customers in Remote Deployment might want to use their FTP servers or multiple existing shared network folders. Although there is of course a benefit to this, we think that one "external" file storage option should really be enough and customers should be able to change to use fewer options.

We are considering deprecating the Database repository option as well at some point, but that has not been decided yet. If you have use cases where you think this is strictly needed, let us know.

 

WHAT HAPPENS NOW?

 

This deprecation will be communicated officially via the release notes in IFS Cloud 23R2 GA, but we wanted to communicate this as early as possible, to avoid unnecessary migration work.

Documentation on migration paths will be available soon. We already have migration tools for migrating customers from Database, FTP, and Shared repositories to File Storage and we will work on making them even better.

Comments, questions?

UPDATE, November 2024

Although the support for Shared and FTP repositories are still deprecated (it will be removed in a coming release), it's still available. However, since 24R1 it's disabled by default. Refer to our release notes for information on how to enable it again. Before you do that though, please consider migrating to one of the other options we have: Database or File Storage.

 

What are the implications to A&D customers under ITAR?


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


@Caleb Dahl   The only option if they want external or non-cloud repository is to implement on-prem or remote,  but even in this case my understanding is that they will still be limited to 1 database and 1 fileshare.

 


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


@Caleb Dahl 

The documentation implies to use anything other than Internal the customer needs to be using Remote (aka on-premise deployment)

This post is about the deprecation of options in Remote deployment only.

Both Cloud and Remote deployment will continue to have an internal and external storage option, and both can be used in the same installation.

As for the reasons why we do this, I will have to refer to my original post as well as some of my answers for the first couple of comments. If things are still not clear, ask away and we will try to answer.

 


@DeanBurell 

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

Thanks!

 


@DeanBurell 

Also, your post is missing important details:

R&D has decided to drop support for external document repositories which has been core capabilities for at least 20 years.

Firstly, we remove two of three external storage options when using Remote deployment. Cloud deployment remains unchanged. Cloud deployment is limited compared to what you have been used to in IFS Applications, yes. It's been like that for three years.

Secondly, both Cloud and Remote deployment will have a internal (database) and an external (IFS Cloud File Storage) option.

What is missing to fulfill the requirements you mention is a way to configure IFS Cloud File Storage to support multiple network shares. That's what you should ask for when you create your idea.


No what I want is the solution to support multiple repositories and external non-cloud repositories as the current functionality in IFS 10 supports and every previous version since IFS 98. Just having multiple shares in the cloud is not enough.


No what I want is the solution to support multiple repositories and external non-cloud repositories as the current functionality in IFS 10 supports and every previous version since IFS 98. Just having multiple shares in the cloud is not enough.

Firstly, I want to ask you to try to be more explicit with your terminology. It's hard to make out what you mean and it then becomes hard for me to comment. 

For example, the use of the word "cloud" in your comment above. Do you refer to the product IFS Cloud or Cloud deployment or cloud computing in general? And please be specific, on every point you make, if you mean Remote or Cloud deployment, otherwise we cannot communicate clearly.

I also think you don't understand my proposal for an idea here on IFS Community, because I think it will solve the problems you describe and its very similar to what are describing that we have had for many years. I will try to explain the idea again:

The idea is for Remote Deployment only, which is IFS term for on-premise, which is about using your own hardware or someone else's cloud.

I argue that, on a high level, it's exactly the same thing to have IFS Cloud File Storage support multiple shares, as having Docman support different shares or FTP servers/folders today. If IFS Cloud File Storage supported multiple shares we could point out different shares to be used for different classes. I didn't describe the idea in this level of detail earlier since it was obvious to me, so apologize for that.

Is it clearer? If not, I can try to explain the idea with some images/diagrams or even fake screenshots.

If we had the feature I'm thinking about we would essentially replace Docman's own support for multiple shares or FTP folders with IFS Cloud File Storage and multiple shares pointed to from Docman.

I have some comments too, especially regarding the performance argument, which is simply not true, not even in Apps 7.5 to Apps 10, since all file transfers go via the application server which will be the bottleneck. So, an end use would not benefit from downloading a document from a local file share if the application server is far away.

Your other arguments, which are mostly centered around physically separating groups of files (for different reasons), have some merits but the devil is in the detail. We need to remember that, even if documents are separated on different shares, all network traffic anyway goes through a single point. This is why our customer SAAB, which need to follow export control regulations, cannot fully use Docman for all their document management. At any rate, my proposed idea is equally good, or bad, depending on how you see things. Again, on a high level, because there is of course a technical difference between using an FTP server and Windows file share.

All of the above applies to Remote Deployment only. As you know, IFS Cloud in Cloud Deployment does not support storing documents on hardware owned by the customer. There we only support database or IFS Cloud File Storage with Azure Storage as the backend. That's a business decision made by IFS (not "R&D") when IFS Cloud was first released. I urge you to file a separate idea about that if you want that to be taken into consideration, but I suspect this has been asked for and dismissed several times already. I haven't been part of such discussions but. I have heard about some of the reasons for not supporting it and if you want to challenge that, it's better done using a separate idea or discussion. If you want I can make the right people join in and comment on that topic.

Thanks for the feedback on comments on our original post, getting comments like these was partly why we shared it here on IFS Community.


 

 

@Mathias Dahl  “As you know, IFS Cloud in Cloud Deployment does not support storing documents on hardware owned by the customer. There we only support database or IFS Cloud File Storage with Azure Storage as the backend. That's a business decision made by IFS (not "R&D") when IFS Cloud was first released.”

This is the problem.  IFS wants all customers to move to the hosted cloud, but is removing functionality that would enable them to do so.  IFS wants to promote that the IFS applications is one product and is the same whether implemented in the IFS Cloud or Remote,  a key selling point that differentiates us from our competition.  and what you are saying here is that it is different and functions different.

Multiple shares/repositories in the cloud does address the issue of segregation of files, and that is a good thing and will address one of the use cases of multi company and multi country.

Based on your comment regarding performance,  I could be wrong but in earlier versions of IFS the ftp was implemented in the thick client, not the application server.  in either case if find it interesting that you would not implement across multiple regions for performance, especially with global companies.

Regarding “all network traffic anyway goes through a single point. This is why our customer SAAB, which need to follow export control regulations, cannot fully use Docman for all their document management.”    Explain your reasoning behind this,   

We have print servers and other services that connect IFS to on-prem solutions, seems like it would be better to resolve the issue so our customers can get the full value of IFS Docman rather than forcing them to either not use the solution or be limited.


@Mathias Dahl Seems ridiculous to have to create an idea for this as if it were new functionality rather than functionality that already exists that you are taking away.

It's new functionality to add support for multiple storage locations in IFS Cloud File Storage. IFS Cloud File Storage is and will be our main way/service to store files, like the name suggests.

Also, Docman and IFS Cloud File Storage are being developed and maintained by two different teams, with different priorities. It might not be optimal, but it is how it is.


@dean

This is the problem.  IFS wants all customers to move to the hosted cloud, but is removing functionality that would enable them to do so.  

IFS probably want that, yes, but still see that there is a need for “on premise” in some cases. Here, the needs of cloud operations, and the certifications they work hard to adhere to, conflicts with the need of some customers, and then another option is needed (“Remote”). It makes sense to me.

IFS wants to promote that the IFS applications is one product and is the same whether implemented in the IFS Cloud or Remote,  a key selling point that differentiates us from our competition.  and what you are saying here is that it is different and functions different.

Let’s sat that IFS Cloud consists of, say, one million “features” (~8000 different object types, where each object type surely have hundreds of behaviors or features, on average).

I don't think it's unreasonable that, due to the very different "execution context" (public cloud, with all that entails when it comes to security, for example vs on premise hardware controlled by customer), a few of those features will not work the same, or cannot be implemented in either of the deployment options.

Based on your comment regarding performance,  I could be wrong but in earlier versions of IFS the ftp was implemented in the thick client, not the application server.

We left the thick client when we released Apps 7.5, over 10 years ago. Since then, all file transfers have been going via the application server.

...in either case if find it interesting that you would not implement across multiple regions for performance, especially with global companies.

I think it's not impossible to get there, but we need more features to get there, each one needs to be prioritized and investigated and I think our cloud operations would also need to evolve to support that.

We have print servers and other services that connect IFS to on-prem solutions

I didn't know that and since that's news to me I cannot comment on if it's relevant or not to the discussion.

Regardless, was I able to explain to you clearly what the idea is that you need to register, about IFS Cloud File Storage supporting multiple shares (and Docman needs to be adjusted to use that feature)?

 


Hi @Mathias Dahl , will you by this also extend the possibility to use Azure blob storage on the Remote solution to. Many customers is using Azure as the hosting platform for IFS cloud already and supporting blob storage from azure in the remote solution instead of starting with smb file share ++ in azure


@kjro That’s not in the plans as I understand things, no.

@chanaka-shanil - FYI

 


Hi @Mathias Dahl ,

 

I must have read your initial email 4 or 5 times and I didn’t get it until your last response where I decided to reference the online documentation and go through the IFS Cloud File Storage information.  Then I read your initial email again and I understood what the second paragraph under TODAY was saying.  

I would recommend you include this reference to the documentation will visually really shows what you are explaining.  For me it really did the trick.

 

https://docs.ifs.com/techdocs/23r1/020_lifecycle/100_file_storage_service/#introduction

 

Regards,

William Klotz

Unfortunetaly the link does not seem to be available any more … 


Hi @Mathias Dahl ,

 

I must have read your initial email 4 or 5 times and I didn’t get it until your last response where I decided to reference the online documentation and go through the IFS Cloud File Storage information.  Then I read your initial email again and I understood what the second paragraph under TODAY was saying.  

I would recommend you include this reference to the documentation will visually really shows what you are explaining.  For me it really did the trick.

 

https://docs.ifs.com/techdocs/23r1/020_lifecycle/100_file_storage_service/#introduction

 

Regards,

William Klotz

Unfortunetaly the link does not seem to be available any more … 

Thanks for reporting that. Seems the document moved here:

https://docs.ifs.com/techdocs/23r1/030_administration/210_cloud_file_storage/#introduction

I updated the link in my original post.


What I have understood is that it is only possible to define one File Storage location in Cloud version.

This will cause problems for e.g. Defence industry when classified document shall be stored. The demand is that they must be stored in the country where the XC license is valid.

For an installation where there are sites in different countries it must be possible to define more than one location as each country have their own XC licenses.

How is this demand addressed in the change of the functionality?


Hi Mikael,

What I have understood is that it is only possible to define one File Storage location in Cloud version.

Correct. In Cloud Deployment, all files are stored in Azure Storage and in Remote Deployment all files are stored under one SMB/Samba/Windows network share.

This will cause problems for e.g. Defence industry when classified document shall be stored. The demand is that they must be stored in the country where the XC license is valid.

For an installation where there are sites in different countries it must be possible to define more than one location as each country have their own XC licenses.

It's a problem but it's not a new problem and we haven't supported that since Apps 7 when our "fat Windows client" directly communicated with the document file repository. The change/deprecation we intended to communicate through this post does not change anything related to what you wrote there.

How is this demand addressed in the change of the functionality?

It's not addressed now and it was not addressed since Apps 7 (which had it's own problems, mostly from a security point of view).

To summarize, we argue that the change/deprecation neither makes the situation better or worse with regards to the requirement you describe (which is about ITAR, Export Control, whatever you want to call it).

Is it clear?

 


Hi @Mathias Dahl

 

As always, thanks for sharing and providing valuable clarifications. I may add just one more related question connected to one of our customers.

They are on 23R2 and planning to move to 24R1 before going LIVE later in the year. It’s a Cloud Deployment and currently uses the default Database as the File Storage option. They won’t move from Database to File Storage. As indicated in the documentation (Index - Technical Documentation For IFS Cloud), the File Storage uses an Azure Blob Storage Account to store files in the Cloud deployment model. Is it possible to have a completely different Azure subscription for this Azure Blob Storage?

Thanks

Kelum Ferdinandez


Hi @Kelum-WIA 

 > currently uses the default Database ... They won’t move from Database to File Storage

Do you know why? File Storage is cheaper and backup and restore operations quicker.

> the File Storage uses an Azure Blob Storage Account to store files in the Cloud deployment model. Is it possible to have a completely different Azure subscription for this Azure Blob Storage?

This is really a question about the IFS Cloud File Storage feature and not Document Management, but no, not as far as I know.

Any comments, @chanaka-shanil ?

 


Thanks @Mathias Dahl

They are mainly looking for a cheaper alternative due to the rapid growth of the DB due to documents. As they already have a separate Azure subscription, the idea is to utilize that.  

Maybe there is no price difference from azure perspective. Still, they would like to explore all possible options before deciding.

Thanks for directing to @chanaka-shanil 

Cheers !

 

 


Thanks @Kelum-WIA 

Then I think they should migrate to FS now. We have a built-in assistant for that. As I said, I don't think they will be able to use another Azure Storage account, so they will not save money that way, but they should save money on not using the more expensive database storage, so it should be a win anyway.


Agree. I’ll wait for @chanaka-shanil thoughts from the IFS Cloud File Storage side before returning to the customer

Thanks again, @Mathias Dahl.

Cheers


Hi @chanaka-shanil,

May I get your advice on the matter, please. 

Your support is much appreciated.

Thanks

 


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


Reply