Unlocking Uniface: A Practical Guide to the $ude("export") Function 🚀

Disclaimer: This post was drafted with the assistance of an AI to help structure and simplify the official documentation for a broader audience.

If you're working with Uniface, you know it's a powerful low-code platform for building enterprise applications. But how do you manage your development objects—like components, entities, and libraries—in an automated way? This is where the $ude("export") function comes in, and it's a game-changer for backups, version control, and CI/CD pipelines. 🔧

Let's dive into how you can use this function to export your development objects from the Uniface Repository into clean XML files.

What is $ude("export")?

In simple terms, $ude("export") is a built-in Uniface ProcScript function that lets you programmatically export the definitions of your development objects. Instead of manually exporting objects through the IDE, you can write a script to do it for you. This is incredibly useful for automating repetitive tasks.

The Basic Syntax

The function looks a bit intimidating at first, but it's quite logical. Here is its basic structure:

$ude("export", ObjectType, ObjectProfile, FileName, {OptionList})

• ObjectType: A string that tells Uniface what kind of object you want to export. Examples include "component", "entity", or "proc" (for global ProcScripts).
• ObjectProfile: A string that specifies which objects to export. You can use wildcards (*) here. For example, "CUST*" would export all objects whose names start with "CUST".
• FileName: The path and name of the output file. You can export directly to an XML file (e.g., "D:/export/my_components.xml") or even into a zip archive (e.g., "xml:my_archive.zip:my_components.xml").
• OptionList: An optional list of key-value pairs to provide more specific instructions, like specifying a library or model.

Practical Examples 💡

Theory is great, but let's see it in action. Here are a few common scenarios.

1. Exporting a Few Components

Imagine you want to export all components that start with "MY_" into a zip archive. The code would look like this:

vResult = $ude("export", "component", "MY_*", "xml:my_backup.zip:my_components.xml")

This command creates a zip file named my_backup.zip and places an XML file called my_components.xml inside it, containing the definitions of all matching components.

2. Exporting a Specific Library

Libraries in Uniface are typed, meaning a library named "UTILS" could exist for messages, global procs, etc. To export all objects from a ProcScript library named "MY_PROCS", you would do this:

vResult = $ude("export", "proc", "*", "my_procs_lib.xml", "library=MY_PROCS")

The "library=MY_PROCS" option is key here. It tells Uniface to only look inside that specific library.

3. Exporting a Full Project with Dependencies

This is a powerful one. You can export a project and all the objects it references (components, entities, etc.). This is perfect for migrating a complete feature or application module.

To export a project named "PROJECT1" and all its referenced objects, you use the FullProject option:

vResult = $ude("export", "project", "PROJECT1", "full_project_export.xml", "FullProject=True")

If that project also contains references to other projects, you can export them recursively using RecursiveProject=True.

Common Problems and Pitfalls ⚠️

Using $ude("export") can sometimes lead to head-scratching moments. Here are a couple of typical issues to watch out for:

Problem 1: The ide.uar\ Requirement

The $ude functions are part of the Uniface IDE's toolset. If you try to run a script with $ude("export") from a standard runtime environment, it will fail.

✅ Solution: You must either run your component using ide.exe or ensure your application's resource file (.uar) includes the IDE resources. You can do this by adding usys:ide.uar to your application's resource list. This is a crucial configuration step!

Problem 2: Inconsistent Export Order

Have you ever noticed that exporting the same objects on different machines results in XML files that look different in a version control diff? This is often due to the database collation settings of the Repository database (e.g., Oracle vs. SQL Server).

✅ Solution: To ensure consistent exports across a development team, make sure everyone is using the same (or compatible) database collation for their Uniface Repository. This will standardize the sort order and make your Git diffs clean and meaningful.

Problem 3: Misinterpreting Return Values

The function returns a number. It's tempting to think this is the number of successfully exported objects, but it's actually the number of records Uniface attempted to process. An error could have occurred on any of them.

✅ Solution: Always check the special function $procReturnContext after an export. It's a list that contains detailed results, including the number of input records, output records, and any errors encountered. This is essential for building robust, reliable automation scripts.

Conclusion

The $ude("export") function is an indispensable tool for any serious Uniface developer looking to implement modern DevOps practices. By mastering its syntax and being aware of the common pitfalls, you can automate your backups, streamline your version control strategy, and build a solid foundation for continuous integration. Happy scripting!