Prevent AX Reports from Auto-Sending via Outlook Email

Requirement: When choosing email as the report destination in, allow the user to edit the email contents in Outlook rather than automatically sending.

A number of users have been concerned that outlook automatically sends email destination reports, rather than allowing them to first modify or verify the email, subject and addresses in a “new email” window.

Solution: To fix this you can modify the “SRSReportRunMailer.emailReport” method. Depending on your version of AX, modify the section around line 41 as below.

 

 

Allow non editable table fields to be modified via AIF.

Requirement: Allow requests made via AIF to modify fields with the table field property “AllowEdit” set to NO to be modified. By default if you modify a field in a service call that is non editable no errors occur but the field is not updated.

Solution: On your AXD service contract class, right click on the class , click “Override method” choose method “initFieldAccessOverrides” to override. Append the following line to the method

this.overRideFieldAccess(tableNum([YourTable]), fieldNum([YourTable], [YourField]), AxdFieldAccess::AllowEdit, NoYes::Yes);

Note: This can also be used to override the “editOnCreate” property of a table field for AIF usage.

Batch Job Updates – The Corresponding AOS Validation Failed

I’ve had it a number of times when trying to update parameters on batch job tasks that I’ve received the cryptic message “Cannot edit a record in Batch transactions (Batch). The corresponding AOS validation failed.” Due to laziness or business I’ve always dismissed the problem and found a work around, but never fully tried to understand why this message occurs.

Screen Shot 2018-01-31 at 7.47.23 AM

I’ve finally had the opportunity to drill into it and decided to share what I found.
Firstly: The message is generated because of the value “false” being returned from the overwritten method “aosValidateUpdate” on table “Batch”, this explains the text of the message “AOS validation failed”, but not the business logic reasons. Drilling into this method one can see the following business logic for allowing updates of batch tasks

1. The user doing the update must either be the person who created the record (createdBy field) or a person with access to the Display MenuItem  “BatchJob” (see Batch->IsBatchOperator). (This does work for administrators who don’t have explicit access).
2. Batch tasks may not change the company, dataPartition or batchJobId. (This is unlikely to happen as they are disable from forms anyway)
3. If the user doing the update is NOT the person who created the job then the parameters and Class of the task cannot be changed – this is the primary reason why we were experiencing the issue.

Notes: I’m not sure why the rule around changing the parameters exists, but it does, so if you want to change this then you would need to either login as the creator and change the parameters, or modify via SQL the batch task to run under your user in the case of historical batch jobs where the user does not exist.

 

AX User 101 – Tips and Tricks for Using AX

A few months ago I wrote a series of posts on things I wish somebody had told me as an X++ developer right at the beginning of my explorations into the world of Dynamics AX. Today I want to start on a new list, one prompted by years of looking over the shoulders of users and realizing that many of the very basic navigation tools that I know and take for granted are often not taught to or effectively utilized by users.

For example I’ve seen way too many users copying field data on one form E.G. Employee Id on Purchase requisition and then navigating to the Employee form to go and search for it instead of simply right clicking and then clicking view details.

The target audience of this series is not seasoned users of AX (although you may benefit too) but rather new users wanting a quick centralized list of tips and tricks that can be used to make your usage of Dynamics AX that much more efficient. Where possible I have will try to link the tips to pre-existing blog posts from other experts rather than than create yet more of the same AX posts for the web.

Navigation (Using the interface).

  1. Drilling down to parent/source records.
  2. Viewing all available fields for a record.
  3. Running multiple workspaces.
  4. Quick navigation through records from edit form.
  5. Reporting
    1. Saving reports to PDF
    2. Saving reports to Excel
    3. Emailing reports via Outlook.
    4. Auto-Reports

Working With Data.

  1. Filtering
    1. View Filter Grid – Ctrl+G
    2. Quick Filter by value.
    3. Advanced filter operators
    4. Save Queries/Filters
    5. Quick filters on lookups
  2. Interacting with Excel
    1. Export to Excel – Ctrl+T
    2. Copy & Paste to Excel
    3. Export subset of data
  3. Alerts
    1. Change based alerts
    2. Due date alerts.

