To prepare an Instrument to be able to upload data to Mediaflux, there are two components: 1) provisioning  resources in Mediaflux and then 2) prepare the lnstrument Acquisition Computer Environment, which includes installing the Data Mover.

Provisioning

For each instrument, the RCS Data Solutions team (DST) will provision the following two items with assistance from operational platform staff (PS) who must supply some of the information 

1. A Mediaflux Instrument Project 
   • Name (PS & DST)
   • Who (instrument operational staff only) has access (PS)
   • You can apply for a Mediaflux Project via this Service Now form. After it is created, you will be advised the ID of that project.
2. A persistent Upload Shareable for the Instrument that will be used to configure the Data Mover tool installed on the acquisition computer.  DST will create this.  However, to do so, DST requires some information (the blue strings below are the internal representation of this information in the shareable, useful for DST).  The process of gathering this information will be initiated by DST. What follows is reference material to assist in that process.
   • The above Mediaflux Instrument Project ID (DST)
   • facility: details about the Instrument Platform (Facility)
     • name (PS): facility name - this will appear in the email notifications sent to platform staff and end users. It will be stored as in the value of shareable property: facility.name 
     • notification
       • to (PS): email addresses of the platform staff (ideally an email distribution list). It is stored in the value of shareable property: facility.notification.to. These email addresses will receive notifications during the data delivery process:
         • when data is uploaded
         • when the end user downloaded the data
         • when the end user consumed(copied) the data via User Interaction Web UI.
   • namespace (DST & PS): the parent asset namespace for the uploaded data.  Generally, DST recommend that this  be the top-level namespace of the Instrument Project, but if desired, it can also be further down that structure.  For example, it might be desired to hold data from multiple instruments within one Instrument Project.
   • upload-name-suffix (PS): this string will be appended (after the data and time of the oldest uploaded file) to the top-level transactional upload asset namespace when data are uploaded to the Instrument Project
   • valid-to (PS): the expiry date of the upload shareable.  DST recommends to not set an expiry date, in general.
   • completion: 
     • manifest (PS & DST): Whether or not to generate manifest asset (stores queryable information about the upload) in the top-level uploaded namespace. DST recommends this be set to true.
     • notify (PS): send a notification to the platform staff (see facility.notification.to) when an upload to the Instrument Project is completed. DST recommend this be set to true.
     • share: options for generating the Download Shareable and User Interaction GUI:
       • duration (PS): how many days before the generated Download Shareable and User Interaction GUI will expire.  DST recommend something of the order of 60 days.
       • download: options for generating the Download Shareable (emailed to a User who can download the data to their own local storage)
         • password (PS): an (optional) download password.  When the user downloads the data from the Instrument Project with the Download Shareable, they will be required to enter this STATIC password. This adds a (weak) layer of extra security.  It would be up to Platform Staff to communicate  it to their users. 
         • notify (PS): send a notification to platform staff (see facility.notification.to) when the data are downloaded by a user via the Download Shareable.  
       • interaction: options for generating the User Interaction GUI (that allows a Mediaflux User to copy the data to their own Mediaflux Project). Will only be generated for Mediaflux Users (looked up by their email address) with a writable Mediaflux Project.
         • ifexists (PS): what to do when the destination namespace already exists in the destination project. Allowed values are as below. DST recommends ignore
           • ignore (skips copying the data)
           • rename (renames the asset namespace at the destination)
         • notify (PS): when the User Interaction (copying data) is completed, a notification can be sent to one of
           • facility (notification sent only to facility.notification.to)
           • user (notification sent only to the user doing the copy)
           • all (notification sent to both facility and user)
           • none (no notification)

Preparing the Instrument Acquisition Computer Environment

Once the recipient Mediaflux Instrument Project and persistent Upload Shareable matched to that project have been provisioned by DST, we can now turn to what is required at the Instrument Acquisition Computer.  There are two things to do: 1) create a configuration file with the Upload Shareable and 2) deploy the Data Mover tool.

1. The RCS Data Solutions team will communicate the details of how to prepare the configuration file at the time of provisioning the Upload Shareable  (see above)
2. Installation of the Data Mover is described in this page.