Microsoft Dynamics 365 / Power Platform

Microsoft Dynamics 365 / Power Platform - page 13

Jul 18, 2011 - AX 2012 Models & Events Part1: Model Architecture

Filed under: #daxmusings #bizapps

In this 3-part series I will let you in on the power of the 2012 model architecture in combination with events. There is a paradigm shift in regards to customizations and even ISV code that will make life so much easier, provided everyone uses this new model. To that end, I will talk a bit about models, events, and then put it all together and SHOW you the advantage. The originally article kept getting bigger and bigger, so I decided to split it up in three parts, I will publish one every day.

Part 1: Model Architecture Part 2: Events Part 3: Full Walkthrough (with code and screenshots)

In this first article, we need to learn some basics about models. The standard layering system as we’ve known it for years still exists. This means, when you modify an existing object, it gets copied into the layer you are working on, and your changes will be saved there. This means the existing object is still intact in its original lower layer, but AX uses its index to execute the object in the highest layer it can be found in. There are however some interesting changes in AX 2012 even on that front. Certain objects such as reports (which only exist in AX 2012 for backwards compatibility) and forms, used to get copied into your working layer, in their entirety. This meant, even if you just added a method or control to a form, or move a control to a different tab, the whole form was over-layered. This opposed to classes, where adding or changing a method only puts THAT particular method in the higher layer, not the whole class with all of its methods. This has been changed in AX 2012. Forms are now over-layered on a control and method level. This is achieved by giving each control a property that indicates what parent it is attached to. This means AX can now keep track of each control. If you move it, the control still exists, it just changed its parent property. So when you add a new control, it is the new control that gets put in the higher layer. For customizations, this is already a blessing, making it much easier to merge customizations, merge a customization with a hotfix rollup, etc. This also means in the AOT you can now see your traditional tree-view design, or you can look at the flat list of controls. This may be necessary in situations where controls get “orphaned” (the parent control is removed). There are some strategies when importing to deal with these situations.

So, back to the models. They are basically compartments within each layer. An object exists in one or more layers, and in EXACTLY one model per layer. Let that sink in. The immediate question then becomes: what good does it do if an object can only exist in one model per layer? Well, there’s a few things. For one, since we no longer have AOD layer files to move, we can export models from a layer to a binary format, and move (export/import) those between environments. This has the added benefit we don’t have to move the whole layer, but logically segregated pieces of code, such as one custom module at a time, or certain third-party apps that are installed in the same layer. Models have an extension of .axmodel, and can be signed (like assemblies) to ensure integrity and authenticity when distributing. The “import” (aka installation) of a model can be done using powershell or regular command line, or you can create a custom installer package to install the model. Of course models can be “uninstalled” in the same fashion. All that is required is a restart of the AOS (think rebuilding the index in previous versions). When you then open AX, it will prompt you with a warning and some choices related to compiling, synchronizing, etc.

I can see you wonder (yes, this blog enables your webcam so I can see you wondering) how this is going to work. Sure, you say, forms are now granular to a control-level, but still… when it comes to code, multiple mods may be touching the same piece of code. This will require merging on install, and it will mean the object/method is one model or the other, which makes model moves useless, since I’ll have to move them all, or resume my old-school XPO practices and merge on import.

AHA! You hit it now. Thank you for leading me to the point of this article series. Events provide the missing piece to the puzzle.

Next: Part 2: Events

Jul 6, 2011 - Generic Unit Tests for Dynamics AX in Visual Studio

Filed under: #daxmusings #bizapps

A little while ago, I blogged about unit testing and integrating this with TFS builds. We have this running currently, but with some drawbacks. We basically wrap each X++ unit test method in a test method in C#, which reads the AX unit test XML results file and either throws an error or passes the test. As Dave Froslie pointed out to me, there is such a thing as “generic tests” in Visual Studio. This is basically a means to invoke an external process, which can then generate a summary results file in .TRX (xml) format. That of course would be a much more efficient way of doing this. Seeing that AX has “listener” classes, which can subscribe to the unit test framework’s output, all we need to do is create one that writes the TRX format that Visual Studio is expecting…