Customizing your experience.

  1. Adding/Hiding fields on your form.
  2. Saving form customisations
  3. Retrieving form customisations from alternate users.
  4. Favorites Menu.
  5. Creating custom favourites with filters.
  6. Useful default user options
    1. Change default company
    2. Always open forms in Edit mode.
    3. Default filter by grid

References / Additional Reading:

  • http://atinkerersnotebook.com/2015/01/24/creating-one-master-menu-to-get-just-what-you-need/
  • http://blog.ignify.com/2015/07/07/personalization-with-microsoft-dynamics-ax-five-ways-to-streamline-your-user-interface/

AX DB Restore Scripts – Full Script

Just over a month ago I embarked on a series of posts on SQL scripts that I use when restoring Dynamics AX databases from one environment to another. We have covered topics including server setups, general configurations as well as data cleans to get your new environment up and smoothly running as quickly as possible. We are now at the end of the series and I trust it has been helpful to you in structuring your scripts.

I’d just like to remind you that these posts and scripts are not meant to be used as is but rather to serve as a guide to adapt for your specific scenario and to prompt your own thinking as to what you will need.

That said you can download my templated script here or view it below (download)

View Previous – AX DB Restore Scripts #8 – Disable users

Back to List

AX DB Restore Scripts #8 – Disable users

A few weeks ago I embarked on a series of posts on SQL scripts I use when restoring Dynamics AX databases from one environment to another. We have covered a variety of topics including various configuration and setting changes to Dynamics AX. This post will be the last in the set of “data cleanup scripts” designed to help scrub your data for use in a development or testing environment.

Disabling users.

Quite often companies or partners will require access to development environments to be restricted to a very select group of users that are aware of what to test and are also careful enough to work methodically in the correct environments (i.e. not trying to to real work in the wrong environment or test work in production). To ensure all of the above one could follow a few paths.

  1. Only provide a shortcut/configuration to users who require it.
  2. Color code your environments so that they immediately recognizable.
  3. Add a startup message to your AX environment to warn users what environment they are logged into.

All of these solutions do not physically stop users from accessing the alternate environment.  So if you need an additional security mechanism, simply disable the users either manually in AX after doing a restore or disable then along with the SQL scripts we have been building up over the past few weeks.

To disable users in AX navigate to “System Administration -> Common -> Users -> Users. Double click on the user in question, click “edit”, uncheck the “enabled” button.DisableUser

The accomplish the same in a SQL script you can do the following. I have parameterised the SQL for easier reuse or adjustment.

Note 1: Parameterising a list can be tricky in TSQL, so the above trick is what i found easiest.
Note 2: You will need to decide whether the list of users provided is inclusive (i.e. provide the list of all the users you WANT to disable) or exclusive (i.e. disable all users except for a small subset). I have provided both options, but would recommend the exclusive approach as it is more likely to give you safely give you what you expect.

I hope this assists you and will be useful in your management of your AX environments. Keep an eye out for new posts in this series!

View Previous – AX DB Restore Scripts #7 – Setting Email Templates and User Email Addresses

Back to List

AX DB Restore Scripts #7 – Setting Email Templates and User Email Addresses

In my series of posts on SQL scripts I use when restoring Dynamics AX databases from one environment to another, we have so far covered various configuration and setting changes to Dynamics AX. Today I will move on to some suggested data changes that you may wish to consider making when doing database restores. These changes won’t affect the functioning of AX, but may prevent some awkward or confusing situations like clients or user’s receiving emails etc..

These data cleanup scripts are really meant as guidelines to help you in creating your own scripts, rather than a comprehensive set of “must-do” scripts.

