Inside Dynamics AX 4.0: RunBase Framework Extension Part I

[Blog bot]

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

Use the RunBase framework throughout Dynamics AX whenever you must execute a business transaction job. Extending the RunBase framework allows you to implement business operations that do not have default support in the Dynamics AX application. The RunBase framework supplies many features, including dialog boxes, query windows, validation-before-execution windows, the progress bar, client/server optimization, pack-unpack with versioning, and optional scheduled batch execution at a given date and time.

Inheritance in the RunBase Framework

Classes that use the RunBase framework must inherit from either the RunBase class or the RunBaseBatch class. If the class extends RunBaseBatch, it can be enabled for scheduled execution in batch mode.

In a good inheritance model, each class has a public construction mechanism, unless the class is abstract. If initialization of the class is not required, use a static construct method. Because X++ does not support method name overloading, you should use a static new method if the class must be initialized further upon instantiation. Static new methods have the following characteristics:

• They are public and static.
• Their names are prefixed with new.
• They are named logically or with the arguments that they take. Examples include newInventTrans and newInventMovement.
• They usually take non-default parameters only.
• They always return a valid object of the class type, instantiated and initialized, or throw an error.

Note
A class can have several new methods with different parameter profiles. The NumberSeq class is an example of a class with multiple new methods.
The default constructor (the new method) should be protected to force users of the class to instantiate and initialize it with the static construct or new method. If new has some extra initialization logic that is always executed, you should place it in a separate init method.
To ease the task of writing customizations, the best practice is to add construction functionality for new subclasses (in higher layers) without mixing code with the construct method in the original layer.
The Property Method Pattern
To allow other business operations to run your new business operation, you might want to run it without presenting the user with any dialog boxes. If you do this, you will need an alternative to dialog box to set the values of the necessary member variables of your business operation class.
In Dynamics AX classes, member variables are always protected. In other words, they cannot be accessed outside of the class; they can be accessed only from within objects of the class itself or its subclasses. To access member variables from outside of the class, you must write accessor methods. The accessor methods can get, set, or both get and set member variable values.
A Dynamics AX best practice is to not use separate get and set accessor methods. The accessor methods are combined into a single accessor method, handling both get and set, in a pattern called the property method pattern. Accessor methods should have the same name as the member variable that they access, prefixed with parm.
The following is an example of what a method implementing the property method pattern could look like.
If you want the method to work only as a get method, change it to something such as this.
When member variables contain huge amounts of data (such as large containers or memo fields), the technique in the following example is recommended. This technique determines whether the parameter is changed. The disadvantage of using this technique in all cases is the overhead of an additional method call.
Tip
From the X++ editor window, you can access a template script to help you create parm methods. Right-click the editor window, point to Scripts, point to Template, point to Method, and then click Parm. A dialog box appears in which you must enter the variable type and name of the member variable that you want the parm method to give access to. You can also access the script by pressing Shift+F10 in the editor window and then selecting Scripts.
The Pack-Unpack Pattern
When you want to save the state of an object with the option to reinstantiate the same object later, you must use the pack-unpack pattern. The RunBase framework requires that you implement this pattern to switch the class between client and server (for client/server optimization) and to present the user with a dialog box that states the choices made at the last execution of the class.
The pattern consists of a pack method and an unpack method. These methods are used by the SysLastValue framework, which stores and retrieves user settings or usage data values that persist between processes.
Note
A reinstantiated object is not the same object as the saved object. It is a copy of the object with the same values as the packed and unpacked member variables.
The pack and unpack Methods
The pack method must be able to read the state of the object and return it in a container. Reading the state of the object involves reading the values of the variables needed to hydrate and dehydrate the object. Variables used at execution time that are declared as member variables do not have to be included in the pack method. The first entry in the container must be a version number that identifies the version of the saved structure. The following is an example of the pack method.
The macros must be defined in the class declaration. CurrentList is a macro defined in the ClassDeclaration holding a list of the member variables to pack. If the variables in the CurrentList macro are changed, the version number should also be changed to allow safe and versioned unpacking. The unpack method can support unpacking previous versions of the class, as shown in the following example.


If any member variable is not packable, the class cannot be packed and reinstantiated to the same state. If any of the members are other classes, records, cursors, or temporary tables, they must also be made packable. Other classes that do not extend RunBase may implement the pack and unpack methods by implementing the SysPackable interface.
When the object is reinstantiated, it must be possible to call the unpack method, which reads the saved state and reapplies the values of the member variables. The unpack method can reapply the correct set of member variables according to the saved version number, as shown in this example.

The unpack method returns a Boolean value that indicates whether the initialization was a success.

</img> </img> </img> </img> </img>


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