I have created the listener and it’s up for download on the AX Build project on CodePlex. In this post I will describe how to set up the generic test in Visual Studio 2010. This process works for both AX 2009 and AX 2012. The code is the same, but make sure you download the right XPO from CodePlex (AX 2009 doesn’t like the AX 2012 XPO format).

For a quick overview on how to create unit tests in AX, please check out the following pages on MSDN for AX2009 and AX2012.

For the purpose of this walkthrough, we’ll assume you have an X++ test project containing your tests (aka “test suite”). Let’s also assume this project is called “TFSGenericTestProject”. Replace with the name of your actual unit test project in AX.

First, download the SysTestListenerTRX class for AX2009 or AX2012 from the AX Build CodePlex project. Import the class into AX. This implements the TRX format for a unit test “listener”. A listener is a class AX unit tests use to output their results. TRX is the result file format which generic unit tests in Visual Studio can read. Feel free to open these, they’re basically XML files. To make the generic unit tests work, all you need is the class. The enum you’ll need if you want to run the TRX listener when running unit tests inside AX, but is not necessary for the TRX listener to work.

AX unit tests can be run from a command line. You can start the AX client as usual (either using the default config in the registry, or by passing a config file as the first command line argument. Furthermore, you can pass “RunTestProject” as a startup command, followed by an underscore, followed by the name of the AX unit test project. The syntax for this is a little strange perhaps:

-StartupCmd=RunTestProject_TFSGenericTestProject

Where “TFSGenericTestProject” is the name of your test project in AX. Now, the parsing of these arguments get even more interesting. The class that runs the unit test project supports two more arguments; one that supplies the name of the listener, and any subsequent arguments will be passed into the NEW method of your listener (the TRX listener’s NEW method accepts an optional filename). The listeners are all called SysTestListener_NAME, and it’s that “name” you need to pass as an argument. So, putting this all together, to start AX using a configfile.axc, run our TFSGenericTestProject with the TRX listener, and output the file to c:\unittest.trx, you would use the following command line:

Ax32.exe "configfile.axc" -StartupCmd=RunTestProject_TFSGenericTestProject@TRX@C:\unittest.trx

Now, if your filename/path contains spaces, you will need to wrap the whole thing in quotes. Since the -StartupCmd and the consequent class names etc are considered 1 argument, you would have to wrap it from start to end, as such:

Ax32.exe "configfile.axc" "-StartupCmd=RunTestProject_TFSGenericTestProject@TRX@C:\my folder with spaces\unittest.trx"

Ok, so now we’re ready to create our Visual Studio generic test project. If you already have a solution (.sln) for your TFS project (which you will if you’re using builds), you will add a new project to the existing solution, don’t start a new solution. For the new project, select the Test template / Test Project. This will actually create a new test class for you, but we do not want to use this, so go ahead and delete that UnitTest1.cs file. Right-click your project again, and select Add / Generic Test.

As the existing program we wish to wrap, enter the path to your AX client (Ax32.exe). The command-line arguments are the arguments we talked about earlier, except one difference. The generic test supplies a variable for the test output directory, which we can leverage for our summary results TRX file. The only thing we want to change is the result settings, where we can specify the filename/path of the TRX file. Also note there is a time-out feature (this can be useful in case your ax client can’t connect to the AOS).

Once you have this setup, you’re DONE! Assuming you actually have an AX unit test project called “TFSGenericTestProject”, you can now run this test, and you will see it open AX, run the tests, close AX, and Visual Studio will show you the results of your tests. Double-click on the test results at the bottom to see a break-down of your methods, with their results and the messages associated with them.

The test project should be automatically included in your TFS builds if you’re using that, assuming you added the test project to the build solution, and it contains “test” in its name. In your build definition under “Process” you will find a section under Basic that runs the tests based on names containing test.

Jun 30, 2011 - AX 2012 Documentation Round-up (June 2011)

Filed under: #daxmusings #bizapps

With the launch date of AX 2012 coming closer and closer, your organization should be preparing for this major release. There are lots of resources being made available almost on a daily basis. It’s hard to keep up with documentation being released every day, but here’s the list I have so far. Feel free to leave any additional links you may know of in the comments.

Major Sources for AX 2012 documentation: Microsoft’s Download Center (search for “AX 2012”) MSDN AX 2012 Beta Page PartnerSource US Launch Page (requires MBS Partner access) PartnerSource Global Launch Page (requires MBS Partner access) PartnerSource Getting Ready for Microsoft Dynamics AX 2012

This "Getting Ready" page on PartnerSource is extremely valuable. It contains the "What's New" training material (including functional), it contains the Convergence Hands-on labs, the Technical Conference 2011 session videos, etc!

The list below contains all the publicly available documentation (all outside of PartnerSource).

Documentation: Upgrade Guide Installation Guide Deploying Customizations Across Environments AX 2012 System Requirements New, Changed and Deprecated Features in AX 2012 What’s new in AX 2012 for Developers AX 2012 Implementation Planning Guide Selecting the Best Development Technology for your Development Scenario (White Paper) Updating the Uses of the Ledger Posting Framework (White Paper) Services (White Paper) Lean Manufacturing - Production Flows and Activities (White Paper) Microsoft Project Server 2010 Integration (White Paper) How to Write Data Upgrade Scripts for AX 2012 Code Upgrade (Multiple White Papers)

This contains the following White Papers: Code_Upgrade_Overview_AX2012.pdf Developing_with_Table_Inheritance.pdf Eventing_AX2012.pdf Implementing_and_extending_the_organization_model_in_Microsoft_Dynamics_AX_2012.pdf Implementing_and_Updating_the_Human_Resources_Framework_AX2012.pdf Implementing_Budgeting_for_Microsoft_Dynamics_AX_2012_Applications_AX 2012.pdf Implementing_InventTrans_refactoring_for_Microsoft_Dynamics_AX_Applications_AX2012.pdf Implementing_Item-Product_data_management_framework_for_Microsoft_Dynamics_AX_2012_Applications_AX2012.pdf Implementing_the_Account_and_Financial_Dimensions_Framework_AX2012.pdf Implementing_the_Address_Book_Framework_for_Microsoft_Dynamics_AX_Applications_AX2012.pdf Implementing_the_Budget_Control_Framework_for_Microsoft_Dynamics_AX_2012_Applications_AX_2012.pdf Implementing_the_Operations_Resource_Model_AX2012.pdf Mapping_the_LedgerTrans_table_to_General_Journal_tables_AX2012.pdf Migrating_EDT_Relations_in_Microsoft_Dynamics_AX2012.pdf Shared_Currencies_and_Exchange_Rates_AX2012.pdf Using_the_Enhanced_Number_Sequence_Framework_in_Microsoft_Dynamics_AX_2012.pdf Using_the_Policy_Framework_in_Microsoft_Dynamics_AX_2012.pdf Using_the_refactored_Formletter_framework_AX2012.pdf

Upgrade Script Reference Reference: Tables and Table Groups Developing Extensible Data Security Policies (White Paper) Implementing the Tax Framework (White Paper)

Jun 29, 2011 - AX & TFS FAQ

Filed under: #daxmusings #bizapps

This is my first post containing an FAQ on the AX and TFS integration. I get a lot of the same questions, and below are the most commonly asked ones. This is a lengthy post so I apologize to the RSS subscribers.

Feel free to leave your questions in the comments, and I will keep this FAQ updated.

AX & TFS FAQ

Q: How to move one X++ project at a time, and what if it contains objects that have been modified for other X++ project as well?

A: This is where TFS' intelligent branching/merging process comes into play. The prerequisite is that you check in code for one X++ project at a time. That way, TFS knows which changes are "bundled" together. Obviously you can multiple changes over multiple days, but it is imperative that you never check in changes you made for different projects. When you merge a change set to another branch, which contains objects also modified by other projects that you are not moving, TFS will raise a flag. It will allow you to make a decision (on the XPO text) whether you wish to move the whole thing anyway, whether you want to move just the change associated with the change set you're moving, or whether you wish to manually modify the change to make it work. This works well for code in general but I always manually check to make sure anyway.

Q: How to build one project or one object or one changeset?

A: Although I understand the question in certain situations, I feel like there is never a good enough reason not to build the whole thing (except time perhaps). In any case, this basically boils down to creating a custom build workflow. When building just one object or one changeset, I'm fairly certain that can be done with the workflow. To build just one project, that is more tricky since TFS is not "aware" of projects, for what it's concerned, all it has is a text file (xpo) dubbed the "project definition". That being said, consider what we're doing with builds today: we are taking all XPOs and combining them into one giant XPO to import. What can be done of course it instead of combining all XPOs, first read a project definition, then combine only the objects described in that. Then follow the normal process for the build.

Q: How can we build a patch/hotfix layer?

A: This relates to the previous question. If you have a project containing the objects touched for your patch, you can use the combine-xpo approach I described above. If you want to build certain changesets only, either build a custom workflow, or consider perhaps a different branch, which can then be completely built in a patch layer…

Q: How can we have multiple developers work on the same AOS using TFS?

A: Due to the way the standard AX integration is designed, this is not possible. Of course in reality, this is a VERY common scenario, and Microsoft has asked a lot of questions and asked for lots of feedback from me and other in the community to try and solve this issue in AX2012. The solution unfortunately, has not worked it's way into the product. Instead, we will get more access to the integration code with TFS (the .NET "proxy" assembly is now a visual studio project in the AOT) so we can make any changes we need to ourselves.

A: That being said, in our AX2009 environments we do have multiple developers on one AOS. This is done through some customizations to AX, and some NTFS (windows filesystem) tricks. Bottom line: - We modify the AX integration to append the AX username to the local repository folder, this satisfies TFS that all users are using a different repository "working folder" - We add NTFS "junctions" so that although each user has its own folder, they are physically all the same folder (think sym links in unix/linux). This satisfies some issues with AX (namely if you have outdated XPOs there's a danger of updating the AOT with old code when you undo a chance for example).

Q: Can AX2009 support branching in the source tree? IE can I point AX 2009 to use a SUB-folder in my source tree rather than the root?

A: Standard AX 2009 will always put all the files starting at the root. Please note that this has been fixed in AX 2012 and you can specify a branch folder there.

A: For AX 2009, we have branching working at our offices at Streamline Systems. The only thing you really need to do is, after AX sets up your workspace, is changing that workspace (using visual studio) so that the working folder on the server points to your sub-folder. Of course, it only takes one user to not do this properly to mess up your source tree. To that end, we have automated this "fix" on the workspace by adding some .NET code in AX that gets executed when you log into AX, and changes your server working folder.

Q: In ISV scenarios, how can we maintain multiple components, and create unique builds for clients containing a unique combination of our components?

A: To be honest, I do not have a good answer to this. For big components, it makes sense to develop them in separate AX environments. For small ones, that sounds like overkill. In any case you can hook them up to the same ID server to avoid object ID collisions.

A: As far as branching is concerned, this would require a branch for each unique combination where you merge in the components you need. That is technically not unrealistic, but may be too much work for your scenario. Especially if you then need to branch for each release off of that…

A: I believe the AX developer community needs to start thinking more in lines of general software development practices, which in the past has never been the case. There are issues due to features and architectural challenges that are unique to AX, but most of the time those can be overcome. In this case, think of each component as a DLL or software product you would sell to a client. The uniqueness in AX is that they will all go in the same layer. But honestly, that's an installation detail, and it should not prevent you from considering each component as a unique product in your development cycle.

A: With the coming of AX 2012, the introduction of models, AxModel deployments and installations, I believe it will become easier to do these sorts of things.

Q: In client scenarios, clients may be doing their own development in a higher layer, how does that work?

A: When clients do development of their own, it should go in a higher layer than your delivered solution. This makes sense from a maintenance/support and liability point of view. We usually deliver our builds in a VAR layer and recommend customers use the CUS layer for their customizations.

A: In situations where you do off-site development and move layers into client environments (are current setup at Streamline Systems), it is true clients may be over-layering your objects so that any changes you make are not reflected in the final code layer "combination". To that end, you have a build log from TFS that can tell you what objects have been modified since the last release, and you have a layer compare in AX to detect layer conflicts. This sounds like a lot of work, but it isn't really. The point of source control is that you know exactly what has changed, so unless you have a ton of changes every release, the layer merge effort should be minimal.

A: In situations where there is development in multiple layers at the same time (such as traditional client projects where all development is done on-site), there are unique challenges. Even though for example fields on a table can be in different layers (ie not the whole table is in a layer at the time, like reports or forms in AX 2009), from a source control point of view the whole objects is moved into the higher layer. This prevents you from making ANY changes to the object in a lower layer as soon as it's over-layered. I have had numerous discussions with Microsoft on this subject, but there is no good way of resolving this.

Q: Why do we want to move layers and not XPOs as we’ve always done?

A: My favorite topic. Moving XPOs is literally moving source code (the XPO is a plain text file containing the source code). There are several issues with that approach: 1) the person importing the XPO can make mistakes (merge issues, object IDs, "delete tables and class members", etc). An XPO also implies someone took an export somewhere, which is the same issue, mistakes could have been made in the exporting. 2) from an auditing perspective this "should" be unacceptable: whomever imports this into production can modify the code, which is a segregation of duties issue, and a liability since after import the code cannot be guaranteed to be exactly the same as the test environment (export/import could introduce changes, merge issues, etc)