The two changes for today are as follows

  1. Setting your email templates to clearly indicate that they originate from a testing system. It may be perfectly legitimate for users to receive emails from your testing or development environments, e.g. for testing workflows, however it is very helpful for the users to clearly see that they are viewing test data rather than production data. So setting the senders name and address to indicate “Development” will assist.
    Email templates are found under: Organisation administration -> Setup -> Email templates
    Email_Templates
    2. Setting user email addresses. We obviously don’t want to send emails to users who have no interest in our development systems so one may, depending on your needs, want to do one of the following.

    1. Clear all user’s email addresses, except for a specific subset.
    2. Set some or all user’s email addresses to a single address (e.g. You want emails to still be generated to see that they are working, but you would like to see the contents of them yourself and not expose the user to the test data)

These settings can be found under System Administration -> Users -> Options (ribbon button) ->  Email
Email_Address

The following SQL code will accomplish the above. I have parameterised the SQL for easier reuse or adjustment.

Note, the above example clears all user email addresses except for a specific set, you could easily adjust this to set them all to a specific address as follows:

 

I hope this assists you and will be useful in your management of your AX environments. Keep an eye out for new posts in this series!

View Previous – AX DB Restore Scripts #6 – SMTP Server and DMF Folder

View Next – AX DB Restore Scripts #8 – Disable users

Back to List

AX DB Restore Scripts #6 – SMTP Server and DMF Folder

Recently I started creating a list and a series of posts on SQL scripts I use when restoring Dynamics AX databases from one environment to another, typically from production to QA or development.

We have so far discussed a number of configurations that must be changed for the new system to operate effectively and starting yesterday we moved onto exploring more optional configurations.

Today we will cover two of these items namely re-configuring the outgoing SMTP server in AX and configuring the settings for the DMF working folder.

Note: In my experience the SMTP server will most likely not change between a production and development server, but you may need to reconfigure it if moving to a new domain etc. Similarly it will work to use the same DMF shared folder between PROD and DEV, however I would recommend changing this to keep the data 100% separate.

These two configurations are located in the Dynamics AX 2012 client under the following paths.
1. SMTP Server, accessed via System Administration -> Setup -> System -> E-mail parameters.EmailServer

2. Data import, export framework shared working directory. Accessed via “Data import export framework -> Setup -> Data import export framework parameters”
DMF

To update these 2 settings above we need to do the following:

1. Update the SysEmailParameters table to update the SMTP server name (and additional login parameters)
2. Update the DMFParameters table to reflect the new shared folder path.

The following SQL code will accomplish the above. I have parameterised the SQL for easier reuse or adjustment.

I hope this assists you and will be useful in your management of your AX environments.

View next – AX DB Restore Scripts #7 – Setting Email Templates and User Email Addresses

View Previous – AX DB Restore Scripts #5 – Configure Service Accounts and Help Server

Back to List

AX DB Restore Scripts #5 – Configure Service Accounts and Help Server

Last week I embarked on a series of posts on DB restore scripts for Dynamics AX by creating a list of items in your AX database that need to be updated/reconfigured when restoring a database from a production environment to a development or QA one.

So far we have covered the majority of the most critical issues to fix when doing a DB restore, so from today on most of the scripts are basically optional. They are optional for one of the following reasons: 1. It may be common to have the same configuration in both live and dev, yet in some circumstances they may differ e.g. Business connector may remain the same if you are restoring from live to dev, but not from live to a demo VPC.
2. The data is correct but for safety or security you may want to manipulate it for a development environment. E.G. Changing all email templates to clearly indicate the source is from a dev system.

Today we will cover two topics namely re-configuring the service accounts in AX and configuring the AX help server URL.

In the Dynamics AX 2012 client, the configurations that we are going to look at are:
1. System Service Accounts, accessed via System Administration -> Setup -> System -> System service Accounts

ServiceAccounts

2. Batch Jobs, accessed via System Administration -> Setup -> System -> Help system parameters
Helpserver

To update the settings above we need to do the following:

