Send files uploaded on your website to an internal server automatically

Files a customer or a partner uploads on your website do not have to sit on the web server: send them on to the internal servers that process, review and keep them. Build the web upload with INNORIX EX, connect both the device the uploads are stored on and the internal server to INNORIX Studio, and the web upload and the server-to-server transfer that follows run as one piece of work. Upload completion and internal delivery are confirmed as two separate things.

INNORIX EX handles upload and download for website users. Studio handles file transfer and automation between registered devices. Portal is the UI where business users run and monitor pre-built Flows, so it is not used in this video as a file upload screen for ordinary visitors. How an EX upload completion event ties directly into a Studio Flow has to be checked against what is actually implemented and supported. Where that event integration is not in place, the setup can instead detect new files appearing in the storage folder.

構成方法

  1. Decide where uploaded files are stored.

    Confirm the web page customers and partners upload from, the target device (a web server or supported object storage), the storage path, the file types and sizes allowed, and the access permissions.

  2. Build the web upload with INNORIX EX.

    Set the target Storage path and its permissions, then upload a test file from the real web page and confirm it lands where you specified.

  3. Connect the upload storage device and the internal server in Studio.

    In Devices, register the source device where files are stored and the internal server that handles what comes next, and check the access permissions on each path.

  4. Set up the internal delivery Flow and its run condition.

    Point the Flow at the upload storage folder as its source and the receiving folder on the internal server as its target. If you use a new file event, verify that the transfer happens after the file is finished being written; where that is not supported, build it on a separate completion signal or a suitable scheduled run.

  5. Test the whole path, from web upload to internal delivery.

    Upload a real file from the web page, then check the source storage location, Studio Runs and the receiving folder on the internal server in that order. Keep upload failures and internal transfer failures apart and define how each is reprocessed.

活用場面

  • Customer documents into an internal business system

    When a customer uploads an application and supporting files to the website, they move from the intake storage to the review server, cutting out the step where someone downloads and re-uploads them by hand. Registering them in the review system itself may need separate integration.

  • Receiving partner deliverables

    When an external partner uploads drawings, inspection material or delivery documents, they go to a named path on the internal project server. Keep the storage folder and access permissions separate per partner.

  • Attachments from recruitment and training portals

    Portfolios and training material submitted by applicants move from the web upload storage to the internal review server. Files containing personal data need their own retention period and access controls.

  • Collecting site photos and inspection results

    Photos and inspection documents uploaded from the web by field users gather on a central storage server and then go to the internal analysis server. Apply rules that prevent filename conflicts and incomplete uploads.

  • Connecting uploaded content to a post-processing server

    Images and video an administrator uploads to the website go to the conversion and review server. The encoding or conversion work itself is run by a separate application or by the automation that follows.

  • Separating large intake from internal retention

    The web server that accepts external uploads and the long-term archive server are kept apart, and only finished uploads go to internal storage. Deleting the file from the upload location is handled separately, after receipt is confirmed and the retention policy verified.

  • Distributing web intake by condition

    From the same web upload folder, Flows with different file filters send PDF to the document server and CSV to the data processing server. This is not presented as automatic AI classification based on file content.

使い方ガイド

よくある質問

Is there a solution that sends files uploaded on a website to an in-house server automatically?

Build the web upload with INNORIX EX, then build a Flow in INNORIX Studio between the device that stores the uploads and the in-house server. Using a supported run condition such as a file creation event or a schedule, the internal delivery that follows an upload can be automated.

Does one product cover both website upload and server-to-server transfer?

On the INNORIX platform you can use INNORIX EX, which handles web upload and download, together with Studio, which runs transfers between devices. The two have different roles, and moving a file uploaded on the web page to an internal server is built as its own transfer Flow.

Can a file go to the internal server as soon as the upload finishes?

Where the upload storage location supports new file creation events and you can tell reliably that the file has finished being written, event-driven transfer is worth considering. In an environment where a partly uploaded temporary file could be detected, use a safe approach: a rename on completion, a completion signal, or a separate scheduled run. Direct event integration between EX and a Flow has to be confirmed as supported.

Can customer uploads be moved to an internal server instead of staying on the web server?

Transfer from the upload storage device to the internal server can be set up. Whether the source is deleted or moved automatically has to be checked separately, and the safer procedure is not to delete the source until receipt has been verified.

Can it handle many uploaded files, or very large ones?

INNORIX EX is used for web upload and download, and the device-to-device transfer that follows runs in Studio. The file sizes actually supported, the number of concurrent uploads, the web server storage capacity and the network performance all have to be confirmed per product configuration and environment.

Can uploaded files go to different internal servers by type, such as PDF and CSV?

Yes. Build a Flow for each with conditions on extension, filename and the like, and files move from the upload folder to the internal server that suits their purpose. Test to make sure the conditions do not overlap.

Can web upload success and internal delivery success be confirmed separately?

Yes, and they should be: the completion status of the upload step and the result of the follow-on transfer in Studio Runs are two different things. A successful web upload does not mean the internal server has received the file. If you need one combined intake status, that calls for a separate implementation linking the two results.

Do external users need direct access to the internal server?

In a typical setup, external users work only with the web upload screen they are allowed, and transfer between internal servers runs through registered devices and configured permissions. The actual network paths, firewalls, storage locations and security policy have to be designed for the environment you deploy into.