Windows metadata information service

Metadata

MBAE deprecation warning

Starting in Windows 10, version 1803, the MBAE app experience is replaced by an MO UWP app. For more information about MO UWP apps, see UWP mobile broadband apps.

The Metadata element specifies the namespaces of the XML schemas that are referenced in the service metadata package.

Usage

Attributes

Text value

The Uniform Resource Identifier (URI) of the namespace of a service metadata XML schema. The XML schema must be one of the schemas referenced within the services metadata package.

Child elements

There are no child elements.

Parent elements

Remarks

In the PackageInfo element, a minimum of two instances of the Metadata element must be specified. Each instance must specify the namespace of one of the following required XML schemas that are used to create a service metadata package:

The easiest approach is to copy the following example above into your Packageinfo.xml file. If any of the folders specified above are not included in the service metadata package, make sure to remove the Metadata element from the PackageStructure element.

The SoftwareInformation folder and service metadata packages are not supported on devices running Windows 7.

Each folder name can be changed to an arbitrary name as long as the name is set in this metadata element. The following example shows how to use “WindowsInfo” as a folder name:

Источник

Metadata Service

Applies To: Microsoft Dynamics AX 2012 R2, Microsoft Dynamics AX 2012 Feature Pack, Microsoft Dynamics AX 2012

The metadata service returns information about AOT objects in Microsoft Dynamics AX such as tables, services, extended data types (EDTs), enums, and so on. The metadata service is:

by default, hosted by the Application Object Server (AOS)

a Windows Communication Foundation (WCF) service that adheres to WCF protocols and standards

How the Metadata Service Works

The metadata service has two types of service operations:

Service operations that return names or keys – these service operations return the names or keys for all queries, tables, menus, and so on. The names are returned in a string array. The name of the metadata service operation specifies the names that are returned. For example, the GetQueryNames method returns a string array of names for all the queries in the installation.

Service operations that return metadata – these service operations take a string array of names, an integer array of IDs, or an array of key objects (such as MenuItemKeys[ ]) and return the metadata for those objects. Each of these service operations returns an array of metadata objects.

For example, the signature of the service operation to retrieve query metadata is: QueryMetadata[] GetQueryMetadataByName(string[] queryNames). The QueryMetadata objects that are returned in the QueryMetadata[] array derive from the QueryMetadata class.

To use the metadata service, you call the service operation to retrieve the object names. Then, you call the metadata service operation and pass in the name or names to retrieve the metadata for those objects as shown in the following code:

For more information about calling the metadata service, see Walkthrough: Calling the Metadata Service.

The following table lists the metadata service operations that return object names or keys.

Returns the names for all queries defined in the AOT.

Returns the names for all tables defined in the AOT.

Returns the names for all menus defined in the AOT.

Returns the keys for all menu items.

Returns the fully-qualified, unique XML names for all published services in Microsoft Dynamics AX. For example, https://schemas.microsoft.com/dynamics/2008/01/services/SalesOrderService.

string[] GetService GroupNames()

Returns all the names for service groups found in the Service Groups node in the AOT.

Returns the names for all EDTs defined in the AOT.

Returns the names for all enums defined in the AOT.

Returns the names for all labels defined in the label file. The labels are returned in the @SYSnnnn format.

Returns the names for all info parts.

Returns the names for all web menus.

Returns the keys for all web menu items.

Returns the names for all list pages.

Returns the names for all cues.

Returns the names for all cue groups.

Returns the names for all form parts.

Returns the names for all web controls.

Returns the names for all web page definition nodes.

The following table lists the metadata service operations that return object metadata.

QueryMetadata[] GetQueryMetadataByName(string[] queryNames)

Takes a string array of query names and returns the metadata for the queries with the specified names.

TableMetadata[] GetTableMetadataByName(string[] tableNames)

Takes a string array of table names and returns the metadata for tables with the specified names.

TableMetadata[] GetTableMetadataByID(int[] tableIds)

Takes an integer array of table IDs and returns the metadata for all tables with the specified IDs.

TableMetadata[] GetTableMetadataByTypeDiscriminatorValue(long[] typeDiscriminatorValues)

Takes an array of type discriminator values and returns metadata for all tables that have that discriminator value.

MenuMetadata[] GetMenuMetadataByName(string[] menuNames)

Takes a string array of menu names and returns the metadata for all menus with the specified names.

MenuItemMetadata[] GetMenuItemMetadata(MenuItemKey[] menuItemKey)

Takes an array of menu item keys and returns the metadata for the specified menu items. Menu item keys are retrieved by calling the GetMenuItemKeys service operation.

ServiceMetadata[] GetServiceMetadataByName(string[] serviceNames)

Takes a string array of service names and returns the metadata for all services that have the specified names.

ServiceGroupMetadata[] GetServiceGroupMetadataByName(string[] serviceGroupNames)

