‘Go to Origin’ Button for Workflow History Form

18 11 2011

For workflow administrators out there, you have no doubt found the need to jump from the workflow history form (Basic -> Periodic -> Workflow History) to the original document that the workflow relates to. Especially for debugging errors. So today’s post provides you with just that… A “Go to origin” button for your workflow history form.

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

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.





DLLs used in Batch processes

13 10 2011

I know this doesn’t have a lot to do with workflow in specific, but I struggled through this issue for a while without finding any other results on the net, so I’m posting it just in case somebody else struggles with the same issue.

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.





Installing Pre-requisite software for Workflow error

5 10 2011

I’ve just been installing Workflow on a client site running Windows Server 2008 R2 and came across a strange error.

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.

 





Business Connector code refresh

15 04 2011

While developing business connector applications you may come across issues where you code changes in AX do not seem to be taking effect or the caching is taking too long to refresh. I’ve tried restarting the AOS, restarting IIS, restarting Application pools even restarting the entire server and nothing seemed to have helped. However, an easy way to ensure that your changes are always available to the business connector code is to add the following line at the beginning of your .NET code, after loggin in, but before executing your custom code:
DynAx.CallStaticClassMethod(“SysFlushAOD”, “doFlush”);

(where DynAx is a logged in instance of Microsoft.Dynamics.BusinessConnectorNet.Axapta)

I hope that helps someone.





Workflow iPhone Application

8 11 2010

Hi all.

Today’s post is hopefully going to be a little different from all the normal posts that I have here at workflowax. I am very excited to post a short demo of some R&D I have been doing for workflow in AX. It all started when I first got an iPhone about a year ago now and was blown away by both the simplicity of the interface and the amazing smoothness of use (much credit to the capacitive touch screen). The iPhone really got my mind thinking about how I could apply this to the area of ERP, AX and workflow in specific. So recently I got exploring how to do development on iphones and as a proof of concept decided to create a workflow approver for Dynamics AX 2009.

The basic idea is for users to be able to have an email like list of all current workitems posted for their attention. They should then have all the necessary information to make an informed decision about what action to take and then perform the necessary action. All of this should be able to function off the current workflow framework, configurations etc… provided in Dynamics AX without any modifications.

The result: an amazingly simple and easy to use mobile workflow approver. Here’s a short screen cast of how the application functions. (i’ve used the iPhone emulator on mac to make the screencast easier)

As always please post your thoughts or comments below!

Happy Daxing.

Update: some screenshots of the application:

Workflow History

 





Workflow Wishlist #2 – onDelegateEvent

5 10 2010

Wish:
The second item on my wishlist for Dynamics AX workflow is to have an “onDelegateEventHandler” option available for tasks and approvals. I must admit that this would most probably not be a very widely used function within AX workflow, but here is why I would like to have one.

Given the way that workflow manages the assignment of workitems, there is no way of determining when and to whom tasks are assigned to people, in order to perform some type of custom action like updating an external system or table. Even making use of custom ParticipantProviders, one does not have a guarantee that it will end up at the person that your provider class is returning, due to delegation settings.

Thus an onDelegate event handler would be very useful. Unfortunately workflow does not have any eventhandlers for individual workitems, rather just set on tasks, so this may be difficult to accomplish.

My workaround:
It is relatively easy to tap into the WorkflowTrackingTable’s (Table) saveTracking Method and kick off some custom action using the record ‘trackingTable’. The trackingTable record contains a useful field  called TrackingType (enum WorkflowTrackingType) which can provide you with more informations as to what has just occurred. E.g. WorkflowTrackingType::Delegate, WorkflowTrackingType::EscalationPath, WorkflowTrackingType::Creation. Using this you can then perform whatever action you would like to do e.g.

if (trackingTable.TrackingContext == WorkflowTrackingContext::WorkItem)
{
  if (trackingTable.TrackingType == WorkflowTrackingType::Creation)
  {
        doAction(trackingTable.User); //this is the user to whom the workitem has finally been assigned 
  }
  else if ((trackinTable.TrackingType == WorkflowTrackingType::Delegation) || (trackingTable.TrackingType == WorkflowTrackingType::EscalationPath))
  {
       doAction(trackingTable.ToUser); //to whom the workitem is now assigned (delegated/escalated)
  }
}
N.B. Be warned, you are modifying system classes so be careful when you are installing new hotfixes or upgrading.
Happy Daxing
Comments Suggestions?




Workflow Wishlist #3

4 10 2010

The item sitting at number 3 of my workflow wishlist is to have the canSubmitToWorkflow logic, that currently resides as a method on your workflow enabled forms, sit within workflow configurations or within a class linked to your workflow template. It seems strange to me that almost all the logic and complexity of the workflow sits in nicely packaged/distinct bundles  i.e. templates and configurations, except for this one method. I would ideally like to be able to install a new template at a client site and without modifying the form, already have my canSubmit logic active.

Workflow does provide activation conditions per configuration, but my success using these has been fairly limited.

My workaround:
I have the habit of creating a static canSubmit method on all my WorkflowActionManager classes  (i.e. per template) which I call from the canSubmitToWorkflow method on the form, this way it keeps the code fairly separate. The drawback is still that i cannot have different logic being performed if I have multiple configurations setup.

Please post any comments as to whether you have experienced similar issues or if you agree/disagree with me in this wish.

Happy daxing.

 

Workflow Wishlist:







%d bloggers like this: