The presentation from Convergence 2007 gave me my first real look at Dynamics NAV 5.1. Following on from my previous post on the Role-tailored User Experience, here are some details on the use of Reporting Services and exposing NAV logic as Web Services.
Reports
Reports in Dynamics NAV 5.1 utilise Microsoft SQL Server Reporting Services. This, we are told, allows:
- Richer visual effects
- Interactive reports
- Export to Excel, PDF on all reports
The transformation tool will (hopefully) create the report for you but you may need to translate some of the code by hand. You will then have the option of adding in your own SSRS specific elements such as interactive elements, dynamic sorting and graphs.
The Development environment in the demonstration still resides in the Dynamics NAV "classic" client but hopefully this will be sorted out before the release (they certainly have plenty of time.)
I am guessing the report dialogue box is going to get a face-lift as the version I saw did not look that great. First of all you get a filtering dialogue box which looks like the Filter pane on the List Place and when you accept the filter, you get a sorting dialogue. I am guessing that if a request form was used, this would have popped up somewhere as well.
Jesper opens the report for editing in the normal way and then, from the Tools menu, selects an option to Transform the Layout (there is another option to Transform the Request Form.) Selecting this option opens a Microsoft Visual Studio window with a Report.rdlc in design mode. I have been using Reporting Services for a good number of years but I wasn't familiar with this rdlc file extension. It turns out that Microsoft added the capability to host reporting services reports in .NET applications using client report definition supported in .NET 2.0. I don't know much about this but you can find out more on msdn.
This little part of the demo has answered the question for me as to how the team are intending to use Reporting Services within the Dynamics NAV application and I think they are being very clever. By using this approach they are giving the users some of the power of reporting services but still keeping control of the reports within the application. This does mean that you will still need a NAV license to view the reports but I am guessing they will make a MOSS-based report viewer.
In addition to the .rdlc file there is a .xsd file (not sure of the purpose of this but it could be a definition of the dataset.) The report has Website Data Source with a Dataset and ResultSet. The information in the report is based on the dataset that is already defined in the report (no hacking SQL here.) It looks like the dataset contains all of the fields from all of the tables within scope plus the values of variables in a single dataset.
Jesper closes Visual studio and returns to NAV and the designer detects that the rdlc file has been changed and asks if you want to load it against the report definition. The whole process certainly seemed quite painless. I would be interested to see if you can use custom assemblies in reports (such as a barcode renderer or other custom graphics renderer.) From the article on msdn it appears that this is supported in rdlc but I am not sure if the NAV application will allow it.
I have to say I found the reports section very impressive and from what I have read, it will be possible to schedule the reports and distribute them using the NAV application so the lack of Report Server hosting is not such a drawback.
Web Services
This section was presented by Kris Rafnsson.
This is where the NAV team have really stuck to that core value of simplicity. Take the page or codeunit you wish to expose as a web service and add them to a new Web Service table in NAV. Give the service a name and tick the Published check box. You now have a web service. How cool is that? Thankfully the demonstration then goes on to show a couple of uses of the new web service.
The first example shows how you can build a simple application in InfoPath that allows you to query NAV customers in less than 5 minutes – without writing a single line of code!
The URL for the web service in the demo is port 3000 on the machine running the service tier followed by WebServices, the company name, Page (presumably code unit would say Codeunit here) then the name that you gave the service followed by a navws extension.
The methods that are available after adding the page as a web service are:
- Delete
- ModifyAll
- Modify
- InsertAll
- Insert
- IsModified
- Find
- Get
I am not sure what happens to any custom functions that may also be on the page.
The filter that is exposed allows filtering on any field – just as you would in the full user experience. All of the fields from the table are returned as data. Once Kris ran the form, he was able to pull back data for all customers matching a given filter. It was a nearly trivial example but impressive nonetheless. I would have loved to have seen him use the view and update option to post changes back to NAV – I can only assume that this still needs some work.
SharePoint Server 2007 (MOSS) allows the web services to be consumed from NAV in a similar way without writing any code. In the second example Kris creates a Business Data Catalogue Application (he used a pre-prepared XML file for the demo but said that there will be some tools to help build these xml files hopefully ready prior to the release) to use with the NAV web service.
After importing the application definition, there is an entity available called Customer_Service – I am guessing this can be named in the xml file. He then creates a site and page as normal in SharePoint but selects the option for a Business Data List (a part that displays a list of items from a data source in the Business Data Catalogue.) He then links up the Business Data List to the newly created Business Data Catalogue Application.
When the new page is run, there is an actions drop down button and a nice interface for specifying any number of field filters. He hits the Retrieve Data button and the list of data comes back. He clicked on the No. field for the customer and a new Details form is displayed showing all fields that customer.
What he showed is a SharePoint hosted NAV form with no coding and none of the configuration that is needed for the Employee Portal application. From the looks of things the security and different options that you would have in the Employee Portal are taken care of at the SharePoint end when defining the Business Data Catalogue Application. I was very impressed by this and it looked a lot more polished than the current Employee Portal offering.
Some ideas for how the web services could be used are given by Jesper as:
- Master Data Management
- Maintaining Exchange Rates
- Integration with other Applications
- Specialised Clients
- Mobile scenarios
This really is exciting stuff. Come on Microsoft – let's have more of this! Let's have an opportunity to learn about this great technology you are building and maybe make some suggestions along the way.
No comments:
Post a Comment