1. Update the SYSBCPROXYUSERACCOUNT table to reflect the business connector user’s SID, networkdomain and network alias. For this step you will need to find out the SID of the business connector either by setting it manually the first time and then running select SID from SYSBCPROXYUSERACCOUNT where NETWORKDOMAIN='[yourdomain]’ and NETWORKALIAS='[yourbcuseralias]’ or follow one of the suggestions over here http://blogs.msdn.com/b/gaurav/archive/2014/06/03/get-sid-of-the-object-registry-wmic-powershell.aspx
2. Update the SYSWORKFLOWPARAMETERS table to reflect the userId of the workflow execution account.
3. Update the SYNCPARAMETERS table to reflect the userId of the Microsoft Project server synchronization service account.
4. Update SYSGLOBALCONFIGURATION to reflect new help server URL if necessary.

Notes:
1. If you are wanting to use an Alias/Network domain combination for either of the two execution accounts, I would recommend setting them manually in AX as they create users and permissions automatically when you do this. 
2. The above script assumes that execution accounts you are setting exist in the new system and have the necessary permissions.

The following SQL code will accomplish the above. I have parameterised the SQL for easier reuse or adjustment.

I hope this assists you and will be useful in your management of your AX environments.

View Next – AX DB Restore Scripts #6 – SMTP Server and DMF Folder

View Previous – AX DB Restore Scripts #4 – Reconfigure batch jobs

Back to List

AX DB Restore Scripts #3 – Configure AX servers and batch servers

Earlier this week I embarked on a series of posts on DB restore scripts for Dynamics AX by providing a list of data entities in your AX database that need to be updated when restoring a database from a production environment to a development or QA one.

Today I will be drilling into how to reset/configure your AX AOS and batch AOS configurations via DB scripts. These scripts are necessary especially for the SSRS script and for the batch server update script (available soon) as these rely on a correct AOS configuration.

Note: Under normal circumstances a new configuration for your AOS will automatically be created if it does not exist when the AOS starts up after a restore, however all your other configs like batch jobs, SSRS settings etc won’t be pointing to it, but rather the old settings that are not cleared. Thus I prefer to fix this in my script.

In the Dynamics AX 2012 client these configurations are located under System Administration -> Setup -> System -> Server Configuration

AOS_servers

Depending on the configuration of your source system (e.g. Production) you may have multiple AOSs setup here and typically your destination may only have a single AOS configuration therefore your script would need to do the following:

1. Remove all but one of the AOS configurations
2. Update the server details of the remaining configuration
3. Enable the remaining server as the “batch” server.

The following SQL code will accomplish the above. I have parameterised the SQL for easier reuse or adjustment.

Note: These changes assume everything is setup correctly on the SSAS server itself.

2015-09-03_0751

View Next – AX DB Restore Scripts #4 – Reconfigure batch jobs

View Previous – AX DB Restore Scripts #2 – SSAS Servers

Back to List

AX DB Restore Scripts #2 – SSAS Servers

Recently I started a series of posts on DB restore scripts for Dynamics AX by providing a list of data entities in your AX database that may need to be updated when restoring from one environment to another, in particular a production DB to a development or QA environment.

Today I will be drilling into how to reset the SSAS (SQL Server analysis services) configurations via DB scripts.

In the Dynamics AX 2012 client these configurations are located under System Administration -> Setup -> Business Intelligence -> Analysis Services -> Analysis Servers.

Analysis

Depending on the configuration of your source system (e.g. Production) you may have multiple servers setup here and typically your destination would only have a single server (Development) therefore your script would need to do the following:

1. Remove all but one of the SSAS configurations
2. Update the server details of the remaining configuration

The following SQL code will accomplish the above. I have parameterised the SQL for easier reuse or adjustment.

Note: These changes assume everything is setup correctly on the SSAS server itself.

2015-09-03_0751

View Next – AX DB Restore Scripts #3 – Configure AX servers and batch servers

View Previous – AX DB Restore Scripts #1 – SSRS Servers

Back to List

AX DB Restore Scripts #1 – SSRS Servers

Yesterday I started a series of posts on DB restore scripts for Dynamics AX by providing a list of data entities in your AX database that should be updated when restoring from one environment to another.

