SpotLight: Developing Content Apps for Excel 2013 & AX 2012 (Part I)

I hope everyone is having a great week thus far! I wanted to continue my spotlight series this morning on Developing Apps for Office 2013. Earlier this week, I started this spotlight with a focus around the developer training videos that are currently released around this topic. You can find the link to that post here.: Spotlight: Apps for Office 2013 - future value add for Microsoft Dynamics AX Customers



For me, as I stated in the first post, this is going to be a place where a lot of value added solutions will start to form for Microsoft Dynamics AX. Being that Office will continue to be the UX of choice for many processes for AX 2012 instances and use cases. We see this already with items like Budgeting in AX 2012, as well as the development and use of the Office Add-in.

Because of this fact, I wanted to start a series around developing office apps that interact and work with Microsoft Dynamics AX 2012, as well as the cloud. The idea, at first is a focus around how such Office apps can communicate with AX. In order to understand this we need to get a lay of the land, for the development approach and model for such apps.





With that in mind, my first focus was the type of apps that can be developed for Excel 2013. This is why I highlight the above, 4. Develop Content apps for Office 2013 with Visual Studio 2011(demo).

There is a couple of points to make right away, in that first off it's now Visual Studio 2012 RC. These videos were made with beta versions of both Office 15, now known as Office 2013, as well as Visual Studio 2011 beta, now known as Visual Studio 2012 RC. Further Office Apps, in these video's, specifically on the project types were called project Agave.

With these semantics understood, in watching this video and some of the others that build up to this point, it's clear that the types of technologies that will be used for developing such apps are.:

• HTML / HTML5
• CSS 3.0+
• JavsScript

This really should not be much of a surprise, seeing as how these targeted apps are meant to work with OnPrim versions of Office, as well as being easily ported to cloud based versions of Office. This fits into the published model Microsoft has for software development in their new world. That being of either XAML + C# or HTML5 + CSS + JavaScript.



The video is a nice Hello World, for content apps for Office 2013. Which I will further point out, at this time only Excel 2013 can be targeted for content apps. Further there are a few different types of app templates that you can target, and in due time we will get to those.

Having this knowledge, and understanding the next step is connecting AX 2012 to a content app for Excel 2013. Being the focus is around HTML/CSS+JavaScript this means that we need to consume services from AX via REST, or RESTful service consumption. In doing so, then we can target specific content apps, that add value to Microsoft Dynamics AX customers.

That sets us up for the next part in this series, consuming Microsoft Dynamics AX 2012 services via REST from within a content app for Office 2013. Before I close out for today's post, and the start of this series, I want to point to you one last resource on this topic. The following has a host of examples already for this focus, and something that I myself will try and reference as we continue down this path. Further, I will take the example that we create during this series and make sure to add to the following.: Apps for Office and SharePoint Samples

Well that's all for this post, I hope your as excited about the value added proposition of such app possibilities as I am. It's a brave new, app focused world - Office and Microsoft Dynamics are apart of that model. Till Next Time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

Consuming Service References in Dynamics AX 2009

As mentioned in the following blog post.:
Continued talks of Integrating Dynamics AX to the outside world

I plan on going through some of the integration options that exists with Dynamics AX 2009, and getting into some real examples of this. In order to dive right into this, lets look at Dynamics AX 2009 consuming service references.



Service references are new with Dynamics AX 2009, and map directly to service references that one would see in Visual Studio 2008.

This makes use of .Net 3.5 framework, through creating .Net 3.5 code for the given supplied Service WSDL, that acts as a consuming proxy. This is registered in the AOT, and can be accessed through the supplied .Net namespace from where the given service reference was created.



This can be a given web service, or a Microsoft WCF service adapter / end point. That means that all of what comes with the .Net 3.5 framework with WCF and WWF can be made use of with such integration points.

One of the given main examples that has been used to showcase this is hitting the Live API (I guess bing now!) for searching through it's publish service.

This is great to show case a technical ability of this, but what about functional wise?

Well such an integration point, of it self, is syncrhonous. Now the integration point can lead into a WCF service, that is hosting a WF Workflow, which drives through several different points, including asyncrhonous processes with MSMQ, etc. However the integration itself is synchronous because it expects a return on a given call out.

This means that typical integration for this would be to other System of Record applications or solutions, web services for feeding data from and consuming, external calculations like shipping, tax, etc.

What's great about this integration, is that in X++, the given .Net namespace is used with a preceeding dot (.) to get access to the given service, and any methods it might offer.

One thing I want to point out about that .Net namespace, if for example you have say three web services you want living in the same parent namespace. Well you need to make sure to do something as the following for that namespace.:


ParentNameSpace.ChildService1
ParentNameSpace.ChildService2
ParentNameSpace.ChildService3

You do this for each of the three services you want to live under a single parent namespace. So you would have registered 3 different AOT service references, and in the .Net namespace provided a structure as you see above.

Now when in X++, you reference ParentNameSpace. The three child services will be listed under this single parent Namespace. There will also be three .Net 3.5 Proxy Clients created, on the AOS, under the documents and settings of the given user id that is running the AOS service. They will be named as well.: ParentNameSpace.ChildService1.dll, "2.dll, "3.dll.

That is a good point to keep in mind, espcially for doing larger integrations and so forth.

These work great once setup, and there are some limits though. The following gives you a good idea of those limits, like data conversions, etc.

AIF Services and Primitive Data Type Conversions for XML and .NET Framework

Take a look at the chart for idea of the conversion of data types. Another good resource, is the 'How to: Consume a Web Service from X++'

One other thing I want to point out is that the service reference does not have a great management form for say, changing the WSDL URL or service name. The best approach I have found for doing this, and for deploying to other instances has been to take and export the Service Reference, and change the WSDL URL, and import into your instance of another instance and regenerate the service.

Sometimes you might run into file locking issues, if the service already existed. If this is the came, you will need to (a) take and stop the AOS (I know a pain), (b) delete the actual .Net file that AX is complaining is locked, (c) restart the AOS, (d) regenerate the service reference.

Doing this will allow for your updated WSDL URL, etc. to be read and made use of.

Thats all for now, and check back soon as more to come. August is wrapping up today, and that was delcared as Lean month. However I have some more great Lean based posted to wrap that Lean month up with.

See you next time!




"Visit the Dynamics AX Community Page today!"