New Workflow Types with Feature Pack Release for AX 2012

Well I hope everyone has had a great weekend, your fully rested and ready to have a productive Dynamics week! Recently I wrote about how the feature pack for AX 2012 should be adopted now for all projects. In that post, I highlighted some of the reasons this is critical, including being a stepping stone to AX 2012 R2 set to be released in H1 2013. With that being stated, I wanted to dig deeper into some valid reasons, from a business impact and value add of such a move - beyond what has already been pointed out.



To this end, I wanted to point to the new workflow types that have been added as part of this feature pack release for Microsoft Dynamics AX 2012. There are five new workflow types that are part of this feature pack release, that cover three area's: Advanced Ledger Entry, Project III & Public Sector.

The following is a list of those new workflow types.:

• AdvancedLedgerEntryTemplate - "Use this type to create approval workflows for advance ledger entries" [Configuration Key: AdvancedLedgerEntry ]
• PSAProjInvoiceProposal - "Workflow for handling invoice proposals" [Configuration Key: Project3 ]
• PSAProjQuotationTemplate - "Project quotation workflow template" [Configuration Key: Project3 ]
• PurchAgreementType - "Use this type to create approval workflows for purchase agreements" [Configuration Key: PublicSector ]
• PurchCommitmentTemplate_PSN - "Use this template to create approval workflows for commitment documents" [Configuration Key: PublicSector ]

As you can see Microsoft is for sure committed to the idea that Workflows should be used to modeling business processes. Further you can see past coverage of this topic, that I wrote about, in the past for creating custom workflows here.: Modeling Business Processes with AX 2012 and Workflow - Part III - Enabling Custom Workflows



It is critical that when thinking in terms of implementing AX 2012, and designing the customers usage - to get the most derived value from such an investments, workflow usage and design has to be a top priority. This great feature of AX 2012 will only continue to evolve and truly enable domain specific modeling & language for companies and the verticals they live and work in.

Well that's all for now, check back soon however as there is a lot more coming, including my postmortem on my AXUG BI webinar I'm putting on next Friday. Beyond that, there is a lot of great coverage in general from the entire Ecosystem, which is wonderful to see. Till Next Time!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

Continued talks of Integrating Dynamics AX to the outside world

Recently I posted the following blog entry.:
Integrating Dynamics AX 2009 with the outside world

This was the start of looking at all the different ways you can integrate the current version of Dynamics AX to the outside world.

As I said in that post, I wanted to move forward which each different type, talk about real world examples, and what I have seen fail and work.

A reader posted a comment on that blog entry, asking.:
"... more and more data needs to be shipped to and from Dynamics AX. What options have been more successful for you when implementing ..."
- Nathan

Nathan, you have great point there, and that is why I wanted to start talking more in depth about this topic. You see, like all things there is a lot of different ways to achieve something. The best answer, or correct answer, has a lot of inputs to reach that.

Same as the cloud conversation, common sense and functional ends should drive the means. This is true also for integration, though integration, it terms of pure integration is mostly technical.

Still the functional ends, should be the driving factor. And what do I mean by that, in this case?

Lets look at some examples. If for example, you have desperate, decoupled older systems that need to talk with Dynamics AX. And this 'conversation' or integration needs to happen in an asynchronous manor, with sometimes queue delivery of data and information. Then looking to middleware, like MSMQ might be something that is considered.

Taking the route of MSMQ, though, brings is on set of enabling functions, and limits with size, performance, and timing.

I have seen a good MSMQ integration work before, but I have seen more bad MSMQ integrations developed for integration into Dynamics AX than good actually. And maybe bad and good are wrong terms. Instead of bad, because MSMQ did what it was told to do, it's more the implemnetations driving functional ends did not really call or have to have an asynchronous integration to reach those ends. Only a part of it did, and since a part of it did, the entire thing was feed through that same channel.

That brings me to another point, a lot of the times a single channel for intergation is not always the best option. Sometimes, depedning on the functional ends or nature of a given process, it could be that a system to system intergation needs more than one channel for communication.

So for the truly needed asynchronous integration point, of queue data, MSMQ be used. But for the other integration path that can handle synchronous, event based integration points, .Net Services / Web Services would be the best approach.

Sometimes technology is the limiting factor, and when that is the case, you have to take the best route for the given limit. For example, it could be the only way to integrate with a given older system is through COM objects.

If this is the case, and you wanted to design some kind of workflow driven, 'smart' integration that could handle errors, routing, and failures. Things that come with newer technologies. Then it might make sense to wrap those given COM objects in .Net Workflow based Service. Where the .Net Service is the exposed integration to Dynamics AX, and it wraps the needed COM objects.