A: Usual complaints are one needs to take down the AOS to move in a new layer. My response to that is taking down the AOS, moving in the layer and starting it up again is a matter of minutes. Proper procedure when moving XPOs would be that all users are out of the system anyway, and that you do a full compile afterwards to make sure there are no issues. The difference is minimal, and not an excuse to keep doing XPO exports.

A: Moving compiled, binary code is the approach anyone should take. You do not receive hotfixes for Windows from Microsoft in source code form, you receive binary updates (new DLLs, EXEs, etc). This is also where Microsoft is going in AX 2012. There are models, and model exports (.AxModel). XPOs in AX 2012 are not the recommended way of moving code.

A: By moving code in layers, they can be versioned easily as "releases", which makes it easy to keep track of what version of the code is deployed where. XPO moves (unless extremely strictly controlled) have the potential of having different versions of different objects. Layers are the only guaranteed way of having two environments use the same code.

Jun 28, 2011 - Unit Tests - Revisited

Filed under: #daxmusings #bizapps

As I have posted on this blog previously, we at Streamline Systems have done some minor testing and created a small framework to be able to run unit tests during our TFS builds. The reason I have not put this up on the CodePlex AX build project yet is that the solution is not entirely elegant… it requires a C# unit test project be created, and a wrapper method for each test method in AX. However, after talking with Dave Froslie at Microsoft and some investigation (my Visual Studio skills are still a work-in-progress), there exists such a thing as a “generic” unit test in Visual Studio. Basically, this is a one-time unit test project, which wraps a command line process and takes an output file from that (.trx file). I’ve not created an actual test on this, but the .trx file is basically an XML file, so the only thing required would be an XSL transformation. And as far as that goes, one could extend the standard AX unit test XML output class and transform the output before writing to file.

