Apply the same file transfer policy to hundreds of devices
As sites and servers multiply, setting the transfer path, the run time and the file conditions again on every device becomes unmanageable. Register the devices in INNORIX Studio and build Datasets and Flows, and you have an operating structure that applies common transfer rules to many target devices. Reuse a shared configuration instead of recreating the same job per device, and read each device result in Runs.
Cómo se construye
- Connect the devices the common policy will cover.
Register the systems that take part in the transfer — head office and site servers, operational devices — in INNORIX and confirm their connection state and the paths you can reach. If hundreds have to be registered at once, review whether a supported Bulk provisioning approach can automate the Agent installation and the device registration.
- Decide the transfer rules to apply in common.
Settle the source and target paths, the file selection conditions, the run interval, the overwrite or filename handling and the recovery behaviour on failure against what the work requires. Note separately the paths, permissions and time zones that have to differ per device.
- Build the Dataset and the Flow in Studio.
Build a 1:N Flow that distributes from one source to many target devices, or a multi-stage Flow that fits the work. Where you manage several devices and paths with a Dataset, check how far selection and expansion are supported in the product. If there is no feature that inherits a shared setting to every device automatically, do not describe it as ‘policy inheritance’.
- Verify on a few devices first, then widen the scope.
On two or three test devices, confirm the file selection conditions, the target paths, the permissions, the resend behaviour and the results. Then add target devices in the way the product supports. Before applying it to every device in production, review the network load and the transfer time window.
- Read the per-device results in Runs and keep the configuration current.
Review the finished, in-progress and failed states across the targets and check whether you can recover only the ones that failed. When a device is added or an existing one drops out, change the target configuration and re-verify that the same transfer rules apply to the changed scope.
Dónde se usa
- Distributing shared material to branches nationwide
Business documents or reference files approved at head office go out to tens or hundreds of branch servers under the same file selection rules and run schedule.
- Updating data at stores and logistics hubs
Price lists, product master data and working files are distributed to store operations servers and logistics hubs together, at a set time.
- Regular collection from distributed servers
Logs and result files from many servers are gathered into a central server under a common filename rule and collection schedule. 1:N distribution and N:1 collection are built as separate Flows, each for its own purpose.
- Distributing configuration files to regional servers
Configuration files the operation needs go out to many servers and completion is confirmed per target. Applying the application settings or restarting the service stays a separate operational procedure.
- Extending transfer work when a new branch opens
Connect the new branch server and add it as a target to the existing transfer configuration, reusing the operating rules. Whether it joins automatically on being added is a matter of what is implemented.
- Running overseas sites in different time zones
Keep the common transfer rules while running the distribution schedule around the run times and network constraints of each region. Rather than forcing one clock on every region, adjust to what the work requires.
- Verifying every result after a policy change
When the target paths or the file selection rules change, verify within the test scope first, then widen to production, and check the run result for each target in Runs.
Guías de uso
Preguntas frecuentes
Can the same file transfer job be applied to hundreds of servers at once?
In INNORIX Studio you can build a Flow that covers many target devices and run a common transfer job from it. That said, a central policy inheritance feature where one configuration change propagates automatically to every existing Flow and device is a separate thing. Depending on what is actually supported, you operate by reusing the shared configuration or by amending the targets.
Does every device need its own transfer job?
Not necessarily. Where files go from the same source to many targets, a 1:N Flow can be used, and a Dataset that manages several devices and paths is worth considering. Devices that need a different source path or different run conditions may need their own configuration.
Can it scale to 100, 500 or 1,000 devices?
The scale you can actually run is affected by how the devices are connected, the licence and plan, the server and network capacity, the number of concurrent runs, and the size and number of the files. Large environments should be verified in advance against a representative workload, and device count should not be treated as the same thing as concurrent transfer count.
Does an existing transfer policy apply automatically to a newly connected device?
Check whether the new device can be included in the targets of an existing Dataset or Flow so the same transfer configuration applies. Behaviour where the policy is inherited or distribution starts the moment a device is registered cannot be guaranteed unless it has been confirmed as implemented.
Can a common transfer run even if each branch has a different storage path?
What is possible depends on how far Datasets and Flows support per-device path assignment. Even with the same file selection conditions, where the target paths differ you have to confirm the real storage path and the access permissions on each device.
If some devices are offline, does that stop the transfers to the rest?
What matters is running failed targets and healthy targets as separate concerns. Retry, resumption after a wait and recovery of the failed targets only have to be checked against the configuration and the support range of the actual Flow and transfer engine. When an offline device comes back depends on the network environment.
Can we confirm that the file distributed to many devices is identical everywhere?
You can verify completion from the per-target Run result and whatever integrity information is provided. A successful transfer and a successful application of the file by the target application are different states, so where the work requires it, put a separate follow-up verification in place.
Are bulk device registration and transfer policy management the same feature?
No. Bulk provisioning is the process of connecting and registering devices in bulk, while Datasets and Flows are the process of defining which files go where, and when, between the connected devices. Do not assume that automating registration automatically configures the transfer jobs or the access permissions.