Save to Folder not including definition.pbism and .platform (for TMDL) #1418
-
DescriptionWhen Saving a (Published) Model to Folder (in TMDL-format), it is not saving the definition.pbism or the .platform files. Tabular Editor 3 Version3.18.2 ScreenshotsNo response Steps to ReproduceConnect to any model in your service. Expected behaviorIt should save in a .SemanticModel-folder including the .platform file, definition.pbism and .definition-folder. Crash ReportNo response Windows Version11 |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments
-
Thanks for reaching out. It's a bit unclear to me what you're trying to achieve. Under normal circumstances, it shouldn't be necessary to modify the .pbism or .platform files (or any of the other non-TMDL metadata files) when making changes to a model. Based on your repro steps, it sounds like you're trying to perform a full "export" of your Power BI / Fabric workspace (or at least of a particular semantic model within the workspace). That's not what Tabular Editor is designed for. There are better ways to do that, such as by cloning the git repo locally, or by using the REST API as you suggest. Using the REST API is not an option for us, as that requires separate authentication, and users who have access to the model metadata through the XMLA endpoint, might not have REST API access (or REST API access may be completely disabled at an organization level). |
Beta Was this translation helpful? Give feedback.
-
Thanks for your quick response Daniel. I'll try to elaborate a bit on what I'm trying to achieve. In my scenario I want to be able to create a Model using Tabular Editor, and then publish it using Git, rather than publishing it directly to a workspace. That would entail saving the model to folder (my local branch repository) and then commit to branch (and alternatively sync branch to connected workspace, or merge to main). The point I guess I'm trying to make is that if you start to create a Model in Tabular Editor it would save a suboptimal representation of the Model according to the TMDL specifications I really appreciate your thoughts on this, I might be way off in my thinking here... |
Beta Was this translation helpful? Give feedback.
-
I see, thanks for clarifying. Our official recommendation, if you want to deploy the model to the Fabric workspace initially through Git, rather than through the XMLA endpoint, is to create a dummy model in PBI Desktop, and save that locally as a PBIP. This will then create the model metadata files including all the supporting files (see step 3, option 3 in this blog post), which you can then commit/push. Upon updating the Fabric workspace based on the git content, the new model will be picked up and created in the workspace. That being said, you can actually create the supporting files yourself. It's not documented anywhere, though, so it's probably not a technique supported by Microsoft. For a model that uses the TMDL format, you only need the following:
{
"$schema": "https://developer.microsoft.com/json-schemas/fabric/gitIntegration/platformProperties/2.0.0/schema.json",
"metadata": {
"type": "SemanticModel",
"displayName": "<ModelName>"
},
"config": {
"version": "2.0",
"logicalId": "<Guid>"
}
}
|
Beta Was this translation helpful? Give feedback.
-
I will move this thread to our discussion section, as it is not an issue with Tabular Editor, but contains information that could be relevant to others. |
Beta Was this translation helpful? Give feedback.
I see, thanks for clarifying.
Our official recommendation, if you want to deploy the model to the Fabric workspace initially through Git, rather than through the XMLA endpoint, is to create a dummy model in PBI Desktop, and save that locally as a PBIP. This will then create the model metadata files including all the supporting files (see step 3, option 3 in this blog post), which you can then commit/push. Upon updating the Fabric workspace based on the git content, the new model will be picked up and created in the workspace.
That being said, you can actually create the supporting files yourself. It's not documented anywhere, though, so it's probably not a technique supported by Microsoft…