Today I will start drilling into the details of each of these items starting with SSRS (SQL Server reporting services) configurations.

In the Dynamics AX 2012 client these configurations are located under System Administration -> Setup -> Business Intelligence -> Reporting Services -> Report Servers.

SSRS1

Depending on the configuration of your source system (e.g. Production) you may have multiple servers setup here and typically your destination would only have a single server (Development) therefore your script would need to do the following

1. Remove all but one of the SSRS configurations
2. Update the remaining one to be default and update the relevant data fields.

The following SQL code will accomplish the above. I have parameterised the SQL for easier reuse or adjustment.

 

Note: These changes assume everything is setup correctly on the SSRS side.

View next – AX DB Restore Scripts #2 – SSAS Servers

Back to List

AX Database Restore Scripts (List)


sqlserver (1)
A  common task in the administration of a Dynamics AX installation is restoring databases from a live application to a development environment or quality assurance (QA) environment. However when doing so one needs to be very careful to re-configure the database so that it behaves correctly in its new context. For example you would need to re-configure your SSRS servers to point to the correct DEV/QA SSRS instance. Many of these changes can be done via the front-end, but it is very useful to script these in SQL so that nothing is missed and alot of effort is saved.

microsoft-dynamics-ax-iconThe following post aims to list as many of the potential data items that need to be changed when doing a DB restore. I will in the following days be posting the relevant SQL alongside the front-end equivalent and ultimately a full DB restore script that you can use when doing such a restore. Some of these may need to be adapted for your specific configurations and you may need to add your own based on customization etc.

Infrastructure setups

  • SSRS Servers – Re-point or recreate your SSRS (SQL Server Reporting services) instances (View Details)
  • SSAS Servers – Re-point or recreate your SSAS (SQL Server Analysis services) instances (View Details)
  • Configure AX AOSs and batch AOSs – Live environments may typically have multiple AOS’ and batch servers. Cleaning up and reconfiguring these references will assist in getting new batch jobs and SSRS setups up and running. (View Details)
  • Batch Jobs/Batch Groups (View Details)
    • Reconfigure batch jobs and batch groups to use the new server configurations as soon as the AOS is started up (e.g. Workflow processing)
    • Disable certain critical batch jobs – This is especially important if there are batch jobs that should NOT run in a DEV/QA environment. E.G. Automatic placement of orders etc… These jobs should typically never be run outside of live so we want to disable them before the AOS even starts up.
  • Service accounts (Optional) Reset your AX service accounts (workflow execution and business connector proxy) if live and DEV/QA differ. (View Details)
  • Help server(Optional) Re-point your help server URL if necessary if live and DEV/QA differ. (View Details)
  • Reset outgoing email server (Optional) if live and DEV/QA differ. (View Details)
  • Reset Data Migration Framework’s shared folder (View Details)
  • Enterprise portal websites – Re-point your enterprise portal website urls to the DEV/QA instances.

Data safe guards (Optional)

  • Reset all email templates to have a sender name and address that clearly shows that they originate from a DEV/QA system. (View Details)
  • Reset Customer/Vendor/User email addresses – We may not want to inadvertently send out mails to clients, vendors or users while performing tests. These may include alert or workflow emails. (View Details)
  • Disable users – You may require that only certain users have access to DEV/QA databases for testing, scripting the disabling of the users in bulk will help prevent the wrong people from accessing the environment and save you having to do this manually. (View Details)
  • Clean up sensitive data if needed – E.G. Bank accounts, credit cards etc.
  • Set user status bar options – It is sometimes useful to set your users status bar options in DEV/QA so that you can easily identify critical bits of information relating to their sessions. (View Details)

Clean Ups

  • Clean up SYSServerSessions
  • Clean up SYSClientSessions

Role Centers / Analysis Services: Report Server (AX) cannot load the AXADOMD extension.

Let me say at the outset that I am very new to Dynamics AX role centers and analysis services and really have a lot to learn. However I thought I would share the following problem with setting up role centers and the associated solution that I found.

