Quick Post: Catching ClrErrors in X++

I wanted to do a quick post actually with some X++ code. I know this exists already on the web somewhere, but it's always handy code when working with .Net Assemblies, WCF Services, etc.

So the following is a great way to catch and see what all is going on with any .Net error being thrown.:


System.Execption ex;
str ClrErrCatch;
;

try
{

// Do some code work here...

}
catch (Exception::ClrError)
{

ex = ClrInterop::getLastException();

if (ex != null)
{
ClrErrCatch = ex.get_Message();
ClrErrCatch += ex.get_StackTrace();
ex = ex.get_InnerException();
if (ex != null)
{
ClrErrCatch += ex.ToString();
}
}

error(ClrErrCatch);

}



Now the above assumes your making correct use of CAS, or Code Access Security, with an InterOpPermission.Assert() going on.

The point with this post is to give a good template for working with Clr errors. This includes anytime you reference any of the System.* .Net Assemblies, your own custom .Net assemblies, and also Service references of any type, be that Web or WCF.

Check back soon, as more good post are coming on. Also this can be included in our WCF series of post going on as well.




"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!"

Integrating Dynamics AX 2009 with the outside world

One topic I wanted to start really spending some time on, in the next few months is Integration options for Dynamics AX 2009.

There are several ways for doing this, and what I want to take and look at each. Go over some pro's and con's, and when should the different approaches be used.

So the following is a list of ways you can integrate Dynamics AX 2009 with the rest of the world.:

Outbound Integration

• Calling a COM Object - Server and Client Context


• Calling a .Net Assembly - Server and Client Context


• Calling a Web Service through a .Net Wrapper


• Calling a Web Service or WCF Service through Service Reference in AOT


• Out of the Box AIF Outbound End Points


• Custom AIF End Points - (MSMQ, File Transfer, Web Service, FTP)


• AIF End Points for BizTalk - BizTalk then offers a wide range of options once inside it's scope


• Your own custom or Third party developed framework that lives inside Dynamics AX 2009

So the above list can be sliced upon into sections of itself. Like Server or Client context, AIF, Web Services, etc.

The approach I want to take is now take the above list, on my next post, and talk about the pro's and con's of each type. After that, take the same list, and talk about when each of the types would be used, and what would be driven factors to use those.

Hopefully by the time we cover these options a solid understanding of what all exist for integration Dynamics AX 2009 out to the rest of the Microsoft stack, and world can be understood and we can move forward with inbound integrations.

I also plan on giving examples of some of these. Like the Reporting Options in Dynamics AX 2009, the integration options are many. And there is specific factors that drive you to choose different paths.

That's all for now, check back as more to come. August is Lean month, so another post tomorrow on the LCE, and interviews are coming up. See you then!




"Visit the Dynamics AX Community Page today!"

Microsoft Interoperability Labs

Do you find yourself in an enterprise or environment where it’s not just 100% Microsoft platform, but a host of different databases, applications, programming languages, frameworks, etc.?

Also your staring down this new road of the 'Cloud', and everything ‘Must work on any device from any level, being that cloud, on site, mobile or at home’ And wonder how that can be the case when there are so many different languages, platforms, etc?

Check this out: Microsoft Interoperability Labs

This is the Microsoft Interop Bridge Labs page, that goes into examples. Just check some of these: Azure SDK for Java - .Net services, PHP for Azure, etc. etc.



These are some of the bridges, and technology interops that can be looked into and developed with. Deployed for just such ‘how’s’ were you are faced with an enterprise that does not have a common platform. Where technology need to bridge systems that span different programming concepts, langauges and even approachs.

There is plenty to look into on that Lab site. The thing that I want you to think about here, is the possibilities or support that exist for when you have, say a Dynamics AX instance that needs to connect to a Java custom package, and there is a PHP driven ECommerce site. This can be bridged, and exist, and this Microsoft lab is there to help in such needs arise.

It worth the time to check out, and keep an eye on from time to time, as you never know when such SDK's, libraries and bridge technologies can be used to help you out.

Well that's all for now, check back soon!




"Visit the Dynamics AX Community Page today!"

Whitepaper: Consuming Web Services in Microsoft Dynamics AX 2009

The following link is a Whitepaper from Microsoft, on consuming web services in Dynamics AX 2009: Consuming Web Services in Microsoft Dynamics AX 2009 White Paper

This whitepaper was published just a few days ago, 5/5/2009. This white paper covers the basics of working with the AOT objects, creating a service reference from within the AOT, and creating the class and correct X++ syntax usage for making use of the new service reference.

