Custom box

hi all,

Don't know about you, but I've been using the Box class quite often. But sometimes I need a dialog with other options than the ones out-of-the-box Ax provides. Some situations just don't get covered by a Yes/No choice. That's where my CustomBox class kicks in: you get the look and feel of the standard Ax box, but with custom buttons.

It comes with only two public method, so it's pretty simple:
- a public static 'construct' method to create the object
- a public instance 'prompt' method to  ... well, to prompt the dialog.

The constructor takes 5 parameters:
- the message/question itself 
- a container holding the button labels: for each element in the container a button will be created using the provided label
- an integer indicating which of the elements of the container should be the default button. This one is optional, the first button is the default ... by default
- the title to be used. This one is optional, by default it states 'Microsoft Dynamics' on top of the dialog
- a boolean to make the dialog modal. This one is also optional but 'true' by default.

The prompt method doesn't take any parameters but does make sure to prompt the dialog and that the number of the button that was pressed is returned.

The example below should make the above more clear:

static void CustomBox_TryOut(Args _args)
{
    CustomBox       box;
    int             retValue;
    ;

    box = CustomBox::construct("Press one of my buttons",
                               ["I will", "I won't", "Not sure"], 
                               2, 
                               "Pick a button");
    info(strFmt("you pressed button %1", box.prompt()));

}

The dialog triggered by the prompt method would look like this:

And the result in the infolog:

Source code of the class and a tryout job bundled in a private project can be downloaded here.

As with the standard Ax Box class, this class is also running on the client. So make sure it's not included in any server side batch or CIL code.

Enjoy!

AxUtil and the application log

hi there,

During the set up some 2012 environments lately, we got warnings like

An error occured in writing to the event log on machine <DBServer>: cannot open log for source 'Microsoft Dynamics AX - AXUtil. You may not have write access.

when we're using the axUtil or perform actions where the axUtil tool is used behind the scenes.

It seems the problem occurs when the account running the AOS instance does not have sufficient privileges on the database server hosting the AX database.

You can go all wild add the AOS service account to the administrators group on the DB server. Or you can handle it more suble by just granting that AOS service account write access to the application log.