Since we’ll be working on converting our build processes to AX2012 soon, I’m expecting us to implement this for AX2012 (which I think last beta build I looked at, it was still the same code for XML output of unit tests).

Jun 16, 2011 - AX2012 .NET Proxies for Kernel Objects

Filed under: #daxmusings #bizapps

For those who’ve played around with Visual Studio and AX2012, the proxies are a great way to most of your logic on the .NET side, without too much hassle. One thing is apparent after a while though: how do we create proxies for kernel classes and tables? For some classes, there is a Sys* version (eg SysQueryRun, SysDictTable, etc), but first of all, you don’t get the static methods of the original kernel class, and as for queries, there is no Sys* equivalent of QueryBuildRange and so on.

So how do we get the proxy? Turns out, this is all handled by the .axproxy file extension. Just create a new file (mind the case! remember .NET is case-sensitive!) in the format ObjectType.ObjectName.axproxy. For example, to get QueryRun, create a file:

Class.QueryRun.axproxy

The standard Visual Studio AX tools just put a plain text message in this file:

This is a Microsoft Dynamics AX proxy file that generates classes for the element that it represents in the project to which it is added.

With the file created, you can drag and drop the .axproxy file onto your Visual Studio project, and the build will generate the proxy for you. (again, watch the case… for example the class QueryBuildDataSource has a capital S in datasource!)