Web Services, and WCF Serverices are becoming more and more the way to integrate. In fact they should be the way most things are integrated these days, espically new integrations into Dynamics AX 2009 and beyond.

Just check out this post I did, when I talked to Lachlan Cash from Microsoft. You will see SOA and WCF Services will be of heavy focus in the next release of AX, and can already be made use of today in Dynamics AX 2009.:

- Microsoft's strategy and vision for Dynamics AX and SOA
- WCF: The Enterprise Service Bus for Dynamics AX and the rest of the Microsoft Stack

This white paper is a simple, step by step guide for pratical use of Web Services inside Dynamics AX 2009, for working with them and consuming them. It is a must for all developers, technical consultants to understand this now and moving forward.

Check back soon, as more great post are coming your way! See you then!




"Visit the Dynamics AX Community Page today!"

Dynamics AX on your BlackBerry

Recently I saw a post on ZDNet talking about how SAP has this big plan in the works for developing their applications to run native on a BlackBerry device. I am sure we will see this in 2012 or 2013, unless it gets delayed too.

In the meantime, you can already run Dynamics AX enabled BlackBerry Applications. Since Dynamics AX is flexible, and you can easily extend / expose Dynamics AX logic with Web Services (SOA) then you can simply create custom tailored to you, BlackBerry Front in applications that consume and make use of those Dynamics AX web services based on your buiness needs.

Want CRM? Sales Quoting? Customer Infomartion lookup? Create a Sales Order? Lookup inventory? Fill out Project Timesheets?



All possible, now through the power of Dynamics AX and .Net with Visual Studio 2005 or 2008. And there is no waiting for this at all. We can do this today! So if your interested in having your own tailored BlackBerry Applications for Dynamics AX, visit Sunrise Technologies, Inc. Web Site today: Sunrise Technologies, Inc Web Site And use the contact form to ask about BlackBerry development for Dynamics AX.



I would like to note, that you can also use the BlackBerry JDE (Jave Development Environment) to do development as well, that will work with Dynamics AX created Web Services.

Check back soon!



"Visit the Dynamics AX Community Page today!"

DAXGuy: Infopath, Web Services & AX Integration

Well DAXGuy over at daxguy.blogspot.com wrote a post recently that really showed how to take infopath and make use of it in an integrated with Web Services solution for Dynamics AX.

The link to that post can be found here: Direct Link

He really did a good job, and gives the entire example project up for download. I recommend you check it out, to really get a feeling for the flow of how such things can work, right now in the current release of Dynamics AX 4.0, plus DAX 2009.

I wrote about similar topics myself, and a list of them follows:

• Snap, Crackle, InfoPath?


• InfoPath 2007, Dynamics AX, and some crackers!

Thanks DAXGuy for that great post. And check back soon here, as I have some great new posts coming soon!

MSDW: Users Overcoming Skepticism About Microsoft Dynamics AX, Seeking Ever More Sophisticated Solutions

Well over at MSDynamicsWorld.com a great post was recently add that was focused on the leader of the AXUG talking about how Dynamics AX is being asked to do more and more complicated things by it's users.

This is a big shift, and honestly I can say this is correct. It seems that the last several projects I have worked on personally, there has been Web Services involved, and several integrations and advanced business rules.

Anyway this is a great article, and really is talking about the reality we all face in the different implementations of Dynamics AX. We have a platform that is flexible in Dynamics AX, and therefore have the ability to really push it to do more new and complicated things.

Well check back soon!

Mobile Solutions for Dynamics AX - A deeper look

link: PartnerSource Link to Download Dynamics Mobile Platform

One of the most interesting things that has been released around the Dynamics AX platform lately was the Mobile Solutions stack. This offering has an example Sales application as well as the development platform tools for creating your own solutions. So in order to start working with this we need to better understand it. With that said I started looking closely at exactly what makes up this platform.

Basically there are a few parts, for the most the part this platform is:

- Visual Studio 2005, .Net 2.0 Compact Framework add on project type
- Exmaple projects that show how these types of projects can be used
- Server side platform components that make use of Web Services and .Net 2.0, as well as the .Net BC
- Example web service extensions for your use
- A Dynamics AX instance

So with this you are actually developing a windows mobile 5.0 application, that makes use of the .Net compact framework. There is a new set of Assemblies that is made use of within the client peice. You also have, as part of your solution, calls to the web services from the server side of this platform that enable and expose X++ business logic.

