Inside Dynamics AX 4.0: The AxInternalBase API

[Blog bot]

Источник: http://feeds.feedburner.com/~r/Insid...lbase-api.html
==============

The goal for creating Ax classes was to have an API available when creating and updating records in Dynamics AX tables. The design goals of the AxInternalBase API were as follows:

• The API must be easy to use.
• The API must handle related fields. The default value should apply when a field is updated. For example, when you update the customer account field on the sales order, the address fields should be populated with default values when you copy the address fields from the customer record to the sales order record.
• The API must handle the sequence of field updating. For example, the invoice account field is a related field, which should revert to the default value when the customer account field is updated.
• Field value defaulting might not always provide the expected end result. Consider an example: If the invoice account field is updated first and related fields' values are defaulted, and then the customer account field is updated and its related fields' values are defaulted, the defaulted value would then overwrite the explicitly provided value in the invoice account field.
• The API must handle fetching numbers or identifiers from number sequences. For example, when you create a sales order, a sales order number must be fetched from a sales order number sequence. The business logic that handles this is implemented in these classes.

New Ax classes must inherit from the base class AxInternalBase. The AxInternalBase class keeps track of which methods have been executed to set a table field to a specific value. You can implement this tracking either externally or internally. Externally, for example, you can call the parmCustAccount method on the AxSalesTable class with a specific value. Internally, you can call the parmInvoiceAccount method on the AxSalesTable, because it is a related field that should revert to the default value when the parmCustAccount method is executed. By monitoring the methods that have been executed, the AxInternalBase class ensures that a value set externally is not overwritten.
The class declaration on the AxBC class must declare a record variable of the table type that the AxBC class relates to. The AxSalesTable class declaration therefore has the following declaration.

On an Ax class, you should create an instance method for each field on the related table. The method name must be the same as the field name, prefixed with the word parm, and it must use the following template.


If the instance method is executed without a parameter, the value of the field is returned. If the method is executed with a parameter, the setField method is executed with the field ID of the table field as well as the passed parameter.

The setField instance method on the AxInternalBase class determines whether the field has already been set to a specific value, and it assigns the value if not already set. At the same time, a list of fields with assigned values is updated. The setField method uses the logic shown in below image.

The setField method logical flow.

You can see an actual implementation of the setField method in the following declaration of the parmCustAccount method on the AxSalesTable class.

When you must solve intra-table field relations in which a table field will default to a specific value when the value of another table field changes, you must create an instance method for both fields. The method name must be the same as the field name, including a set prefix, and it must apply the following template. The bold text is subject to modification of current table and field names.
Because the method may be executed several times, the isMethodExecuted method determines whether the method has already been executed and whether the field has already been assigned a value. The isMethodExecuted method uses the logic shown in below image.

The isMethodExecuted method logical flow

Dependencies on other fields must be programmed like this.
First, you should execute the set method of the field for which the current field has dependencies to get a value assigned to this field if any of its dependencies have changed. Then you should determine whether the dependent field has been assigned a new value. If it has, assign a new value to the current field. You can see an implementation in the following declaration of the setPaymMode method on the AxSalesTable class.


To set and get the current record, the instance of the currentRecord method in AxSalesTable must be overridden. The override must apply the following template.

The super call in currentRecord executes the currentRecord instance method on the AxInternalBase class. The currentRecord instance method uses the logic shown in below image.

The currentRecord method logical flow

You can see an implementation in the following declaration of the currentRecord method on the AxSalesTable class.



To update fields on an existing record, the record must be passed to an Ax object via a table record instance method. The method name must be the same as the table name, and it must apply the following template.
The setCurrentRecordFromExternal instance method executes the currentRecord methods and clears all internal variables to prepare the object for changes to the new record.

To ensure that all defaulting methods are called before inserting or updating a record, you must override the setTableFields method on the AxInternalBase class. The method should include a call to all defaulting methods. You can see part of the implementation in the following declaration of the setTableFields method on the AxSalesTable class.





http://insidedynamicsax.blogspot.com/
</img> </img> </img> </img> </img>


Источник: http://feeds.feedburner.com/~r/Insid...lbase-api.html

[kashperuk]

Я правильно понимаю, что все это вырезки из книги?

[gl00mie]

Цитата:

Сообщение от kashperuk

Я правильно понимаю, что все это вырезки из книги?

Точно! А я-то еще думаю, что это все напоминает... и эти странные скриншоты исходного кода... и название блога