Problem description: After installing role centers on AX2012 RTM CU 3 with SQL Server 2012 the following error is displayed “An attempt has been made to use a data extension ‘AXADOMD’ that is either not registered for this report server or is not supported in this edition of Reporting Services. (rsDataExtensionNotFound)” 

2015-08-19_1410

 

The Event log on the SSRS machine says the following: Role Centers / Analysis Services: Report Server (AX) cannot load the AXADOMD extension.

 

Problem resolution / investigation: After chasing my tail on this one for quite a while (including multiple re-installation etc) trying to figure out why the “AXADOMD” SSRS datasource extension was not installed I discovered that the problem did not lie with “AXADOMD” being missing but rather it might be having issues when it was loading.

Looking at the SSRS log files (C:\Program Files\Microsoft SQL Server\MSRS11.AX\Reporting Services\LogFiles) I discovered the following message:

ERROR: Exception caught instantiating AXADOMD report server extension: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.AnalysisServices.AdomdClient, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. The system cannot find the file specified.
File name: ‘Microsoft.AnalysisServices.AdomdClient, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91′
at Microsoft.Dynamics.Framework.Reports.AxAdomdConnection..ctor()

This lead me to think something might be wrong with the Microsoft.AnalysisServices.AdomdClient itself despite the AX installation validation showing up that it was installed already.

Paying a quick visit to C:\Windows\Assembly revealed that only AdomdClient version 11.0.0.0 was installed

2015-08-20_1433

The simple solution to this issue was to install the 10.0.0.0 client from http://www.microsoft.com/en-za/download/details.aspx?id=23089 after which SSRS no longer complained.

2015-08-20_1431

I hope this saves somebody some of the hassle and time that I have spent on figuring this one out.

 

Workflow – Manual Decisions

Recently a question was asked on the Dynamics AX community forums about the reason for and the use of manual decisions in Workflow. (see original thread)

Basically manual decisions allow you as a implementation consultant at configuration time to define a question for a user to answer with two outcomes (answers) that can be used to change the logical process flow of the workflow.

Normally in my experience with workflow, processes tend to not rely on a user’s choice to define the flow, but rather on a pre-decided flow and set of rules that can be catered for by automatic decisions (conditional statements), assignment etc. However there may, from time to time, be choices that are simply too fuzzy or complex for system to handle and we can therefore delegate the decision to a human user to make. For example: We may want a purchase requisition to go through an RFQ cycle if a senior manager thinks that the amount “looks” too much, or that he thinks there “may be” preferential treatment of a selected vendor. There is no conditional statements in AX that can cater for these subjective scenarios. So we can simple ask a user using a manual decision.

So here is how we setup a manual decision.

Configuration

1. Create a new workflow configuration of your choice and fill in all the basic details. E.G. Purchase Requisition review.
2. Drag the “Manual decision” control from the “Flow controls” onto your workflow configuration.

Manual_Decision_13. Select the newly created Manual decision and click the properties Icon in ribbon bar.
4. Provide a name for the element so that it makes sense in your configuration.
5. In the “Workitem Subject” field pose a question to the user. E.G. Does this requisition require a Review / RFQ?
6. Provide a description with more details in the “Work item instructions”.
Manual_Decision_2
7. Select the “Outcomes” tab (under Basic settings) and enter the two answers for the user. E.G. “Review Document” and “Do not review”
8. Select the assignment tab and choose who to pose the question to. (beyond the scope of this blog)
9. Click close.
10. On your workflow diagram create the relevant elements such as  requisition review and approval nodes (beyond the scope of this blog)
Manual_Decision_3

