Download it from: http://www.microsoft.com/download/en/details.aspx?id=27565

Ok, so you’ve developed your workflow template, enabled your form for workflow, setup a configuration and are ready to give your workflow its first test run. You open your form and the first thing you get is the debugger with an error message: “Error executing code: FormDataSourceObject not initialized” Called from the SysWorkflowFormControls\initControls class.

Error executing code: FormDataSourceObject not initialized

Don’t worry, this is a very quick fix, and you, like I did, may kick yourself for forgetting. Open up your workflow enabled form in the AOT, navigate to Designs, Design, right click, select properties and select a valid data source. e.g.

No data source selected

Data source selected

Go to origin button on workflow history form

Seeing as this is a standard AX form, I don’t think I’m allowed to simply export and provide an XPO on my blog so here are the instructions on how to do it.

1. Open the form WorkflowStatus in the AOT.
2. Create a standard button at the following location on the form Designs -> Design -> Group -> GridGroup -> Button group called DrillDown with the label @SYS88047 in its text property.

Insert Button

3. Right click on the button’s method node, click Over ride method , Clicked.
4. Overwrite the method code with the following.

void clicked()
{
    Common buffer;
    selectableDataArea company = curExt();
    Args args = new Args();
    SysDictTable dictTable;
    FormRun formRun;
    WorkflowTrackingStatusTable trackingStatus;
    ;
    trackingStatus = WorkflowTrackingStatusTable::findByCorrelation(WorkflowTrackingStatusTable.CorrelationId);
    if (trackingStatus.RecId)
    {
        changecompany(trackingStatus.ContextCompanyId)
        {
            dictTable = new SysDictTable(trackingStatus.ContextTableId);
            buffer = dictTable.makeRecord();
            select buffer where buffer.RecId == trackingStatus.ContextRecId;
            if (! buffer)
            {
                 info('You cannot go to the origin of the workflow instance. The record no longer exists or you do not have sufficient access.');
return;
            }
            dictTable.formRef();
            args.lookupRecord(buffer);

            args.name(dictTable.formRef());
            formRun = ClassFactory.formRunClass(args);
            formRun.init();
            formRun.run();
            formRun.detach();
        }
    }
}

If you cannot read the above you can view it in this text file: clickedWF.txt

5. Save the form.
6. You’re done!! Quick and easy.

Disclaimer: Please note that this is really just an code suggestion and that you should test it thoroughly before introducing to any live environment.

I’ve tried something like this

Common buffer;
;
select buffer where buffer.TableId == _tableId && buffer.RecId == _recId;

This however always return an empty buffer regardless of whether or not the record does exist. I eventually managed to retrieve a common record with the following method.

Common buffer;
SysDictTable dictTable;
;
dictTable = new SysDictTable(_tableId); buffer = dictTable.makeRecord(); select buffer where buffer.RecId == _recId;

I’ve needed to do this a couple of times in the past and kept forgetting, so I’m posting it here for myself and who ever else wants to accomplish this. Enjoy!

So if nothing seems to work and you unable to restart your physical server, you can easily force kill the IIS process with the following command in DOS: Taskkill /F /FI “SERVICES eq w3svc”

We are running a batch job that makes use of a 3rd party DLL file. The batch process runs quite ok if we run it manually from the client, however as soon as we try and run it in batch mode it fails with a “CLR Error: cannot create object”.

The reason for this is that the batch server cannot find the DLL file to use. All the recommendations that I found to solve this error involved placing the DLL in the Global Assembly Cache (GAC) on the batch server. I understand that this would be the best way to overcome the error and should normally be the approach. However the DLL we have is not Strongly Named, so we received constant errors when trying to add it to the GAC. Unfortunately the vendor is not shipping a strongly named version of the DLL so a different approach has to be followed.

Where for client side execution of the DLL you need to place the file in C:\Program Files (x86)\Microsoft Dynamics AX\50\Client\Bin if you would like the server to access it, simply place it in C:\Program Files\Microsoft Dynamics AX\50\Server\[AOS name]\Bin on the batch server.

And like magic the batch job works. (Ok i had to restart the batch server AOS as well)

I hope this assists somebody in the near future.

When selecting the workflow component to install, it requested to install prerequisite software “IIS” and “.NET 2.0″ However when clicking yes, it failed to install IIS and wouldnt allow me to continue. I managed to resolve the error with fixes.

1. Ensured that no other Server Role Manager sessions were running/installing roles. (I was receiving the following error message in the IisInstall log file: Error (Id=0) Roles or features are currently being added or removed on this computer. Only one user can add or remove roles or features at a time to prevent conflicting configurations.” )
2. I was also received the message “Error (Id=0) ArgumentNotValid: Feature not valid: ‘NET-XPS-Viewer’. The name of the feature was not found.” which we managed to resolve by modifying the line <Feature Id=”NET-XPS-Viewer” /> to <Feature Id=”XPS-Viewer” /> in the ServerManagerCmdInputIIS.XML file in the support folder of you AX2009 setup folder.

I hope this helps somebody struggling with this issue.
Happy Daxing
Jonathan.

E..G:
Old: http://10.0.0.1:80/MicrosoftDynamicsAXWorkflow50
New: http://CLIENTAOS_SERVER:80/MicrosoftDynamicsAXWorkflow50

I hope this helps somebody.

I’ve just started delving into the goodness of AX2012 workflow and will hopefully over the coming days and weeks be posting some of the more interesting aspects and new aspects of AX 2012.

When opening the AOT in AX2012 and looking into the workflow node one notices a number of interesting changes.

1. Workflow Templates are no longer this in AX2012, rather they are called Workflow Types.
2. There is a new node named Automated tasks
3. There is a new node called “Providers”.

Todays focus is specifically on this last node, the providers node. In AX2012 is appears that Microsoft has decided to do away with requiring developers to lock into a specific provider for each of their tasks or approvals. Rather the provider can now dictate what workflow templates (workflow types) it supports. In other words I believe all the tasks or approvals that are part of a workflow type can now make use of any of the providers that have been made available to the Workflow Type. So for example a purchase requisition completion task could at configuration time, allow the administrator to select either a user group (using the WorkflowUserGroupParticipantProvider) or some form of role using the WorkflowRoleParticipant provider.

AX 2012 Approval Properties

AX 2009 Approval Properties

Providers can be setup to either be accessible to all Workflow Types or only a specific set of Workflow Types. These changes seem to be applicable to all types of providers including DueDate providers, participant Providers, hierarchy providers and the new type “Queue” Providers.

The Participant provider classes themselves (the provider nodes just link to these) seem to be similar to their Ax2009 counter-parts. Microsoft has expanded their list of out the box providers quite significantly and now deal with with a number of Dimension Driver expenditure providers.

My initial thoughts so far is that this improvement will significantly improve configuration time customisations and provide a greater level flexibility without having to get developers involved.