Takes a string array of service group names and returns the metadata for all service groups that have the specified names.

ExtendedDataTypeMetadata[] GetExtendedDataTypeMetadataByID(int[] edtIds)

Takes an integer array of extended data type IDs and returns the metadata for all extended data types with the specified IDs.

ExtendedDataTypeMetadata[] GetExtendedDataTypeMetadataByName(string[] edtNames) ()

Takes a string array of extended data type names and returns the metadata for all EDTs with the specified names.

EnumMetadata[] GetEnumMetadataByID(int[] enumIDs)

Takes a string array of enum IDs and returns the metadata for all the enums with the specified names.

EnumMetadata[] GetEnumMetadataByName(string[] enumNames)

Takes a string array of enum names and returns the metadata for all enums with the specified names.

LabelMetadata[] GetLabelMetadataById(string[] labelIds)

Takes a string array of label IDs and returns the metadata for the specified labels. The label IDs are in the format @SYSnnnn and the metadata is returned in the installation default language.

LabelMetadata[] GetLabelMetadataForLanguageById(string languageId, string[] labelIDs)

Takes a string variable that contains the language ID and a string array of label IDs and returns the metadata for the specified labels in the specified language. The label IDs are in the format @SYSnnnn. The language ID is retrieved by calling the GetLanguages service operation.

WebMenuMetadata[] GetWebMenuMetadataByName(string[] menuNames)

Takes a string array of web menu names and returns the metadata for all web menus with the specified names.

WebMenuItemMetadata[] GetWebMenuItemMetadata(WebMenuItemKey[] webMenuKey)

Takes an array of web menu item keys and returns the metadata for all web menu items with the specified keys. The web menu item keys are retrieved by calling the GetWebMenuItemKeys service operation.

InfoPartMetadata[] GetInfoPartMetadataByName(string[] infoPartNames)

Takes a string array of info part names and returns the metadata for all info part names with the specified names.

DimensionMetadata[] GetDimensionMetadataByID(int[] dimensionIDs)

Takes a string array of dimension IDs and returns the metadata for all the dimensions with the specified names.

DimensionMetadata[] GetDimensionMetadataByName(string[] dimensionNames)

Takes a string array of dimension names and returns the metadata for dimensions with the specified names.

ListPageMetadata[] GetListPageMetadataByName(string[] listPageNames)

Takes a string array of list page names and returns the metadata for list pages with the specified names.

CueMetadata[] GetCueMetadataByName(string[] cueNames)

Takes a string array of cue names and returns the metadata for cues with the specified names.

CueGroupMetadata[] GetCueGroupMetadataByName(string[] cueGroupNames)

Takes a string array of cue group names and returns the metadata for cue groups with the specified names.

FormPartMetadata[] GetFormPartMetadataByName(string[] formPartNames)

Takes a string array of form part names and returns the metadata for form parts with the specified names.

WebControlMetadata[] GetWebControlMetadataByName(string[] webControlNames)

Takes a string array of web control names and returns the metadata for web controls with the specified names.

WebPageDefinitionMetadata[] GetWebPageDefinitionMetadataByName(string[] webPageDefinitionNodeNames)

Takes a string array of web page definition node names and returns the metadata for web page definition nodes with the specified names.

These service operations return an array of metadata objects. The metadata object contains the actual metadata. The type of metadata object returned depends on the service operation. For example, the GetQueryMetadataByName service operation returns an array of QueryMetadata objects. The QueryMetadata object contains the metadata for a single query and this metadata is exposed through the object methods and properties. For example, the QueryMetadata object has properties such as Name, QueryType, DataSources, and AllowCrossCompany.

The metadata classes reside in the Microsoft.Dynamics.AX.Framework.Services.Metadata.Contracts namespace. Some commonly used top-level metadata classes include the following:

Metadata Service Architecture

The metadata service is a WCF service that is contained in the Microsoft.Dynamics.AX.Services.Metadata.Service.dll assembly. This assembly is located in the server Bin directory. Depending on your configuration, the assembly is located in a directory such as C:\Program Files\Microsoft Dynamics AX\ \Server\MicrosoftDynamicsAX\Bin.

The metadata service has the following configuration default values:

It is hosted by the AOS on port 8201 and the URL is net.tcp://servername:8201/DynamicsAx/Services/MetadataService.

The service WSDL URL is http://servername:8101/DynamicsAx/Services/MetadataService

It uses the netTcpBinding binding.

These settings will vary depending on what port number the service port and the WSDL port have been configured to use.

The configuration settings for the metadata service are found in the Ax32Serv.config file which is also located in the server Bin directory.

Metadata Service Security