To wrap this conversation up, for now, and get directly to Nathan's question. 'What options have been more successful', I personally have seen many of the mentioned options both suceed with high and low degrees of sucess, and fail as well. It all goes back to the functional ends.

I guess it would be better to change the question, just a little bit, to say which one's have I seen fail the least. That, because of the nature of the integration, would be synchronous integration points. Be that Flat file, .Net Services / Web Services, direct calls to COM or .Net assemblies, etc. These are usually very event driven, easier to debug, understand, and don't usually have as many layers of abstraction.

That's also not to say that layers of abstartction are bad. In designs, if done correctly, the right amount of abstraction is a good thing. This is also not to say that asynchronous should not be used. I am not saying that at all. I am just trying to get across that what should be used, should only be used, based on the functional ends. If a functional ends, or technology limiting means extist and drives to an asyncrhonous type of intergation, where MSMQ or some other form of middleware, message delivery system is needed. Then a correct design and implementation of that, will help make that a success.

That's all for now, thanks for the question Nathan, and check back soon everyone. More great post are coming out.

See you then!




"Visit the Dynamics AX Community Page today!"

Dynamics AX, SOA and Oslo on the mind...

Alright, so I have been doing a lot of degrees of seperation lately, or thinking in such terms. The area's of topic, by choice, are Dynamics AX, SOA and Oslo. I started thinking about these 3, two products and one an arch. that is used to bridge systems, interconnecting products.

Then, even as I was typing that, about being products, in turn I realized that Dynamics AX and Oslo are not products really, not anymore, well not anymore for Dynamics AX.

When Dynamics AX was called Axapta, and back before Microsoft bought it, you could consider Axapta a product on the verge of becoming a platform.

With the release of Dynamics AX 4.0, this product grew up and became a real platform for the first time. It integrated and fit, nicely sometimes and not so nicely on others, into the Microsft stack. And why not right?

Microsoft is a platform company, that is what they are. They provide the platform that partners and customers use to provide and create solutions with.

Alright so Dynamics AX and Oslo are platforms, and SOA is an Arch. Well recently, Microsoft hosted their SOA conference. The home page can be found here: Real World SOA: 2009 Microsoft SOA & Business Process Conference

At the conference there was a lot of different topics covered, and I plan on getting into some of the details in a later post (hopefully) about in specific session. For now though I wanted to talk about these two platforms and the one arch. The reason is, in the not to distant future Oslo (along with "Dublin") will be released from Microsoft as live products platforms / services, and they are already in the line up for Microsoft Dynamics AX roadmap.

The reason they are is that Oslo, Dublin and Dynamics AX with the help of SOA will become platforms that work together with the rest of the Microsoft stack, like office, to help deliver to business that make use of the Dynamics AX business platform, create and manage business workflows.

Big deal huh? I mean this is already happenning right with the release of Dynamics AX 2009 and it's use of the .Net 3.5 workflow engine right? Technically the answer is yes. But... (and you knew there was a but) there is a lot of code that goes into these workflows, the designer is a tree down designer, and the flow of these workflows are not very flexible.

Enter WF in .Net 4.0. This will come into play, along with Visio like diagram ability to offer partners and customers to create workflows with greater ease soon, that are more flexible and less code.

A little later, enter Dublin + Oslo (along with the letter "M" [more in a bit about M.]) with WF 4.0 (and beyond) and you have the *desired* goal of creating business process workflows that are managed and created by users, with complex flows and use of logic, with 80%-90% estimated less code than currently exists with workflows in Dynamics AX 2009 and .Net 3.5.

So with all this said, what's the point?

1.) You can create workflows now in Dynamics AX 2009, that will help manage your business processes, out of the box.

2.) In the very near future, this will be improved with .Net 4.0 and WF, along with a new designer for the workflow that will be Visio like. The workflows will be easier to manage and offer more flexibility, with less code.

3.) In the next release of Dynamics AX (based on current road map) Oslo + Dublin, along with the modeling language "M", yes a new language that we will explore here, will be used by normal super users to create, manage and maintain business work flows and processes, without the need of much coding in X++ or C#. (Based on information from Microsoft)


So we have some exciting new things to look at with this. Look for more on this, later this week, as we look back in time at the PDC 2008 that happended last October to talk about this in greater detail and to get some direction on the who, what, when, how... and why of this topic.

Check back soon...






"Visit the Dynamics AX Community Page today!"