So you could create connected and disconnected state mobile windows applications with this paltform, and make use of the platforms exposed X++ objects via the server side web services that are deployed. This is Targeted for the .Net 2.0 Compact framework, which in turn targets Windows Mobile 5.0 devices.

From here I plan on diving deeper into this platform and creating an example solution. The one given though really gives you a good idea, and the samples provided.

Check back soon as I continue to post!

Find a job at: www.DynamicsAXJobs.com

TechEd 2007 InfoPath demo bits

Alright,

This is my last day of vacation. It's been fun, and so I am trying to get back into the grove of things. Well in that I have been doing so reading around the web, catching up on things in the community and all. I came across the Microsoft X++ teams blog. Not many post yet, but you can tell there is going to be some really content here. you can check this: X++ Team Blog

In reading over this, which some nice post already, I came across something I wanted to post about, which was using InfoPath 2007 to interact with Dynamics AX with, as a front end forms processor / client. Now the direction taking here is a 'Connected State' direction, which mine was going to be more of an Asychronous state of interaction. Still you could easily take the example provided here: Example from the X++ Team And turn that it to something that works in a disconnected fashion. Think of a salesman traveling around, generating Sales Quotes that needed to be submitted, when connected, to the CRM module in Dynamics AX.

Anyway I wanted to post this link to the X++ team blog, and that article as well for something that everyone should keep an eye on for good information. Well check back as I start my regular postings again. I am about to wrap up my focus on the .Net and Dynamics AX [I will come back later to this] and move to advanced SQL Server tunning and performance enhancements with Dynamics AX. Check back soon!

Find a job at: www.DynamicsAXJobs.com

.Net BC Custom App, Part II

Well now that we talked a little bit about theroy / design behind the custom ASP.Net Application, lets talk about more on the design. In my thoughts, you always want to be absrtact. Meaning the layers that seperate and operate should be as much independant as they can.

Some rules of thumb here for me:

(1) All business logic lives in X++. This is Very important. Doing this keeps the AOS as the central point for performing all Business Logic on Dynamics AX related data and objects.

(2) All use of .Net BC code should be contained within a Web Service or Web Services. This is a very important layer of abstraction. This moves your solution into the JBOWS / SOA arena, where it needs to be anyway. This allows for multiple interfaces, into the same access logic. Meaning, though we are developing and custom ASP.Net application front end, we could easily create a Mobile Windows, regular windows, Java, etc. etc. number of front end or middleware interfaces into this same Web Service(s).

Now there can be other obvious and not so obvious rules of thumb that would apply, depending on the nature and design of the application. Like user size for example. Maybe your custom app will be used by a lot of concurrent users? So possible considerations for pooling, Session variables, connection pooling, as well as designing your application to work well in a web farm. Where multiple servers make up a single virtual server. All of these things must be considered in the design of your appliocation. For now though can be after thoughts that you decide when prompted for such needs.

So here we have our base design: (a) All business logic lives in X++, (b) All access to the business logic will be contained with web services.

This means you needs at least 1 instance of Dynamics AX, 1 AOS, and 1 IIS box. Preferred these be different boxes of course, but in development / test can be the same.

Alright well check back tomorrow as we continue our dive into our custom ASP.Net application!

Find a job at: www.DynamicsAXJobs.com

Microsoft Dynamics Real World SOA White paper

[Must have PartnerSource access]

Well I came across the following white paper while looking for information on PartnerSource. Basically this firms up all the things I have been talking about for SOA, Enterprise 2.0, and Dynamics AX, etc. Here is the intro to the white paper:

"Business need to connect processes, people, and information both within the organization and across organizational boundaries. Service-Oriented Architecture (SOA) is an emerging architectural style that helps meet these demands. Microsoft Dynamics has made investments in Web services and other SOA technologies across our product lines to help customers take a “Real-World” approach to SOA. Real-World SOA is about taking a pragmatic approach to systems integration where time-to-value is much more immediate. This paper walks you through the tools and technologies that enable service orientation. Check out the success stories of our customers who have taken on Real-World SOA projects to support their business vision.
"

And here is the Link:
Link to Microsoft Dynamics SOA White Paper

It is a great read, with a Lot of nice resource links, case studies, and a great road map for what and why in the Dynamics ecosystem for SOA. This is something that everyone should be thinking about and in the process of developing for, planning for, and deeply understanding.

The key... Web Services, and this will be the underlying delivery method of the next generation business applications from Microsoft. Understand it now, master the future later!

Check back soon!

Find a job at: www.DynamicsAXJobs.com