Only authenticated Microsoft Dynamics AX users can access the metadata service. In order to retrieve data by using the metadata service, you must have a valid username in Microsoft Dynamics AX. The metadata service uses Windows integrated security. Therefore, when a caller invokes the metadata service, the system verifies the credentials under which the calling client is running and verifies that the username is a valid Microsoft Dynamics AX user.

The metadata service is available to all authenticated users. Therefore, all security roles have the same access level to metadata information.

Источник

Service metadata overview

MBAE deprecation warning

Starting in Windows 10, version 1803, the MBAE app experience is replaced by an MO UWP app. For more information about MO UWP apps, see UWP mobile broadband apps.

You can create and submit a service metadata package to create an experience that is deeply integrated with Windows. When Windows detects mobile broadband hardware that matches the operator’s service metadata package, it automatically downloads the service metadata and the specified mobile broadband app.

Service metadata contains the information that describes a service, including the following:

The service provider name

One or more service categories

Mobile broadband-specific information

Mobile broadband app

Mobile broadband profiles

Trusted certificates for provisioning XML

The information in the metadata is used to customize aspects of the WindowsВ 8, WindowsВ 8.1, and WindowsВ 10 user experience and provide integration with a mobile broadband app, previously known as a mobile operator app.

A service metadata package consists of multiple XML documents stored within a .devicemetadata-ms file. Each document specifies various components of the service’s attributes. These XML documents provide Windows Connection Manager with customizations that appear to the user, as well as network configuration information.

For reference information about the XML documents in a service metadata package, see Service metadata package schema reference.

Service metadata contents

The following summary describes some of the most interesting fields that are contained and defined inside a service metadata package:

Hardware IDs
For a GSM network, you can submit a metadata package that describes the IMSI or ICCID ranges against which you want your service metadata package to match. If you are an MVNO, you can specify one or more ranges of IMSIs or SIM ICC IDs that you have leased from an MNO. For a CDMA network, you can submit a package by using Provider ID (SID/NID) or Provider Name. The hardware IDs correspond to the HardwareID element in the service metadata package schema. For more information about how to plan your Hardware Identification (HWID) ranges for MNO and MVNO scenarios, see Delivering experiences for MVNOs

Service number
The unique ID for the mobile broadband service provider. This GUID is also used to identify the operator when using Account Provisioning Metadata. If you update the device metadata package, this GUID must remain the same. The service number corresponds to the ServiceNumber element in the service metadata package schema.

Operator logo A custom logo that appears in Windows Connection Manager next to your network entry. (The logo is hidden when the user is on a roaming network.) The operator logo corresponds to the ServiceIconFile element in the service metadata package schema. For more information about the logo requirements, see Service Icon Requirements.

In Windows 10, version 1709 and later, this field has been replaced by branding through COSA. Fields in COSA for branding are described on Planning your desktop COSA/APN database submission. If you are targeting versions of Windows before Windows 10, version 1709, you will still create a metadata package as described in this section. For more information about COSA, see COSA overview.

Mobile broadband app
A UWP device app that is automatically downloaded and applied to the computer. This app can provide key experiences such as plan purchase, data usage, and help and support, and can highlight value-added services.

MB Purchase Profile
Purchase profile that is used for establishing limited connectivity for purchasing a subscription.

If you are a GSM operator who has only one Purchase APN for all subscribers, you can use the service metadata to provision that to the computer. If you have multiple Purchase APNs, you should use account provisioning metadata to set the appropriate purchase APN. Or, you can do nothing and use the entries that are stored in the APN database to provide APN connectivity information.

MB Internet profile
Every mobile broadband subscription can have one default profile that is used to connect to the home network operator. The Windows Connection Manager uses this profile for auto-connecting to the network.

If you are a GSM operator who has only one Internet APN for all subscribers, you can use the service metadata to provision the computer. If you have multiple Internet APNs, you should use account provisioning metadata to set the appropriate internet APN. Or, you can do nothing and use the entries that are stored in the APN database to provide APN connectivity information.

Certificate data
Certificate information used for provisioning. This includes Certificate Issuer Name and Subject Name. This information is used to ensure that account provisioning operations that are initiated by a website are issued by a trusted operator.

Custom operator name
The mobile broadband device typically provides the operator name, which Windows shows in Windows Connection Manager. You can override this name by specifying a custom name in metadata. This name displays only if the user is on a home network and is not on a roaming network. A displayed roaming network name is based on information that is received from the device. This corresponds to the ServiceProvider element in the service package metadata schema.

In Windows 10, Version 1709 and later, this field has been replaced by branding through COSA. Fields in COSA for branding are described on Planning your desktop COSA/APN database submission. If you are targeting versions of Windows before Windows 10, Version 1709, you will still create a metadata package as described in this section. For more information about COSA, see COSA overview.

Device notification handler
In general, an app must be run by the user at least one time before it can register work items with the System Event broker. However, mobile broadband apps might need to receive important events before the user can run the app. You can specify the DeviceNotificationHandler element in service metadata, which Windows will use to register some critical events. For more information about SMS notifications, see Delivering experiences for MVNOs.

