file load featur for all users
what are the pros and cons of file load through JavaClient and Webclient?
I have a situation, where for end user delight. file load feature is identified.
1) Should we give access to mass user for mass load?
2) is the a performance hit or architecture wise
3) What is the most simplified approach for file load without impacting or changing existing architecture to provide capability for mass load and mass users.
File load from the web client requires the source file to be on the application server. The java client can upload files from the PC it is running on. So to use the web client you also have to provision by FTP or similar the ability for the user upload the files to the application server
FileLoad is intended to allow large numbers (> 100) of attachments to be processed at one time. Note that if index files are greater than 10K records, things can sometimes crash without much explanation. As Adrian noted, there are significant differences between using FileLoad from the Java client and from the web client (I always use the Java client version). Make sure the users understand this and know how to create index files correctly. The major performance hit is usually from having to move the files from wherever they are located to the Agile file vault – when moving multiple GB of files around, the network can slow down a LOT. So I usually recommend that the files to be attached be local to the server on which DFM and the file vault reside, thus removing the network from the equation.
The most efficient means of importing large numbers of attachments is to create a read-only custom vault, put the files there and use the INPLACE option in the index file. Doing this eliminates the need to move the files around, they are already where they will need to be. So all FileLoad has to do is create the database records that link the file to it’s intended object. Note that this can only be done using the Java client, and it does require some up-front setup (moving the files to the read-only vault), but Fileload can easily attach 5K files/hour using this option.
But seriously, letting 10’s (or hundreds) of users run FileLoad (possibly at the same time) probably won’t be very good for performance. To run it efficiently requires a fair amount of setup and planning. It would probably be better to assign responsibility to run FileLoad to one or 2 folks (maybe a small group of folks), have other users request to have files attached, and then have the designated folks make sure things are ready and schedule when things will run. For 10-20 files or less, it is just as easy to attach them manually from the web client as it is to create the index file, get the files where they need to be and run FileLoad.
Hello deshmukh2,
Speaking for IS management and administration side, normal end system users and also power users should not be granted the capability to load thousands of files in the same time. This user scenario normally happens when preforming data migration and first system set up.
To every day users, the ability to load files should (in my opinion) should be kept using the normal UI, and simply by teaching them to (1) zip all the files needed to be loaded (2) select unzip in the web interface when loading the files.
My own expectance is working on SoS projects which also include civil engineering and drawings.
Best regards,
RZ
To see how to create an index file, look in the Import/Export User Guide for the chapter/appendix on using FileLoad (it is usually the last one). It explains everything you need to know about using FileLoad and creating index files.