Windows comes with a nifty tools (called 'wevtutil') to regulate this. You can read all about it here.
What we did to solve the issue is:
- open an elevated command prompt on the DB server
- run 'wevtutil gl appication > c:\temp\out.txt', which will give you a textfile containing the security settings for the application log
- from that texfile, you copy the (seemingly uncomprehensable, but all part of MS's security descriptor definition language (SDDL)) expression that's after the 'channelAccess: ' keyword. This is the string that actually defines who has (or hasn't) access to the application log
- now you need to make sure the AOS service account is added to that string. I took the easy way and gave all 'authenticated users' the 'file write' permission by adding '(A;;FW;;;AU)'.
- the last step is to send that modification back into the system using the 'sl /ca' option on the wevtutil command: 'wevtutil sl Application /ca:<the modified channelAccess string>'

I got my inspiration on 'The Raven Report' blog, so it's only fair to mention that.

bye

Name based versus Id based

hi guys,

I'm programming some new functionallity that requires setup based on tables, fields, methods and classes. At first my solution used tableIds, fieldIds and classIds on the setup tables to store the required values. But then I figured out there will be a point in time the user will come with the question 'how he can copy the setup from the test to the production environment?'. And then it hit me: there's no guarantee whatsoever that a specific table.field combination in two environments will have the same tableId and fieldId. Same goes for classes: a class does not necesseraly have the same Id in different environments.
Or in other words: I'd had to disappoint the poor guy who putted all the effort in setting up and testing the solution in a pre-production environment.

Hey, but wait a minute! Maybe I don't have to disappoint him ...

What about this ID-issue they'd solved in Ax2012? Is that not helping me then?
Sure it is: each object gets an installation specific ID that will never ever change. That is: if you honour the best practices and don't intentionally ty to mess it up ... . Ok then, but will this solve my data export/import issue? Yes it does: the standard Ax data import/export functions have been improved to handle this. Check the full details on  http://blogs.msdn.com/b/mfp/archive/2011/07/11/the-solution-to-the-element-id-problem.aspx.
So Ax2012 does offer great advantages over previous versions regarding object ID's. And the poor guy testing my solution can export his setup from test to production.

In the end I did decide to rewrite my solution and make it name based over ID based.
Why? Because I figured it could as well be name based: this would make the code more clear to read, understand, debug and export/import would still work fine.
And also because I do have the  impression there's a shift to name based in Ax2012:
- new constructor methods 'newName' on for instance SysDictClass, sysDictTable and sysDictField
- the typical dimension[1, 2, 3] fields are gone and replaced by a new dimension framework and the corresponding bitwise-shifting-methods like fieldId2ext and fieldExt2Id are far less used throughout the application. All this makes name-based usage easier.

So should you code ID based or name based? I'm going for name based with Ax2012.
But I think there's no general rule on which of the two is better.
It's worth taking a minute or two to evaluate your situation (think about export/import, maintainability) before taking the decision.

bye

The model store has been modified

hi folks,

I've been involved in creating build scritps for Ax2012 over the last few months and have encountered (and conquered) a number of ... well, let's cal them 'obstacles'.

One of them is the 'the model store had been modified' dialog that pops up the first time you start an Ax client after the model store was modified. It actually gives you some options (start checklists, compile and sync or just skip the whole affair).
But  sometimes this happens: you don't manage to select any option. I mean: you can click an option, but it does not get selected. In fact: the (modal) dialog (including the OK/cancel/close buttons) does not react at all.

My workaround is to start the Ax client directly in a developer workspace (ax32.exe -development), where you get the same 'modelstore modified' dialog, but it does react when you click it.

Another option is to undo the installmode setting on the modelstore (axutil.exe set /noinstallmode) which prevents the modelstore modified dialog from popping up, and fire the compilation, CIL generation an synchronisation (or any option you whould have chosen) manually.


Don't know why this happens, I just hope I save someone some valuable time with this workaround.


bye!

DAXCONF - Upgrade Tools for Developers & Administrators

Traditionally MS support upgrading to a new version from the two previous versions. So you can go upgrade to Ax2012 from Ax4 and Ax2009.
MS seriously focussed on minimizing the time-frame the Ax live system is unavailable by introducing a wel-considered upgrade procedure. Bear with me while we go through the concept:
- The upgrade process is partly executed on the old (current live) system, partly on the new (future live) system.
- The old system is checked for upgrade readiness: potential upgrade issues are detected. Some of them are show-stoppers and need to be resolved before upgrading can continue, some of them have an advisory goal. Showstoppers could be missing data conversion scripts for custom tables. Activating or adding performance boost scrips could be advisory items in the output list.
- The principle of using attributes in the upgrade classes makes is possible to easily define relations between different upgrade classes. So you can actually decicde exact where to anchor your classes in the existing upgrade order.
- Still in the old system, the application data is prepared for preprocessing. This means the current data is made ready for upgrade, or basically: a number out-of-the box classes handle the differences between Ax4/2009 and Ax2012 and makes sure the 'old' system gets all dressed up to smoothen the data conversion. Think for example of preparing currencies for upgrade, preparing financial dimensions, … or make sure the old datamodel is extended so that converting the data to the new system will be a smooth as possible.
- Preprocessing the actual data on the old system would be the next step. This requires a separate set of tables is created (in the AxDB) to pretty up the live data in order to ease the data copy later on. This is not touching the live data or affecting the availability of the live system.  Shadow tables are added for the actual data-copying to expose all required data for the Ax2012 system.
- An important advantage here is that the workload of the preprocessing can be contolled: preprocessing tasks can be paused during office hours and continue at night for example. Another interesting thing is the concept of delta processing.
- Data needs to be preprocessed at once. You can plan this up front: let's say the weekend before the go-live-date the data is preprocessed. During the actual go-live-weekend, only the data that was touched since the previous preprocessing run is taken into account.
- During all the above actions, the old (current live) system stays online and available for users to work in, a large number of upgrade-task can be executed simultaniously (in parallel)
- Only the last step require a single-user-mode approach (downtime).

So the upgrade model of Ax2012 supports
- parallel execution of (pre)prosessing tasks,
- delta processing of data,
- up-front checks to make sure the source system reaches a full upgrade readiness
- a flexible way of adding in new custom upgrade classes
which all results in a minimum down time.

DAXCONF - Extending the Reach of the application with the new Office Add-ins

I've really seen some cool  things in this session. Here we go:

Copying data from Ax to Excel is not new, but it wouldn't be Ax2012 if it wasn't improved: now only the actual columns you're seeing on the screen are copied. But that's nothing compared to the fact that you can actually create, change and delete Ax data from within Excel. In an Excel workbook, you can 'add data' and pick one of the availabe services (these are webservices). In design mode you can bind the fields from your datasource to the cells in your worksheet.

You can then:
- Add new records (of cource all mandatory fields need to be in place)
- Even create new linked header/line records
- Update existing values (data is validated!)
- Delete records
- Add (non-bound) calculated columns
- Format your data as you want
- Use lookup-values (just as with the drop-downs in the Ax client)
- Add 'matrix fields' to create aggregate views
- Changing the value of an aggregated field automatically updates the original values (proportionally)

All modifications that you do on bound data stays within Excel until you hit the 'publish' button, this sends the data back to Ax.Actually this can be used as a new way to bulk-insert data (think data conversion).

Is it limited to MS Excel?
No it is not: you can use MS Word to create nice looking documents based on Ax data.
Again: formatting can be applied, columns/tables can be created and populated, calculated columns can be added, support for multi-language using the Ax labels, the document handling feature can pick up templates from a SharePoint library and use these to produce customized documents, … 

Allright! Can I replace the reporting in Ax by Word documents then?
That's not the intention since you will be missing features like batch support , your hardcoded template texts will not be language-sensitive, the paging of the generated documents is not guaranteed, ...

Also: Ax2012 now support copying data from an Ax running in a remote desktop to an Excel running on your local machine. This saves you an Office license on the terminal server.

So this actually is a nice feature to read data securely into Office so that end users can see live data, refresh, modify, add and delete data in a way that's convenient for them and publish the data back to Ax. It is an easy way of creating re-useable reports (Excel) and documents (Word) without any development.

DAXCONF - Building, Configuration and Customization Cubes

Cubes and OLAP are not realy my piece of cake, so I'm not sure if my highlights below stress the correct innovations (especially since I've not done too much with cubes in previous versions).
But anyting would be better than nothing, right? Right! And if I really start talking trash … just let me know!

- Ax2012 comes with a number of preconfigured cubes out-of-the box. These are all aware of the new Ax2012 concepts like security, the dimension model, data effictive tables, ….
- Cubes support multiple languages
- Cubes are created and managed through a wizard in Ax, this wizard helps you to deploy, configure, update or create new analysis service project.
- These analysis service projects reside in the AOT, under the visual studio projects node, which makes them part of a model and therefor easier shipable.
- Changing licence/config key changes are no longer an issue; the configure option in the wizard take care of this
- The role center pages in Ax no longer display errors when the underlying content is unavailable (this type of error messages are hidden)
- Views can now be used in perspectives
- New calendar and time dimension options are introduced
- Rolebased permissions in Ax and SSAS are alligned

Hope this gives you a heads-up on what's coming.

DAXCONF - Developing Advanced Reports - Deep Dive

This session promoted the use of SSRS as a reporting engine in Ax2012.
Let me rephrase that: '… as the reporting engine in Ax2012'.
The Ax reports as we know them from previous versions are still there in Ax2012, but no new development is to be done on them. The 'old' Ax reports are supported in the sense that they still exist and can be used, but there not supported in the sense that all Ax reports are converted to SRSS (read: SSRS is the way to go).

And since the security framework and the datamodel has had some serious redesigning in Ax2012, your reports will probably be broken anyway. Upgrading them would not be a good investment. The better decission would be to create new SSRS reports right away.

Not everyone was wildly enthousiastic about the SSRS integration in previous versions.
Do know that the SSRS integration in Ax2012 is seriously improved  and offers in combination with the latest 2008 version of SSRS a fair performance gain.
SSRS is totaly aware of Ax2012 metadata and new concepts such as the org model and security model. It has batch integration and archive support. Besides that, SSRS just offers cool graphical stuff and layot possibilities that just were not possible in Ax reporting. Let's face it: Ax reports were not eye-catchers.

The SSRS-Ax reporting framework allows creating basic reports (that need no coding at all).
OK, but what about more complex reports such as the projInvoice or salesInvoice?
All converted to SSRS! The new reporting framework gives developers different types of classes to customize reports as required: data provider classes, data contract classes and controller classes. These give the developer the same possibilities as with the Ax reports.

What does SSRS offer more over Ax reports?
- Awareness of Ax2012 metadata and concepts
- Correct PDF output
- Support for images in batch
Basically we the tiny shortages we had in Ax reports are a goner.

Is there anything in the Ax reporting framework offer that is not in SSRS?
Well, Ax reports allow the user to define sorting, subtotals, grouptotals, print ranges, …
SSRS does not offer this. And SSRS may be bit moody when it comes to footers in some circumstances.
But that's about it.

Not too bad this SSRS if you ask me!

DAXCONF - Role-based security (RBS) and eXtensible Data Security (XDS)

I just attended 3 sessions on the new security framework in Ax. The content is just too much for one post. I'll give the highlights:

RBS (role based security)
- The new security framework is based on:
  - Roles: a group of duties specific to a function (accountant, mechanic, clerck, manager, …)
  -  Duties: a group of related privileges needed for a specific task (sales order entry, approve expenses, order picking, …)
  -  Privileges: a group of entry points (mostly menu items) needed for a specific action (create sales order lines, set up HRM parameters, start a pickingroute, …)
  -  Permissions: a group of base objects  each with the required level of access (update salesTable, update HRMParameters, …)

- Developers are responsible to provide the appropriate privileges and permissions
- An administrator can define roles and duties based on the privileges and permissions -and link uto roles

- Standard out-of-the box all roles, duties, privileges and permissions are available to secure all functionallity in Ax2012! Impressive: previous versions had … no out-of-the-box security configured.

Some other facts:
- SecurityKeys are no longer used
- Companies are replaced by legal entities
- Domains are replaced by organisations
- Users groups not longer used in a security context
- External users (without an AD-account!) now can log on to the EP (using # ways of user authentication  in SharePoint 2010)

XDS (eXtended Data Security)
- In previous versions there was RLS (record level security), where you couldn't do much more than restricting the selected data by adding a where clause to tables
- Ax2012 takes RLS to the next level: it's called the XDS framework
  - the combination of an application context (form, menu item, ...) and a role context (user, role, ...)
  - is applied to a policy (based on queries, so more flexible compared to RLS, also the meta data is used to apply data security on linked tables)
  -  this policy filters the data as configured

In an example this would be: if you define a query on the salesTable, but a policy defines you can only see customers from a specific group ('x'), you will only see the salesTable records for customers of group 'x' … even if your select looked like 'select from salesTable', it would become something like 'select from salesTable where exits (select from custTable where custTable.PK = salesTable.FK and custTable.group = 'x')'. Applying multiple policies, would add extra 'exists' clauses to the query.

- Ax2012 comes predefined with 11 policies (3 enabled by default)

- This sounds like a performance killer ... well there's a solution (as with most potential performance issues in ax2012). Policies that result in complex queries including multiple joins can be cached in temp tables that will be populated the first time the complex policy-query is executed. The next time this complex query is executed ... it is not ... the results from the temp table are used in the query rather than executing the complex query over and over again. This is called a 'myConstruct' and the refreshrate is customizable (on each execution, per session, ...). Ax2012 comes with 7 myConstruct tables out-of-the-box.

- A super-duper feature for developers is the possibility to get the actual SQL statemets (policies applied) from within X++.

The goal of this new security framework is
- Faster implementation
- Role-tailored user experience
- Comprehensive data security

I'm impressed!

DAXCONF - Patterns in building client forms & usability

Hi,

A number of new form patterns are introduced, documented and described in best practice documents: master data forms, header/line forms, transaction forms, parameters forms, …
Each type is described in UX (User eXperience) guidelines and development guideline documents telling you exactly how each formtype should look like, which controls suppose to be where on the form, which properties should be set, … in order to get a uniform Ax-look on all forms including the custom-ones.

Some facts about forms in Ax2012:- You can create a new form based on a form template so that you get a headstart on the basic layout of the form. A 'list page' style form has a filter group for example.
- The style of the form is defined by a new style property (=template described above), this property tells the form manager how to behave
- A form node in the AOT has a few new sub-nodes:
  - Permissions: helps you define which part of the form is accessible depending on security
  - DesignList : flat list of all form objects (see further down for details)
  - Parts: reference to 'parts' objects, defined in the new AOT node 'parts'
- A part actually is a form, but can be plugged into an 'fact box' on a list page form for example (in like a sort of widget)
- Tab pages are replaced by fast-tabs (=horizontal expandable/collapsable area's)
- The buttons on the right side of form are no more there: replaced by the action pane.
- A form has a view mode (to prevent unwanted data changes) and an edit mode
- Forms can have a detail view and a grid view (kind of like the 'advanced' button on the salesTable form in previous versions)
- A form can be published to the enterprise portal (just like that!)
- Quite some new properties are introduced:
  - Form controls have a property to define where they should exist: client and/or EP
  - A form has a interactionClass property, this class handles for example events for both the client and the EP (forms seem to be publishable to the enterprise portal)
  - several other properties (not only on forms) to realize what required lots of coding in previous versions

Besides the fast-tabs some other new controls are introduced:
- Drop dialog: a dialog sort of sticked to a form (so no separate form is created) activated from the action pane
- Enhanced preview: can be linked to a formcontrol via the previewPartRef property, enables you to extend the standard tooltip popups
- Fact box: typically on the right handside of detail and list pages, a collection of parts with additional data related to the active record (address, contact information, …)

Controls for managing information (country/region filtering)
- menu-items get an property representing the ISO code
- only the menu-items matching the current company's ISO code are shown
.Net controls can easily added to Ax + the events can be catched in X++.
Easier form customization:
- Besides a design, a new node 'designList' contains a flat list of all form contols (including new properties such as hierarchy parent).
- This node normally should not be used: changes in the design node are reflected here.
- Metadata is made much more granular (=reduced upgrade cost): like with tables and classes, controls on a form can be overridden without promoting the whole form object to the next layer (thanks to the designList)
- This obviously reduces upgrade costs on forms

Improved performance- Data method caching much easier (property 'cacheDataMethod' and code attribute on data method)
- onlyFetchActive property on datasources also used in inherited table structures

I know: it's quite a list and somewhat vague … but the demo's were pretty amazing. The draft version of the "What's new in Microsoft Dynamics Ax2012 for developers" document is about 80 pages … The complete what's new for Ax2009 was 51 pages. Go figure.

DAXCONF Ax programming model improvements

hi,

We just finished the session on programming model improvement ... information overload :-)
The speed of the session is as impressive as the improvements themselves. As MS announced, 'the surface is sratched', we've got an impression of the innovations, no deep-detailled-dive. A rough list of what's been shown:
- table inheritance possibilities
- date effective tables
- computed columns on views
- introduction of having clause
- support for SQL temp tables
- introduction of watermarks (on obsolete fields and dateMax date values)
- All above realised by a bunch of new properties on tables, indexes, forms ….
- Unit of work pattern to reduce developer complexity in managing CUD sequencing and transaction mgmt
- delegates and eventing

The idea behind it:
- write less and cleaner code
- encourage model driven development (optimal use of the data layer) and use new customization paradigms
- use 'event based customization' over 'source based customization'

This technical conference is just the beginning … getting into the details, applying all the inovations and implementing this will require a considerable amount of effort and time.
Good to know all sessions are recorded and can be replayed afterwards, not only to view the sessions again, but also to have a peek at the sessions we couldn't attend.

DAXCONF - Keynote

hi,

Just attended the opening keynote session on the MS Dynamics Ax Technical Conference. MS Dynamics Ax 2012 - which will be the official name - will include some major changes. Or as Vice President Hal Howard stated 'it is a generational shift in ERP'; 'Ax 2012 it is not just the next release of Ax'. We're looking at enhanced Visual Studio integration, event based extensibility, dramatically improved .Net interopability, inheritence-capabilities for tables, no more reports in Ax (but all in SRSS), ... It seems there won't be any areas where Ax 2012 is not changed and improved.