The internal SLNet call as mentioned from Michiel would be the only way currently. With its own dangers of use as also mentioned.

I would generally recommend using a driver and element to manage DCF on the system. An element has access to better logging, options for caching data and more options to visualize the status of the system. A script is really just for short pieces of volatile & short-lived code.

If inter-device DCF has to be provisioned, this can be easily done using an existing driver: the Skyline Generic Provisioning driver version range 1.0.0.X. It reads in an excel file with all external connections you want to have on the system and takes care of everything for you.

There is also a DCFHelper namespace available in our protocol examples on DCF. In case you want to make/adjust your own custom protocol to manage DCF. It provides much benefit, such as keeping track of what connections the element has ownership of. This allows it to automatically clean up connections and acts as a security to avoid accidentally deleting connections the element itself has no ownership of.

There have been plans to add the DCFHelper code to the class library for a while now, it might be possible to then also release a 'lite' version for automationscript usage. It would lose some of the previously mentioned benefits though.

If adding the DcfHelper code to class library for Protocol and Automation is a popular request feel free to add a record to the Feature Suggestions on DoJo and we can see how much it is requested so we can prioritize.