Ax2012 Office Addins Restrictions

There are some restrictions that are inherit with using the Office Add-ins.

Document Services

Document Services are based on a query that defines their structure. Only certain query structures are supported. The following are the restrictions on queries that form the basis of document services. Services which violate these rules may be added to the document data sources form by the administrator, but will result in errors when accessed in the add-in. For this reason it is important that developers and administrators test services for use with the add-in prior to adding them to this form.

·         Replacement Keys: The root level of the document service (the parent datasource) must have unique indexes other than Rec-ID. This may be in the form of a non-RecId Primary Index or a Replacement Key.

·         Related Replacement Keys: Each field within the service which is a RecId-based foreign key must relate to a table that has a replacement key specified.

·         Relationship Direction: When parent-child relationships exist in the underlying query associated with the service, only relationships originating on the child element, and pointing to the parent may be used. For example, in the custCustomerService, the custTable parent data sources holds a foreign key to the dirParty child data source. This pattern is not supported in the Excel Add-in.

·         Query and Service consistency: Document services are based on an underlying query which defines the data contract used in the service at the time that the service is generated. The Excel Add-in uses this query definition to perform read operations when refreshing data into the workbook. Because of this, any overrides to the read method, or extension of the schema beyond what is in the underlying query will not be reflected in the service.

·         View Support: Views may be used within document services to provide an easier to use data model for end users. However, the PrepareForXXXExtended methods must be implemented to properly handle information sent to the service within the views. Views may only be used as the “leaf” level node in the underlying query. For instance if there is a query “Parent, child, grandchild”, then only the grandchild node can be a view.