Obviously this is not the recommended way to create proxies, but I have yet to hear a more official way to do this from Microsoft. As for built-in X++ functions in AX, the official word is there is no way to get those, except creating a wrapper class in X++ and generating a proxy for that.

Jun 1, 2011 - TFS Build Workflow

Filed under: #daxmusings #bizapps

This will be a rather lengthy post. I’ve received several emails asking how to implement the TFS build scripts. Well, it’s pretty easy actually.

First things first. The build scripts need to be available to your build agent, of course. To that end, you can either put them in a fixed location and call them from that fixed path. However, at Streamline Systems we actually sometimes switch between building on a dedicated build VM (per client - to support different versions of AX) to building on an AOS server where consultants can remote in to test. To support our multiple scenarios, we actually put the build scripts IN the source tree, so that the build script workflow can run it, regardless of what server or where the scripts are located. They’re always in the source’s root. The added benefit is you’re versioning your build scripts, in case you need something crazy for a particular project/branch.

Anyway, the following is a TFS project based on the CMMI template. I’m unsure if the Agile template has a different build template. I’m assuming it’s slightly different, except for these essentials steps, regardless of your project management style.

First, locate the spot in the XAML (have fun scrolling) where it actually does the compiling. I’ve noticed there’s more than one MSBuild statement in there, so locate this exact spot.

