Dynamics AX - Retail Scheduler Gotcha

On a recent project, I ran into a bit of a "gotcha" today around data replication to the Retail POS in Dynamics Ax 2012 R2.  We had created our own schema in order to transfer customized table data to the POS, however, the data would never be written, no matter what we tried.  Before I get to the solution, fist some background on the new Retail Channel Schema in R2.

In R2, Microsoft has moved away from a single schema mentality when synchronizing data to the POS.  It is now utilizing a more flexible multi-schema model.  One of the advantages of this model is to allow AX 2012 R2 to seamlessly communicate with both old and new POS versions without issue.  It does this by defining a schema for each version of the POS.  Out of the box, it looks something like this:


Notice there are schemas defined for most version of Dynamics AX (this model doesn't support the POS pre-2009).  This will allow the Retail Scheduler to synchronize data between AX 2012 R2 and AX 2009 POS for example.  The possibilities for using this framework to synchronize data between AX and 3rd party databases are there as well, but that is an entirely different blog post.

As a best practice, it is generally a good idea to take a copy of existing functionality before modifying it for your particular customization, so I do that here.  Through simple X++ scripts, I copied the RetailConnChannelSchema, RetailConnLocationDesignTable, and RetailConnLocationDesignTableField to a new Schema, called "My Schema".  This can also be done by using the UI to create a new schema and using the Read Schema function, pointing to a non-customized "vanilla" store database.


Once a new schema is in place, in order to utilize it, you must set the Distribution location(s) to point to the new schema, as seen below:


We must also update the subjob(s) that rely on the new schema to the new schema.


Now, here is where our "gotcha" rears it's ugly head.  With this configuration alone, if we run the Job that contains this subjob (in this example, N-1000), AX will appear to have run the scheduler without issue, however no information is sent to either the Head office / Message databases, or the store database itself.



After several hours of head scratching, and some code walking, it turns out that if the Distribution Location schema is not the same as the Job schema, the job is completely skipped for that distribution location.  That is to say that in our current example, even though the schema definition is the exact same (only the name changed), AX still treats it as an entirely different schema and skips the job.

Of course, the solution is simple, setting the Job Schema to "My Schema" resolved the issue, and data flowed freely once again.




Comments

Post a Comment

Popular posts from this blog

SQL Reporting Services - Viewer broken in Non-IE Browsers: FIX

Image
Download Source SSRS Browser Fix Installer A while back I was tasked with getting SQL Reporting Services reports rendering in MVC while deployed on the Cloud with Windows Azure, and the reports must render in IE, Firefox and Safari.  The scenario is somewhat similar to trying to ride a bicycle backwards while chewing bubble gum and reciting the last 18 pages of the 2nd volume of War and Peace... in Russian.  I was eventually able to complete the task, though it was not without much hair pulling and profanity.  That solution involved using local reports, an embedded Report Viewer control, and a custom state manager (I may blog about that later if there is any interest). Fast forward to my current project, and Lo And Behold there is a requirement for a cross browser reporting solution using SSRS (though thankfully this time sans Azure).  The difference here is we are able to use the SSRS Reporting Server's Report Viewer as opposed to embedding our own.  However, the same mons
Read more

Dynamics AX 2012 - Visual Studio Team Services Custom Work Item Fields Break Version Control (Error TF237121)

Image
W e've been using Visual Studio Team Services  (VSO) on several projects as or project management and version control solutions for Dynamics AX successfully for several years.  Recently though, AX occasionally presents us with one of these gems when logging into the client: "TF237121: Cannot complete the operation. An unexpected error occurred." and "Failed to update metadata cache. (Object Model)". You may have seen this error before.  Generally, from my experience, this coincides with an update that Microsoft has pushed to VSO. The fix is generally quite simple:  Navigate to C:\Users\[Your User]\AppData\Local\Microsoft\Team Foundation\3.0\Cache and delete all the files in that directory.  You may see several versions; 3.0 is the version AX 2012 R3 uses. Upon clearing the cache and restarting the AX client, the issue goes away and you can happily version control again. However, a few days ago, this fix stopped working for us.  No matter how much I
Read more

Dynamics AX SysFileDeployment Framework - Deploy files automatically (using resources) to the client on login

Image
S ometimes when creating a customization in AX, external files are required to make things happen.  External graphics files, XML or even DLL's may be required by the AX client. For example, a recent customization for my company required a control in AX to drag-select areas of a PDF document, so the user could tell the system where relevant information is located on the document.  AX is far too limited to satisfy this requirement with native UI controls, so I created a .NET managed user control to complete the task.  This control (DLL file) is required to be installed on each client before the form that uses it can be loaded. Herein lies the problem. If your company has only one or two clients connecting to the AOS server, you may be able to just install these missing components manually.  However, when you have hundreds of clients connecting to your server, this quickly becomes a maintenance nightmare of ensuring clients are up to date. The SysFileDeployment framework in AX
Read more