Hi All ,
This post focus on Jobs creation in retail from the code. This post will give the idea of how to customize the retail cdx classes for job creation as well as add customize fields to sync the data to the channel database.
After debugging the code from initialize button on Retail
Parameter form I got to know that class RetailCDXSeedData and its child class RetailCDXSeedData_AX63 has major role
in the job creation in AX R3.
As we see in the parent class RetailCDXSeedData-> run() method, we find the following code.
while (subjobEnumerator.moveNext())
{
subjobMethod = subjobEnumerator.current();
seedDataClass.resetParameters();
dc.callObject(subjobMethod, seedDataClass);
if (subStr(subjobMethod,
1, 2)
== 'C_')
{
seedDataClass.createSubJob();
}
else if
(subStr(subjobMethod, 1, 2) == 'A_')
{
seedDataClass.appendFieldMapping();
}
}
Here we can see that parent class look in to the child class
that is in to class RetailCDXSeedData_AX63 for methods whose name stars with
the C_ or with the A_, then it define tables and fields that will be
synchronized.
At this time there no "A_" methods available in AX
R3, so difference between "C_" is not clear. What we can see from the
code is A_ methods might be use to append
the new fields to existing sub-job.
Each of the “C_” methods simply initialize some class
instance variables so they’re all really simple. Each method will generate the
setup required for one sub-job and attach that sub-job to one or more jobs. The
variables that we must set depend on whether it's a sub-job to send data to the
POS or a sub-job to pull data back.
For a send style sub-job, you need to initialize the
following variables
| JobIDContainer | A container of strings with each element defining the distribution job Id that the sub-job should be linked to. Typically this would be a single element container but there is no reason why you cannot link a single sub-job to multiple jobs using this approach. |
| subjobID | A string defining the id of the sub-job to be created/amended. |
| axTableName | The name of the table that will be synchronised by this sub-job. |
| axFieldNames | A container defining the list of fields that the sub-job will synchronise. |
For a sub-job designed to pull data back from the store
database we need to define the same variables as a send sub-job plus the
following additional variables.
| isUpload | A boolean variable that should be set to true. |
| ReplicationCounterFieldName | A string that defines the replication counter field name (typically “REPLICATIONCOUNTERFROMORIGIN”) which should also be included in the axFieldNames container. |
| tempDBTableName | The name of the TempDB temporary table used during synchronisation. |
Here is the example of C_ method for a pull job.
private void C_RetailTransactionAttributeTrans()
{
jobIDContainer = ['0001'];
subjobID = 'RetailTransactionAttributeTrans';
axTableName = tableStr(RetailTransactionAttributeTrans);
axFieldNames = [
fieldStr(RetailTransactionAttributeTrans, Channel),
fieldStr(RetailTransactionAttributeTrans, Name),
fieldStr(RetailTransactionAttributeTrans, ReplicationCounterFromOrigin),
fieldStr(RetailTransactionAttributeTrans, store),
fieldStr(RetailTransactionAttributeTrans, terminal),
fieldStr(RetailTransactionAttributeTrans, TextValue),
fieldStr(RetailTransactionAttributeTrans, transactionId)
];
isUpload = true;
replicationCounterFieldName = 'REPLICATIONCOUNTERFROMORIGIN';
tempDBTableName = 'RetailTransactionAttributeTransT';
}
Let’s assume that I want to add a field to the RetailBarcodeMaskTable table and have that synchronise to the store database. For this I would need to modify the C_RetailBarcodeMaskTable() method as follows.
private void C_RetailBarcodeMaskTable()
{
container myCustomFields;
jobIDContainer = ['1040'];
subjobID = 'RetailBarcodeMaskTable';
axTableName = tableStr(RetailBarcodeMaskTable);
axFieldNames = [
fieldStr(RetailBarcodeMaskTable, Description),
fieldStr(RetailBarcodeMaskTable, Mask),
fieldStr(RetailBarcodeMaskTable, MaskId),
fieldStr(RetailBarcodeMaskTable, Prefix),
fieldStr(RetailBarcodeMaskTable, RecId),
fieldStr(RetailBarcodeMaskTable, Symbology),
fieldStr(RetailBarcodeMaskTable, Type)
];
myCustomFields = [
fieldStr(RetailBarcodeMaskTable, MyCustomField1),
fieldStr(RetailBarcodeMaskTable, MyCustomField2)
];
axFieldNames += myCustomFields;
}
As you can see, rather than directly modify the code that sets the axFieldNames variable I have created my own container variable local to the method and added my fields to that. The local variable is then simply appended to the axFieldNames container so that it contains both the standard and custom fields. This means that, although we will still have to merge code during an upgrade if the standard field list has been changed, it will always be a simple operation to merge in whatever new changes are in the new Microsoft code.
To Add New table :
It should be reasonably obvious from the text above that adding a new table into the synchronisation setup should be a simple matter of creating a new “C_” method a following either the send or pull method pattern appropriately to determine which variables should be set. The framework will automatically see the new method and will execute it along with all of the existing standard methods, creating your new sub-job and attaching it to whichever job you want to attach it to. If you need to define an entirely new job then you should modify the RetailCDXSeedData_AX63.createJob() method, adding a new line of code to create your job.
