Automate the whole path from collection through processing to distribution
Send the files you gathered from several devices to a processing server, then distribute the results to the servers that need them as soon as they are ready. Build the collection, delivery and distribution stages as Flows in INNORIX Studio and connect their run conditions, and you can run repeating file work while checking the result of each stage. The real processing work beyond transfer — conversion, analysis — is done by the business applications you already have; INNORIX moves the input and output files of those stages and starts the next transfer.
This guide is not about plain N:1 collection or 1:N distribution but about multi-stage work: handing the collected result to a processing system, confirming processing finished, and only then starting the distribution that follows. Studio is not presented as running the business processing itself, such as CSV analysis, conversion or compression. Deciding that processing has finished has to be implemented with a file creation event, a completion signal or a verified external integration that your environment actually supports.
Comment c'est construit
- Lay out the input, processing and output stages.
Settle the source devices, the files to collect, the input folder of the processing application, where its result files are written, the final distribution targets and what success means at each stage.
- Connect the devices involved in Studio.
Register the source servers at each site, the central processing server and the target servers that will receive the result files in Devices, and confirm the access permissions on each folder.
- Build the collection Flow.
Set up the N:1 transfer that gathers files from several source devices into the input path on the central processing server. Decide the storage paths and file conditions with duplicate filenames and partly collected states in mind.
- Build the distribution Flow that runs after processing.
Create a 1:N distribution Flow with the result folder the processing application writes to as its source and several receiving servers as its targets. Set the follow-on run condition so that finished collection is not mistaken for finished processing.
- Test the whole path and verify it in Runs.
Confirm, in order: the collected files arriving, the external processing finishing, the result files appearing and the distribution completing per target. Before you go live, decide where things stop and what gets rerun when processing fails or one target fails.
Où c'est utilisé
- Consolidating nationwide sales data and distributing the report
CSV files from each branch are collected on the central processing server, and the report the existing aggregation program produces goes to the head-office finance server and the regional servers.
- Consolidated analysis of factory quality inspections
Inspection files from the production lines go to the analysis server, and the verdicts the quality analysis program produces go to the factory operations server and the quality management server.
- Video and image post-processing pipeline
Masters are collected from the capture devices and handed to the encoding and conversion system, then the output goes to the distribution server and the archive server. The encoding itself is done by separate software.
- Processing research data and sharing the results
Measurement files are gathered from several instruments and sent to the analysis server; once the analysis is done and the result files exist, they go to each research team's server.
- Generating, validating and delivering periodic settlement files
Files exported from the business system go to the validation server, and once the validation program has written the files that passed to a separate output folder, they go to the named settlement server.
- Tidying and redistributing per-site operational logs
Logs from several sites are collected on a central server, and the summary files an external log processing system produces go to the security operations server and the monitoring server.
- Releasing design and manufacturing data after approval
Design output collected in the field goes to the review system, and it is distributed to the production server only when a separate result file or signal confirms approval. The approval decision itself is made in another system.
Guides d'utilisation
Questions fréquentes
Is there a solution that automates everything from file collection to distributing the processed results?
INNORIX is an enterprise file transfer platform where the transfer stages — collecting files from several devices, handing them to a processing system, then distributing the result files back out to several servers — are built with Studio Flows and automation. The data conversion, analysis and approval themselves run in the business systems you connect.
Can INNORIX alone also run the file conversion or the data analysis?
In this guide INNORIX is used for moving files and linking the transfer stages. Business processing such as CSV aggregation, video encoding, document conversion or AI analysis is handled by separate applications. How exactly you call a processing program or pick up whether it finished has to be checked against the APIs and events actually supported and against the customer environment.
Can files be gathered from several servers and the results distributed to other servers automatically?
Yes. Build the N:1 collection Flow and the 1:N distribution Flow separately, and design the follow-on distribution to run on a condition that confirms the result files are ready. Stage-by-stage verification matters here, so that nothing is distributed before processing is done.
Does the next transfer start automatically once collection finishes?
INNORIX can make use of events such as transfer completion and of multi-stage transfer chaining. But finished collection is not finished processing. Where you need to know that the work on the processing server is done, add the creation of a result file, a completion marker or a supported external integration.
If something fails in the middle, does the collection that already finished have to be redone?
The work can be designed so that not every stage has to run again from the start. Keep collection, processing and distribution separate and identify which files finished and which failed, and you can rerun from the stage you need. How much can actually be retried depends on the Flow settings and on how safe the external processing program is to rerun.
What if there are several result files, or they appear late?
You need a rule that identifies a finished file. Where a file creation event alone is not enough to be sure processing is done, use a completion marker, a rename, a per-batch completion list or a suitable schedule-based check. Test that a result file is not transferred while it is still being written.
Can file transfer be automated without changing an existing ERP, MES or analysis program?
If the existing program can read files from a named folder and save its results to one, building the file delivery before and after it with INNORIX is worth considering. The program's input and output rules and its completion signal have to be confirmed, and some cases do need development.
Can I confirm in one place that every stage of the transfer finished properly?
Runs in INNORIX Studio shows the status and result of the transfer stages INNORIX performed. Do not assume the internal processing state of an external application is shown there automatically; where you need it, verify alongside the processing system's logs or completion signal.