Now, we want to get rid of the MSBuild task (delete!) and add the calls to our build scripts instead. To get the console output, errors and warnings to show up in the logs, we need to capture the output. So, to that end, add a step (where the MSBuild used to be) and add the “InvokeProcess” workflow step. In fact, add two while you’re at it. Now, as you may have noticed, the build scripts have some optional parameters. The cool thing with TFS is, you can create “arguments”. That way, even if you don’t use the optional parameters NOW, you can still use them later. Also, we’ll use arguments to make the AX configuration file a parameter to the build script. As for the standard and error output, you can have it write to the actual output, and then use them to write as build output / build errors. Completed, it should look something like this.

As you can tell, the process you invoke, should be “powershell.exe”. We use the SourcesDirectory as the working directory, since that is where our build scripts will be located (TFS will pull them from the source tree, along with the XPOs). As for the arguments, we pass in the main build script name along with the properties.

You can see we added an “argument” for the config file which you can then use in the parameters to the build script. As for the second InvokeProcess step you’ve added, that is used to get the compiler errors and warnings. Same setup for the workflow step, except this time, write the standard output to the writebuildwarning, and error output you write to writebuilderror.

Now you setup the build definition; you will need a blank solution file… you don’t need anything in it. I’m sure you can find it in the workflow where it looks for it (and remove that step), but we never bothered.

I hope this will get you started with the scripts. Let me know how it works out for you!

May 31, 2011 - Build scripts update

Filed under: #daxmusings #bizapps

I have updated the Dynamics AX 2009 build scripts on CodePlex.

