I think what've found is a "hack", or side-effect. Because of ZX.PKG resource line IPM imports "everything" from /src/ZX folder, inlcuding dfi files which happen to be there.

But it's OK. I wonder, if there will be no classes in ZX, or if you include another folder ZY which include only DFI documents inside, will IPM import those as well?

Next is editing and control versioning in VS-Code.

DFI changes in VS-Code are not propagating to connected IRIS automatically after saving. @Brett Saviano  - any hints how can this be set up?

In order to make changes in the Dashboard portal to be automatically reflected, one can use git-source-control. After the following lines:

USER> zpm "install git-source-control" 

USER> do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

changes made in Dashboard Portal editor are being exported into VSCode (into a file), but the location is wrong - git-source-control has created cls/ZXFree folder and dashboard.dfi

But I expected src/ZXfree.dashboard.DFI, as there is no Folder in a dashboard, just title="ZXFree"

@Pravin Barton , @Timothy Leavitt  - could you please take a look?

It indeed works! After providing proper (for Mac) Dockerfile and Docker-compose.yml, and adding DSW, here is what I'm getting:

Like the minimalistic setup, but this doesn't work on mac:

 12/19/25-12:27:01:978 (467) 0 [Utility.Event] Initializing Interoperability during system startup
iris-1  | [INFO] ...started InterSystems IRIS instance IRIS
iris-1  | [INFO] Executing command /docker-entrypoint.sh iris-after-start '/ext/ascript.sh'...
iris-1  | [ERROR] /docker-entrypoint.sh: line 196: /ext/ascript.sh: Permission denied
iris-1  | [ERROR] Command "/docker-entrypoint.sh iris-after-start '/ext/ascript.sh'" exited with status 32256
iris-1  | [FATAL] Error executing post-startup command
iris-1  | [INFO] Shutting down InterSystems IRIS instance IRIS...

no way. Could you please share the repo?

I'd say xml as it's been working well with IPM packaging and standard import/export.

But if dfi is working for you it'd be great to hear! I kind of like .dfi more as it's more clear what the file is about. But xml is fine too.

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.
 

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

There is one dashboard and two pivots here:

 <Resource Directory="dfi" FilenameExtension="dfi" Name="Potatos-AnnualPotatos.dashboard.DFI" />
      <Resource Directory="dfi" FilenameExtension="dfi" Name="Potatos-Totals.pivot.DFI" />
      <Resource Directory="dfi" FilenameExtension="dfi" Name="Potatos-Yearly.pivot.DFI" />

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.
 

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")

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.

Neat! Thank you, looks easy and practical! Thank you for sharing!

What a milestone! Thanks, everyone, for these remarkable 10 years together!

Thank you for introducing, @José Pereira ! Will take a look!

Thahks @Timothy Leavitt ! Looks better with an example, of course. Hope you'll have some time for it in the future.

Ideally, if you share the code sample somewhere so devs can reproduce and see what's really going on

Perhaps there are no rows that satisfy the dimension conditions?

Or maybe there are build constraints? (1000 rows?)

Also take a look $CASE - in some cases can be less wordy and more effective.

Thanks @John Murray ! It's a good idea. I'm not sure if the Ideas portal allows such functionality, as it turned out that we are not the first enterprise to consider bug reporting functionality via a private channel of communication, but it makes sense to me.

Public exposure of critical bugs is not the best way to support the community. On the contrary, it could be a serious threat to thousands of working and important services.