List of privileged apps with access to mobile broadband restricted interfaces
Mobile Broadband APIs and interfaces (including Account Provisioning and SMS) are restricted and available to mobile broadband apps only. A list of privileged apps that have access to these privileged APIs can be specified in the service metadata package in the PrivilegedApplications element. Privileged apps can be debugging or test apps; they are not required to be distributed through the Microsoft Store.

Service Metadata Package Structure

The components of a service metadata package are stored in a compressed cabinet file and must have a file extension of .devicemetadata-ms. Service metadata packages use this file extension because they use the same underlying platform as device metadata packages. Before you create the .devicemetadata-ms file, you must first create a globally unique identifier (GUID) for the metadata package. Then, you must use the following naming convention when you create the .devicemetadata-ms file: .devicemetadata-ms.

NoteВ В Although the usual file extension of a cabinet file is .cab, the file extension for a service metadata package file must be .devicemetadata-ms. This is intended to underscore the fact that end-users must not decompress or modify these packages.

There are two types of service metadata packages: a single locale service metadata package and a multiple locale service metadata package.

Single Locale Service Metadata Package

The localizable resources in the service metadata package are the operator name that appears in Windows Connection Manager and the service icon that appears next to it. If you do not need to localize your name or change your icon based on locale information from the PC, create a single locale service metadata package. Regardless of what locale the user is using on their PC, they will get the operator name and service icon defined in the single locale service metadata package.

A single locale service metadata package must have the following file structure:

Some considerations for a single locale metadata package:

The icon file can have any file name. However, the individual XML documents must be named PackageInfo.xml, ServiceInfo.xml, WindowsInfo.xml, and SoftwareInfo.xml.

The name of the MobileBroadbandInfo.xml file is defined in the ServiceInfo.xml. You should use the names listed in this document for that file.

The .devicemetadata-ms file cannot include “<“ or “>” in the name. The GUID for each metadata package file name must be unique. When you create a new or revised service metadata package, you must create a new GUID, even if the changes are minor.

Windows recognizes service metadata packages with a file extension of .devicemetadata-ms.

Multiple Locale Service Metadata Package Structure

A service metadata package supports multiple locale files in one package. If you support more than one locale for your service, you can put multiple locale files into one service metadata package.

You can use a multiple local service metadata package if you want to show a localized name for your service in Windows Connection Manager network list or to show a different logo in Windows Connection Manager for your network. Windows will display the localized network name and logo based on the system preferred language, which is usually configured during Windows Setup. Even if the current user’s language is different from the system preferred language, the icon and network name always will show up in the system preferred language. If the service metadata package does not include a locale, the language neutral description from the root of the service metadata package is displayed. For most users their language will match the system preferred language.

A multiple locale service metadata package must have the following file structure:

Some considerations for a multiple locale metadata package:

Create a locale name folder in each folder and put the XML file or relevant file in the locale name folder.

You still must have the top-level XML file and relevant files, such as the icon file, at the top level of each folder. This provides a fallback mechanism when the locale is not included in your service metadata package.

Ensure that all required files and the fields within those files are completely filled out inside each locale-specific folder that you create. This is in addition to the content in the top level of each folder. For example, the ServiceNumber element in ServiceInfo.xml must be filled out and duplicated in the top-level folder and in every locale-specific folder that you create. Failing to do this will cause errors.

The SoftwareInformation XML document does not support multiple locales because you cannot specify different SoftwareInfo.xml files per locale.

Service metadata submission and maintenance

For more information about how to submit service metadata packages to the Windows Dev Center Dashboard – Hardware, see Developer guide for creating service metadata.

It is important to keep metadata packages up-to-date in terms of how they are described and which IMSI and ICCID or CDMA Provider Name or SID values they match. This can require an MNO or MVNO to implement a new workflow that is part of SIM or device acquisition to track new orders of SIMs and the MNO or MVNO to which those ICCIDs or IMSIs are being provided.

It is a best practice to avoid making frequent changes to your service metadata by reserving ICCID or IMSI ranges (or CDMA SIM/Provider name) for the MNO and MVNO in advance, so that when new SIMs (or CDMA devices) are procured, they are already accounted for in your service metadata package.

If you need to update your service identifiers that are registered on the Windows Dev Center hardware dashboard, see Service identifier ownership updates.

Metadata updates are silently applied based on internal Windows logic (typically every eight days) when Windows queries WMIS whether it has any updated metadata updates.

The app should be designed to deal with a previous version of the metadata to which it refers, until the latest metadata is applied to the system.

Designing the user experience of a mobile broadband app provides guidelines about how to design the user experience to address common error cases, such as when the device is missing or not recognized.

Источник