Import deepsee(.dfi) files via IPM

Question

Question

#InterSystems Package Manager (IPM) #XML #InterSystems IRIS BI (DeepSee) #InterSystems IRIS for Health

Hello Community,

What is the correct way to import and compile .dfi files when using zpm load? Do .dfi files need to be defined in module.xml?

I have code that imports the .dfi file successfully; however, when I run
zpm "load /home/irisowner/dev/ -v"

I get the message: Unknown file type. Skipping file: .pivot.DFI

    zpm "install isc-dev"
    do ##class(dev.code).workdir(dir)
    do ##class(dev.code).import("*.DFI")

Thank you!

Product version: IRIS 2025.1

$ZV: IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2025.1 (Build 223U) Tue Mar 11 2025 18:23:31 EDT

Discussion (7)5

Log in or sign up to continue

score 0 · Answer 1 · 2025-12-16T03:35:18-05:00

No idea about zpm.
Just a guess: if not listed or in a PKG it won't be touched
BUT this loads and compiles it

set tSC=$system.OBJ.Import(fileref,"ck")

score 0 · Answer 2 · 2025-12-16T08:34:15-05:00

I take the approach of adding my .DFI items to a class that extends %DeepSee.UserLibrary.Container following

Creating a Business Intelligence Container Class

as this allows me to treat like any other class.

This means I can

commit to the source control repository just like any other class
deploy like any other class
include the Container class in my module definition to be delivered via ZPM/IPM

This capability has been around since 2018 +/-.

score 0 · Answer 3 · 2025-12-16T15:12:36-05:00

Hi Ashok!

Yes, you can use IPM to support DFI files.

"Lazy", aka "dirty" way - introduce the following resource:

<Resource Name="*.DFI" />

like here, which will package everything you have in a src/dfi folder. Convenient but not optimal and can introduce problems while working with more than one IRIS BI packages.

in this case resource will import all the 100+ DFIs (pivots, dashboards) into IRIS (via load command) and package/publish then:

Don't ask me, why DFI is an XML in fact.

score 0 · Answer 4 · 2025-12-16T15:17:17-05:00

You may ask: how to export the file?

There is a special "helper" package "isc dev", once installed via:

zpm "install isc-dev"

and set up then as:

do ##class(dev.code).workdir("/home/irisowner/dev/src")

it will allow at any moment to export all the DFI at once into your dev folder with the command:

d ##class(dev.code).export("*.DFI")

score 0 · Answer 5 · 2025-12-16T15:53:44-05:00

And here is an example of "proper" using DFI resources - OEX module, Github.

There is one dashboard and two pivots here:

Git-source-control "supports" editing in the UI and exporting to files, but it is quite "buggy" - I hope @Timothy Leavitt and Co will introduce 100% support of DFI someday. Today I prefer to use "isc-dev" and export all the DFI from the namespace into the dev folder to commit changes to the individual DFI files.

But still, the question for the iPM/ObjectScript VSCode team is why the Other section (server-side viewer in VSCode ObjectScript) exports DFI in a different format, which cannot be imported later with the system import method, and thus is not being imported by IPM. Maybe @Brett Saviano can comment here:

Also, why is the naming of resources so complex (you need to use "-" as the folder delimiter and follow this in folder structures.

But it works somehow.

score 0 · Answer 6 · 2025-12-16T16:49:21-05:00

@Evgeny Shvarov The Atelier REST API used by VS Code uses the same document representation as $SYSTEM.OBJ.ExportUDL(). It has no trouble saving files that are sent to it in this format. If $SYSTEM.OBJ.Import/ImportDir/Load() can't import that format then I believe that's a bug that should be reported to development.

score 0 · Answer 7 · 2025-12-17T02:36:44-05:00

Hi @Brett Saviano !

I double checked the export format - the format is the same now and is supported both in IPM and VSCode ObjectScript.

The only issue left is file naming: Atelier REST API exports DFI file names with dFI extension as:

Potatos-AnnualPotatos.dashboard.DFI

at the same time IPM can consume DFI resources if they are presented as XML (tested in 0.10.4), e.g.:

Potatos/AnnualPotatos.dashboard.xml

Inviting @Pravin Barton also, maybe there are plans to do something with this in the future.

And it exports files with "-" as a folder delimeter. Imagine if you have 100+pivots and dashboards in folders - in the code repository, they all will be in one folder with 100+ files with "-" as delimiters. Doesn't sound like a convenient approach.

It's like ObjectScript code files will be named as:

/src/package-subpackage-class.cls

and all reside in one folder, instead of being distributed in packages as folders, as it is working now:

src/package/subpackage/class.cls

@Brett Saviano - hope we could fix this too in the future.