Al: Access to Table "Object Metadata" (or provide alternatives)

[julianwissel]

I am working with the November Preview and I need to read from the virtual table "Object Metadata".

This table however is blocked:
ObjectMetadata : Record "Object Metadata";
[AL] The type or method 'Object Metadata' cannot be used for 'Extension' development.

Could you unblock it (at least for read-purposes)?

Thanks and best regards,
Julian

[StanislawStempin]

Hi, what information do you rely on form that table? Can you use the AllObjWithCaption table instead? Or individual metadata tables: Table Metadata, Page Metadata etc.

[julianwissel]

Hi Stan,

I am parsing the object metadata XML to identfy all fields that are available on a page and whether a field is editable or not (based on editable/enabled-property on table and/or page).

I have not thought about page and table metadata. Could that work?

Best regards,
Julian

---

Von: Stanislaw Stempin [e-mail]
Gesendet: Freitag, 10. November 2017 14:32:34
An: Microsoft/AL
Cc: Julian Wissel; Author
Betreff: Re: [Microsoft/AL] Access to Table "Object Metadata" (#912)

Hi, what information do you rely on form that table? Can you use the AllObjWithCaption table instead? Or individual metadata tables: Table Metadata, Page Metadata etc.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/Microsoft/AL/issues/912#issuecomment-343474068, or mute the threadhttps://github.com/notifications/unsubscribe-auth/Af_b9I1X07YBFLDJczAyWcLa-0iHxBORks5s1FBygaJpZM4QZZHw.

[StanislawStempin]

Page Field information doesn't seem to be available in any other system tables. May I ask what is the scenario that you're trying to achieve? The Editable/Enabled properties can be expressions that only get evaluated at runtime. How do you statically decide if the are true/false?

[julianwissel]

We are "solving" the issue that editable/enabled-property allow expressions that only the static value TRUE is understood by us as editable. The general scenario is a search and replace app that only allows searching and replacing on fields that are editable from the page (without any conditional editability).

[FSharpCSharp]

We also have a case where we need access to the table "Object Metadata". Specifically, we need these to read the RequestPage for the existing reports. Unfortunately, we have no other option than to go over the metadata, because the XML returned by the report tells us nothing about the request page structure. We then build the request XML from the metadata and pass it to the report. So far, however, there is no other way. For this we would only need read-only access to the object metadata table.

[dennisfrostlander]

@julianwissel @FSharpCSharp What about objects added through extensions? Do you also need to include those objects in your solutions?
The problem is that metadata for extension objects is not stored in Object Metadata table, but in Nav App Object Metadata table instead.

[julianwissel]

@dennisfrostlander: if possible it would be perfect to access the metadata of the extension objects as well.

[FSharpCSharp]

@dennisfrostlander It would indeed be very good if you had access to both metadata. Would it be possible to offer a virtual table of metadata that connects the two? This means that you could not make any changes to the existing real tables.

[dennisfrostlander]

Yes, I was thinking along the same line. To set the right priority though, I assume that at this point the absence of access to Nav App Object Metadata is not a blocking issue for you (to convert the existing solutions). Am I right?

[julianwissel]

@dennisfrostlander: for me the blocking issue would already be solved if access to the object metadata were available

[FSharpCSharp]

@dennisfrostlander I also think that it would be sufficient for the first if access to the normal object metadata table were possible. Of course, it would be nice to be able to access the extension metadata via a virtual table. In my view, however, this can only happen later.

[FSharpCSharp]

@dennisfrostlander
Any news on this? For the implementation of our previous module we still need access to this table. So far, this issue has only been marked as a "question". Is implementation no longer planned?

[dennisfrostlander]

This table is still under discussion between various stakeholders. Will keep you posted on the decisions.

[MaKnauer]

We need acccess to the Object Metadata as well. We need to know the Lookup Page for tables. for Standard objects and for extensions.

[dennisfrostlander]

@MaKnauer What information do you need to read from the lookup page?

[MaKnauer]

We want to get the lookup page from a table . For example Lookup Page of Table 18 is Page 22. We use this in a generic way to generate page link URLs.

[MaKnauer]

In our workflow granule, we track changes on tables. If some fields have been set, for example the item description on item table, we send an email to a user which contains a direct link to the item card. Therefore we need to know the lookup page from a table.
But we are able to track changes on every table in NAV so we need a generic solution.

[danielrodgers]

@MaKnauer Codeunit 700 may help you

[MaKnauer]

Thanks, for the info. That will help us.

[dennisfrostlander]

@FSharpCSharp Opening the entire Object Metadata table for extension development might not be the most desirable option. The better alternative for us would be to provide the exact API that you need for your scenarios. But for that we need to understand in more details, why you need to extract request page metadata from XML? What type of changes are you making in the XML and what for?

If you already have an idea of the suitable API, we could work towards submitting a pull request to Microsoft C/AL Open Library and then it will be included in the next base app update.

[FSharpCSharp]

@dennisfrostlander
I need access to the XML data from this table because we use our programming NAV reports program controlled and with input parameters automated call. For this to work we have to pass the settings of the RequestPage to the report. This is known to be an XML file that explicitly describes the structure of the parameters and filters. In the NAV, there is no way to access the data that is required when calling a RequestPage. Furthermore, the XML file which contains the parameters does not contain any meta information. So you don't know whether it's a table or a normal variable (captions, options etc. are missing).

In our development department, we now read the data from the metadata in order to build up an XML. We then pass this to the function REPORT.SAVEAS. In this way we can ensure that we always have the current status of the RequestPage.

The problem would not arise if the structure of the RequestPage (variables (incl. options, data type and caption) DataItems (name, table number) were available in a certain amount of detail. Unfortunately, it was not possible for us to get this structure via the functions provided in the standard version.

[dennisfrostlander]

The problem is that the XML format of the report and request page is internal. There is no public schema for it nor is it guaranteed that it will not be changed in the future versions.

I am not exactly sure I understand what you mean by this:

because we use our programming NAV reports program controlled and with input parameters automated call.

As far as I understand, you are programmatically running reports, without user interaction. Is that right? What do you use it for?
Is it for testing the reports in the development department? If so, perhaps you are missing something in request page testability?

Or do you use it for integration with some other system in production environment? If so, could you please give more details on the integration?

[FSharpCSharp]

@dennisfrostlander
Yes, that is correct. We execute reports without user input. We use this to access the report's DataSet so that we can evaluate the data from it in another application. I already know that the structure is only internal and can change at any time.

We only need the following data from the request page:

• Number of fields, the display is irrelevant, for example, whether they are displayed in a normal layout or in a grid.
• Name of the fields, is also mapped 1:1 in the XML request.
• Labels of the fields.
• Data type of the field
• OptionString and OptionCaption to map these fields.
• DataItems that are displayed and the fields that the user sees (RequestFilter fields).

All the rest is irrelevant to us. If we had access to this information, it wouldn't be an issue. For the software tests in NAV there is also the possibility to call up a report completely program-controlled in NAV (TestRequest Page). Would it be possible to put this information into an object model, similar to the test? The only thing missing from the test is the possibility to enumerate the options of the request page. Otherwise, everything else would already be there.

[dennisfrostlander]

Thanks, now that we have a more detailed feature request, could you please open a new issue for that?
So that we don't have it under the generic "Access to Object Metadata" issue.

[FSharpCSharp]

@dennisfrostlander
There is already an open issue on this 546. I don't know what happened to it, but I don't know what has happened so far. The problem is well known. Should I extend the requirement in it now, or are you going to follow up the existing topic?

[dennisfrostlander]

Ok, thanks. Didn't know about 546. Let me collect some feedback on this.

[dennisfrostlander]

To summarize the issues in this thread:

1. Enabled/Editable properties on page controls could be looked up using the _Page Control Field_ virtual table.
2. LookupPageId on tables could be looked up using the _Table Metadata_ virtual table.
3. The report request page, xml request pages and data items could be now supported using the new virtual tables _All Control Fields_ and _Report Data Items_. See https://github.com/Microsoft/cal-open-library/pull/56 for more information. These tables will be available in the upcoming release.

It seems like there are no more outstanding issues here, so removing the _in-progress_ tag. If anything else is required, let's track it via separate issues.