11. Connect up your Manual decision
11.1 Connect an incoming flow to your decision e.g. From the start element (or from any other workflow element.
11.2 Connect (from the left of your decision) the Outcome one node to the element that your want to process should the user select what you defined as Outcome one. E.G. In our example Outcome 1 was to review document, so we connect outcome 1 to the review element. Hint: Hover over the decision to see the handle to drag the process flow
11.3 Repeat 11.2 for outcome 2.
Manual_Decision_4

12. Save and close your workflow. (ensure you select the “activate new version” option) when prompted

Test your workflow.

1. Create your document and submit it into workflow.
2. The user you selected in step 8 above should (after workflow has processed for a minute or two) see the following screen with our question and two outputs.

Manual_Decision_5

 

3. The user can now select an option and workflow will be redirected as needed.

 

I hope this is helpful in understanding Manual decisions in Workflow in Dynamics AX.

Happy Daxing

Free: AN INTRODUCTION TO DYNAMICS AX 2012 (Dynamics AX Companion Guides)

2015-07-24_1435Its not really my habit in my blog to re-post or re-blog other users content, but rather to write up my own findings as I explore Dynamics AX. However this post is a bit of a worthy exception.

If you have been in AX for an period of time you have most likely heard of Murray Fife and his very practical Companion guides to Dynamics AX. Right now you can download his “AN INTRODUCTION TO DYNAMICS AX 2012″ for free over here. It is highly useful material for anyone new to AX or even old hats looking for some new easy to use tips and tricks. I’ve been compiling some introductory basic training material for our company and this book will go along way in assisting me with this!

Thank you Murray Fife for this awesome content.

See his original post over here too.

https://www.linkedin.com/pulse/free-prize-download-introduction-dynamics-ax-2012-murray-fife?trk=prof-post

Update: Unfortunately this was only a limited time offer, but I would still encourage you to get hold of this book either from Murray Fife’s website http://www.dynamicsaxcompanions.com/ or from amazon  Here

Beware the “Catch”

Recently while debugging some legacy code I came across the following interesting observation regarding transaction scopes (ttsbegin, ttscommit) and the exception handling surrounding it. While walking the legacy code was observing very strange and unexpected behaviour and after some online investigation i found the following statement from Microsoft:

“When an exception is thrown inside a ttsBeginttsCommit transaction block, no catch statement inside that transaction block can process the exception. Instead, the innermost catch statements that are outside the transaction block are the first catch statements to be tested.”
(
https://msdn.microsoft.com/en-us/library/aa893385.aspx)

In its simplest form this means that for the following code:

Prints the following results:
2015-07-23_0801

Now when it comes to a simple block of code like above one may say “Well that is simply silly coding”, however it becomes harder to anticipate results when that inner try…catch is within a method somewhere deeper inside the call stack (perhaps in standard code somewhere) e.g.

Further more if your inner exception does cleanups or logging of information this will not happen by carelessly adding ttsBegins and ttsCommits around the calling code E.G. “writeErrorLog” will never be called in the following function regardless of what the writer of “innerFunction” does if the writer of the caller adds TTSBEGIN AND COMMIT

I thought I would just paste these observations for anyone who like me has experienced this type of “strange behavior” in the past and didn’t know the exact reason and also as a warning to beware of the “Catch”.

Feel free to share your comments, observations and thoughts.

 

 

 

 

Setup DB Logging in X++ (Updating events)

Setting up AX Database logging via the user interface wizard can at times be a bit of a cumbersome and slow task, especially for tables that are not very common. The job below will simply set database logging for all fields on a specific table. Simply replace “InventSalesSetup” with the table name of your own choosing. As always, test this in a non-production environment to confirm that it performs suits your own needs.

 

Advanced AOT searching

Its always a great opportunity to interact with other AX developers and have the opportunity to learn from each other. A few weeks ago I published a blog post on searching the AX AOT in code for objects with specific properties, after the post went out I got a comment on the post of a much easier way to search the AOT from the frontend, that for some reason I have never really noticed before. So here is a quick way to do an advanced search of the AOT using a real situation I encountered this morning.

Example: Find all privileges in the AOT that have a specific menuitem as an entry point. e.g. “PurchFormLetter_PackingSlip”

1. Open an AOT and select the section of the AOT that you wish to search. Obviously the narrower the search the quicker it will be. I selected Security->Privileges.
2. Right click on the object. Click Find
Find
3. Select