Please shoot me an email with your AX tech questions and I'll see what I can do about answering them. If I answer it, unless you request otherwise, I will use it as a post on this website.
I'm looking for new things to fill my blog up with. I have tons but I want to learn some fun stuff that I may not have in my toolbelt but that would increase my arsenal of stuff I use for clients as well as teaching. I'm an information hog.
I can't guarantee a fast response unless you have talked to me before and I gave you alternate contact information that I check more often.
So... PLEASE ASK ME A QUESTION!!
Thursday, February 10, 2011
Use X++ wildcard (LIKE and NOT LIKE) in X++ select statement
If you want to use wildcards in an AX X++ select statement (*), you will have to use the LIKE command. The following select statement will find all captions in the batch tasks (BatchHistory) table.
For x++ select statements:
select firstOnly batchHistory
where batchHistory.Caption LIKE "*Test*"
For x++ queries:
queryBuildRange.value(*Test*);
Note the LIKE instead of a '==' and the wildcards inside of the quotations. All other combinations of wildcard usage will work here. This is the same functionality as what the users would put in the grid filtering(eg. '*TEST*' in the caption field filter on the batch tasks form).
However, if you want to find all Captions that do not have the word Test in them (NOT LIKE, !LIKE), you will have to modify the above example slightly.
For x++ select statements:
select firstOnly batchHistory
where !(batchHistory.Caption LIKE "*TEST*");
For x++ queries:
queryBuildRange.value(!*Test*);
Note the "!(" and ")". Again, this is the same functionality as what the users would put in the grid filtering(eg. '!*TEST*' in the caption field filter on the batch tasks form).
I hope it helps you out!
For x++ select statements:
select firstOnly batchHistory
where batchHistory.Caption LIKE "*Test*"
For x++ queries:
queryBuildRange.value(*Test*);
Note the LIKE instead of a '==' and the wildcards inside of the quotations. All other combinations of wildcard usage will work here. This is the same functionality as what the users would put in the grid filtering(eg. '*TEST*' in the caption field filter on the batch tasks form).
However, if you want to find all Captions that do not have the word Test in them (NOT LIKE, !LIKE), you will have to modify the above example slightly.
For x++ select statements:
select firstOnly batchHistory
where !(batchHistory.Caption LIKE "*TEST*");
For x++ queries:
queryBuildRange.value(!*Test*);
Note the "!(" and ")". Again, this is the same functionality as what the users would put in the grid filtering(eg. '!*TEST*' in the caption field filter on the batch tasks form).
I hope it helps you out!
Wednesday, February 9, 2011
AX 2009 Batch Job Stuck In Executing
Having a batch job stuck in the Executing status in AX 2009 is a pretty common thing for me to get a call about when a customer is upgrading or doing an implementation.
One of the first things that I check is to make sure that the batch job that is stuck in executing has all tasks set to run on the server. You can check this out by going to Basic -> 'View Tasks' button -> 'Run location' field. If it is set to 'client', that is the issue. The next step is determining why this happened.
Check 1: Check the menu item (probably an Action or Output) and make sure the 'RunOn' property is set to 'Server'. If not, change it.
Check 2: Find the class where the 'runsImpersonated' override is. This value must be true. If it is false, change it.
Check 3: Look inside the code for anything that has a client call in it (hint: WinAPI calls a big culprit). If you find some, find an alternate way to do the task using server side calls instead of client(eg System.IO instead of WinAPI). If you're not sure if a method is running client or not, check the method declaration for the word client. If its there, its client. If nothing is there, use the call Global::isRunningOnServer() which will return a boolean of true if you are server side.
I'm sure you're asking yourself 'Why do I have to do this?!?! Couldn't Microsoft leave it like it was??'. There are a variety of reasons that this change was made and it's awesome. The biggest benefit is better performance because all of the processing is on the server so the client->server calls are eliminated. But maintenance and deployment is also a biggie.
The new AX 2009 batch engine does all of its processing on the server whereas the previous AX 4.0 batch engine ran the code client side. Because of this, batch jobs will get hung up if it makes a call that runs client side (aka WinAPI). AX 4.0 had to have services (at least that was our preferred method) that booted up the AX program and had a user run the program like a user and then kick off the process. Remember the little moving progress boxes? No more in the batch engine. Also NO MORE SERVICE MONITORING APPS RUNNING EXTERNAL TO AX! You can manage the batches from within AX now.
if(this.)
{
warning('your browser is out of date...')
}
One of the first things that I check is to make sure that the batch job that is stuck in executing has all tasks set to run on the server. You can check this out by going to Basic -> 'View Tasks' button -> 'Run location' field. If it is set to 'client', that is the issue. The next step is determining why this happened.
Check 1: Check the menu item (probably an Action or Output) and make sure the 'RunOn' property is set to 'Server'. If not, change it.
Check 2: Find the class where the 'runsImpersonated' override is. This value must be true. If it is false, change it.
Check 3: Look inside the code for anything that has a client call in it (hint: WinAPI calls a big culprit). If you find some, find an alternate way to do the task using server side calls instead of client(eg System.IO instead of WinAPI). If you're not sure if a method is running client or not, check the method declaration for the word client. If its there, its client. If nothing is there, use the call Global::isRunningOnServer() which will return a boolean of true if you are server side.
I'm sure you're asking yourself 'Why do I have to do this?!?! Couldn't Microsoft leave it like it was??'. There are a variety of reasons that this change was made and it's awesome. The biggest benefit is better performance because all of the processing is on the server so the client->server calls are eliminated. But maintenance and deployment is also a biggie.
The new AX 2009 batch engine does all of its processing on the server whereas the previous AX 4.0 batch engine ran the code client side. Because of this, batch jobs will get hung up if it makes a call that runs client side (aka WinAPI). AX 4.0 had to have services (at least that was our preferred method) that booted up the AX program and had a user run the program like a user and then kick off the process. Remember the little moving progress boxes? No more in the batch engine. Also NO MORE SERVICE MONITORING APPS RUNNING EXTERNAL TO AX! You can manage the batches from within AX now.
if(this.)
{
warning('your browser is out of date...')
}
Tuesday, February 8, 2011
AX 2009 Ad Hoc vs Self-Service reporting
What is ad hoc reporting? Click HERE. lol. Enjoy that!
'Ad Hoc' (or self-service) capabilities basically means allowing the users to manipulate or create something on the fly. Self service reporting and Ad Hoc reporting are one and the same.
Some people will argue that there are subtle differences between ad hoc and self service but that is not true. They can be used synonymously. Don't let the BI (Business Intelligence) jive trip you up.
It's pretty common to hear customers stressing the importance of Ad Hoc Reporting or the ability to create Ad Hoc Queries. It's one of the buzz words you'll hear throughout the projects. Why? The information needed for end users change from day to day as businesses grow and new requirements are created. Or requirements exist for information analysis that is not possible at the moment.
Can you blame users for wanting a robust way to get the information they need without the reliance on anyone else? I can't. Who wants to get on the phone with a guy from tech to explain that you want a field added/removed/moved from a report. Or that you need a new report made that doesn't exist and then wait at least 3 months before you ever get one only to find out it is filled with bugs (my reports never have those...).
A vital component of future ERPs will definitely be these abilities and the ease of users to get the information they need.
Microsoft has done a great job in its progression from AX 4.0 to AX 2009 (exporting to excel with a single click, SSRS Reporting, SSAS) to AX 2012 (can't give details yet but lets just say you better get used to SSRS).
I won't get into specifics of what AX's capabilities are but just wanted to make a post about how there are no differences between ad hoc and self service reporting. If you want to know more about ad hoc and BI, check out this site: Reporting & BI in AX: An Overview.
'Ad Hoc' (or self-service) capabilities basically means allowing the users to manipulate or create something on the fly. Self service reporting and Ad Hoc reporting are one and the same.
Some people will argue that there are subtle differences between ad hoc and self service but that is not true. They can be used synonymously. Don't let the BI (Business Intelligence) jive trip you up.
It's pretty common to hear customers stressing the importance of Ad Hoc Reporting or the ability to create Ad Hoc Queries. It's one of the buzz words you'll hear throughout the projects. Why? The information needed for end users change from day to day as businesses grow and new requirements are created. Or requirements exist for information analysis that is not possible at the moment.
Can you blame users for wanting a robust way to get the information they need without the reliance on anyone else? I can't. Who wants to get on the phone with a guy from tech to explain that you want a field added/removed/moved from a report. Or that you need a new report made that doesn't exist and then wait at least 3 months before you ever get one only to find out it is filled with bugs (my reports never have those...).
A vital component of future ERPs will definitely be these abilities and the ease of users to get the information they need.
Microsoft has done a great job in its progression from AX 4.0 to AX 2009 (exporting to excel with a single click, SSRS Reporting, SSAS) to AX 2012 (can't give details yet but lets just say you better get used to SSRS).
I won't get into specifics of what AX's capabilities are but just wanted to make a post about how there are no differences between ad hoc and self service reporting. If you want to know more about ad hoc and BI, check out this site: Reporting & BI in AX: An Overview.
Subscribe to:
Posts (Atom)