This update features a fix for the clean layer list, there was a powershell variable issue (the variable was declared as string, so couldn’t be re-used as an array). There’s also an additional “feature” that contains a tweakable time-out for the calls to AX32, to avoid issues where the build process gets stuck due to a client dialog (can’t connect to AOS etc). A third addition/fix is to remove the read-only flag from the label file after copying it to the application folder.

I’ve associated a new release with all the scripts in one zip file.

May 5, 2011 - AX 2012 & .NET - Coding Business Logic in C#

Filed under: #daxmusings #bizapps

AX 2012 has pushed the boundary of .NET interop, and - as Microsoft touts - makes managed code a “first-class citizen” in the application. This is true - with some limitations on the eventing side in my personal opinion - but there are some caveats, which can easily be overcome if you understand the underlying workings of the proxies.

Consider the following example, in C#:

Query query = new Query(); query.addDatasource(Global.tableName2Id("CustTable")); QueryRun queryRun = new QueryRun(query); while(queryRun.next()) { /* .... */ }

At first glance, this would work. And it compiles as well. However, a runtime error occurs complaining that object of type “Query” does not have a method called “Next”.

So what’s happening? Well, remember the classes in managed code are proxies. So, they can be instantiated by giving them a reference to an existing X++ object. When you pass in your query object to the constructor of QueryRun, it will try to wrap the managed QueryRun proxy around the X++ object reference, which is the Query.

As you can see in the IntelliSense, the other overload of the constructor is to pass in an object of type “object”. Not much documentation there, but that is in fact the X++ New() parameter profile we would like to invoke. So, we change our C# code to:

query = new Query(); query.addDataSource(Global.tableName2Id("CustTable")); queryRun = new QueryRun(query as object); while (queryRun.next()) { /* .... */ }

Now, this will work as expected.

Apr 27, 2011 - AX 2012 Events

Filed under: #daxmusings #bizapps

With the introduction of events in AX2012, a slew of possibilities has opened up. At the technical conference in January 2011, Peter Villadsen first unveiled the power of the new functionality. In conjunction with that, I had prepared a lab exercise which was available at the conference. I am working on preparing a new lab document, which I will post here on my blog, which is largely based on the original tech conference document, but with more detail and showing every possibility (the tech conference lab was limited to 1 hour of work, so some features were not explicitly shown).

Before I start posting these labs here, I would like to point out a few VERY important things that I feel the AX developer community should be aware of.

1) The pre/post handlers are a powerful concept, but one needs to be aware of its limitations. The power lies mostly in the ability to add behavior without modifying, and the power to apply/install multiple solutions together without the need to merge (think AxModels, or even traditional XPOs). However:

when subscribing a handler, the subscription has a “name” property, which should ALWAYS be changed to a meaningful yet unique name. Failure to do so immediately eliminates the power of installing models without merging, since now you have two subscriptions titled “EventHandler1” and one will overwrite the other.
when changing return values in a post-handler, be aware you may not be the last handler to do so. When changing the value of a validateField(), only change it to FALSE if you have a reason to do so, otherwise, leave the return value alone. In other less obvious cases, be aware of the limitations and potential other code impacting the return value.
same goes for pre-handlers and changing arguments to the original method!

2) Managed handlers are powerful, but have their limitations. I will go into this in my lab posts, but there are limitations in what you can and cannot do, and what you should and should not do. Remember any data manipulation you do from managed code will have to cross the boundary again and could impact your code’s performance.

3) When creating delegates, look at best practices for C# delegates. Arguments should be the sender object, and a class, Extending XppEventArgs base class, containing all the variables you wish to pass. This will ensure that the API your delegate provides will never get broken. If you ever wish to add more data, you would add it to the class, without breaking any delegate subscriptions depending on your delegate method’s signature.

As far as delegates and events go, please review C# best practices for naming conventions (eg “InvoicePosting”, “InvoicePosted” as delegates, and the subscribers should be “InvoicePostingEventHandler” and “InvoicePostedEventHandler”).

Previous Page: 13 of 15 Next

Code Crib