NAV Team: Search in NAV 2009 - Part 3 (out of 3)Microsoft Dynamics NAV 2009 Ships! - Dynamics CRM: Blogs

Blog bot · 26.11.2008, 13:08

If you haven't read part 2 and part 1 of the Search in NAV 2009 posts, you should do so before continuing.

This is the 3rd and final part of the Search in NAV 2009 post. In this section I will show how to create a Windows Vista Gadget and have this gadget connect to NAV through Web Services and search in NAV (like the System Tray version in part 2).

We will create an installable Gadget like:

and when installed the user should be able to perform searches like:

Giving the user the opportunity to click on items and link into NAV 2009.

As you will notice the results window is different from the results window in part 2 and the main reason for this is, that I couldn't get intra document links (that be <A HREF="#Customers"> and <A NAME="Customers">) to work in a flyout. Every time you would click a link which should reposition yourself in the document - it would reload the page and leave me with a blank page.

After having struggled with this for some hours I decided that that piece was primarily done in order to help keyboard users - and since Gadgets kind of require the mouse I decided to remove the intra document links.

If anybody finds a way to do this, feel free to add a comment and make me smarter! :-)

I actually think the sample shows that the strategy of having the Web Service just return a result set and have the consumer format this in the way that fits the consumer is the right decision.

What is a .Gadget file?
If you ever downloaded a file called Something.Gadget and opened it, you might get a warning like this

and if you say Install, then the Gadget gets installed - very easy indeed, but what is this?

As a hint - try to rename the file to Something.Gadget.zip - and you will see.

The file extension Gadget is known by Windows Sidebar, which will look for a Gadget.xml in the .zip file and if a correct Gadget.xml is present, it will display this installation dialog and if you select to Install, the .zip file is unpacked into a directory under

C:Users<username>AppDataLocalMicrosoftWindows SidebarGadgets

and add the gadget to the sidebar.

Note that the .zip file should NOT contain the outer directory - only the content.

And what is the Gadget then?
The Gadget is actually just a small html document, which can contain Javascript, VB Script code or other client side code, supported in html. The first file read by the Sidebar is the Gadget.xml file, which in my Search example looks like:

<?xml version="1.0" encoding="utf-8" ?>
<gadget>
    <name>NAV Search Gadget</name>
    <namespace>NAVsearch</namespace>
    <version>1.0</version>
    <author name="Freddy Kristiansen">
        <info url="http://blogs.msdn.com/freddyk" />
    </author>
    <copyright>None, feel free to use!</copyright>
    <description>Freddys NAV Search Gadget</description>
    <icons>
      <icon height="48" width="48" src="Images/Navision.ico" />
    </icons>
    <hosts>
        <host name="sidebar">
            <base type="HTML" apiVersion="1.0.0" src="gadget.html" mce_src="gadget.html" />
            <permissions>full</permissions>
            <platform minPlatformVersion="0.3" />
        </host>
    </hosts>
</gadget>

So, this is where you define Name, Namespace, Version, Author, etc. But also Icon to display in the Add Gadget and the html document to display in the sidebar (in this case gadget.html).

In my sample I will be using Javascript - not because I by any means is an expert in Javascript - but I did some Javascript coding back around year 2000 - so I guess it is time to refresh my memory. I use notepad as my editor - and the biggest problem I have run into is, that whenever I make a mistake (like misspell something btw. Javascript is case sensitive) execution of Javascript will just stop without giving any form of error. I guess there are better way to write Javascript than this - I just haven't found it.

Gadget.html
Note, that this is not an HTML tutorial, I expect you to know the basic constructs of HTML and Javascript - you should be able to find a LOT of content around these things on the Internet.

The body section of my gadget looks like this:

<body bgcolor="0" leftmargin="0" topmargin="0" >
<g:background opacity="100"></g:background>
<table width="100%" height="100%" border="0" hspace="0" vspace="0" cellpadding="0" cellspacing="0">
<tr>
<td height="36" align="left" valign="top" background="Images/gadgettop.png" nowrap><p style="margin-top: 10px"><font color="#FFFFFF" size="3" face="Segoe UI">NAV Search</font></p></td>
</tr>
<tr>
<td height="22" valign="middle" background="Images/gadgetmiddle.png">
<input type="textbox" id="SearchText" onFocus="hideFlyout();"><input type="image" src="Images/search.png" id="doSearch" onClick="search();">
</td>
</tr>
<tr>
<td height="28" border="0" background="Images/gadgetbottom.png"><div align="right" valign="middle">[img]Images/weelogo.png[/img]</div></td>
</tr>
</table>
</body>

As you can see, most of this is HTML in order to make the Gadget look right. The only two Javascript methods that are called is

hideFlyout() - when the textbox receives focus.
search() - when you click the search icon (or press enter in the text box)

and of course our Gadget has references to some images from an Images folder.

The main search function looks like this

// Main search function
// search after the content in the textbox
function search()
{
    // If flyout is shown, hide it
    if (System.Gadget.Flyout.show)
    {
        hideFlyout();
    }

    // Get search string
    str = document.getElementById("SearchText").value;
    if (str != "")
    {
        // Perform search
        result = doSearch(str);
        if (result != "")
        {
            // Store HTML to use when flyout pops out
            newHTML = result;
            // Display result in flyout
            System.Gadget.Flyout.show = true;
        }
    }
}

System.Gadget.Flyout is part of the Gadget Framework and gives you access to set a document used for flyouts, show the flyout and hide it again.

The flyout is (as you can imagine) also just a HTML document - even though it doesn't behave totally like a normal browser showing a HTML document - more about that later.

As you can see, the function, which will be doing the Web Service connection and the "real" search is doSearch:

// the "real" search function
function doSearch(searchstring)
{
    // Get the URL for the NAV 2009 Search Codeunit
    var URL = GetBaseURL() + "Codeunit/Search";

   // Create XMLHTTP and send SOAP document
    xmlhttp = new ActiveXObject("Msxml2.XMLHTTP.4.0");
    xmlhttp.open("POST", URL, false, null, null);
    xmlhttp.setRequestHeader("Content-Type", "text/xml; charset=utf-8tf-8");
    xmlhttp.setRequestHeader("SOAPAction", "DoSearch");
    xmlhttp.Send('<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><DoSearch xmlns="urn:microsoft-dynamics-schemas/codeunit/Search"><searchstring>'+searchstring+'</searchstring><result></result></DoSearch></soap:Body></soap:Envelope>');

    // Find the result in the soap result and return the rsult
    xmldoc = xmlhttp.ResponseXML;
    xmldoc.setProperty('SelectionLanguage', 'XPath');
    xmldoc.setProperty('SelectionNamespaces', 'xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns="urn:microsoft-dynamics-schemas/codeunit/Search"');
    result = xmldoc.selectSingleNode("/soap:Envelope/soap:Body/tns

oSearch_Result/tns:result").text;

    // Load result into XML Document
    xmldoc = new ActiveXObject("Msxml2.DOMDocument.4.0");
    xmldoc.loadXML(result);

    // Load XSL document
    xsldoc = new ActiveXObject("Msxml2.DOMDocument.4.0");
    xsldoc.load("SearchResultToHTML.xslt");

    // Transform
    return xmldoc.transformNode(xsldoc);
}

***Это спам-сообщение*** - a lot of code.

This is actually the only code in the Gadget connecting to Web Services - all the other code is housekeeping and has as such nothing to do with NAV 2009. Basically we just get the URL for the Web Service and use XMLHTTP to connect to the Web Service and get a SOAP response back. We use XPath to find the XML result from our codeunit. Load this into a XML Document. Load the XSLT into another XML Document and transform the XML using the XSLT - somehow similar to the way we did it in C# in part 2.

I will post other examples of Gadgets communicating with NAV Web Services, stay tuned.

The basic initialization of the gadget is done in

// Microsoft suggests using onreadystatechange instead of onLoad
document.onreadystatechange = function()
{
    if(document.readyState=="complete")
    {
        // Initialize Settings and Flyout
        System.Gadget.settingsUI = "settings.html";
        System.Gadget.Flyout.file = "flyout.html";

        // Add eventhandler for Flyout onShow
        System.Gadget.Flyout.onShow = flyoutShowing;

        // Write default Base URL in settings if not already done
        GetBaseURL();
    }
}

When setting the value of settingsUI on System.Gadget the gadget will get a small

icon when you hover over the Gadget and an Options menu item in the Context menu. Both these options will open the HTML defined in settingsUI.

There is no code in the Flyout - the only special thing is with the flyout is that it contains an IFRAME element, which loads the content.html document in order to get a scrollbar if the content of the flyout becomes too big.

The GetBaseURL function is used under startup - and when we need to connect.

// Get the Base Web Services URL
function GetBaseURL()
{
    // Read the URL from settings
    var URL = System.Gadget.Settings.readString("URL");
    if (URL == "")
    {
        // No settings in the settings.ini - write the default URL
        URL = defaultURL;
        System.Gadget.Settings.writeString("URL", URL);
    }
    // Always terminate with /
    if (URL.substr(URL.length-1,1) != "/")
    {
        URL = URL + "/";
    }
    return URL;
}

The reason for calling the function at startup is, that we set the settings to the default URL if it isn't already defined. It is better that the settings dialog comes up with "some" default than just a blank URL - IMO.

The settings.html contains two functions for doing the housekeeping of the settings:

// Initialize settings Form
document.onreadystatechange = function()
{
    if(document.readyState=="complete")
    {
        // Read settings and set in form
        URL.value = System.Gadget.Settings.read("URL");
    }
}

// Event handler for onSettingsClosing
System.Gadget.onSettingsClosing = function(event)
{
    if (event.closeAction == event.Action.commit)
    {
        // Write new URL into settings
        System.Gadget.Settings.writeString("URL", URL.value);

        // State that it is OK to close the settings form
        event.cancel = false;
    }
}

I will let the code speak for itself.

The System.Gadget.Settings read and write functions stores the settings in

C:Users<username>AppDataLocalMicrosoftWindows Sidebarsettings.ini

and the settings will be stored in clear text, you will actually be able to modify this file as well.

That's it for the NAV Search demo - I hope you like it, you can download the Gadget from http://www.freddy.dk/Search - Part 3.zip. Note that this download cannot stand alone - you need the NAV piece of this, which you can find in Part 1.

Enjoy

Freddy Kristiansen
PM Architect
Microsoft Dynamics NAV

A week ago, the Microsoft Dynamics NAV team celebrated the launch of version 2009, a product that involved over three years of work. We had a party on the MDCC campus (which subsequently ended up in an Irish bar somewhere in Copenhagen) and spent some time talking about our accomplishments. The energy in the room was infectious. We signed the ship poster, a tradition at Microsoft, previewed the Microsoft Dynamics NAV demo for Kirill's keynote at Convergence EMEA, and announced that we'd take a team day off – these all helped people savor the moment. Though we hit many bumps along the way during those three years, we finished with what it is nothing short of a landmark release. So, if you're an NAV fan and it's Friday night for you, toast to this release, because it's an event to remember!

In this blog post, I'd like to tell the story of Microsoft Dynamics NAV 2009. Instead of resorting to sanitized marketing sound bites, this will be a more personal account. It's my own particular point of view exploring this product and how it relates to our customers and partners.

There are a number of things that I simply love about this release, but I have to start with the UX (or user design). When I installed NAV 2009 when I first joined the team back in February, I knew the user experience was special. Then, in my last blog post, I admitted that I had a crush on it. Now, I must say that it's brilliant. To understand why, I have to make a brief detour.

At the heart of a good business solution is the resulting productivity of its users. How much time does the system save? How much higher is the quality of their work? Because we are engineers, we at MBS needed a business productivity framework to understand how to improve it with our products. Together with a research firm, we concluded that end user productivity had to take into consideration familiarity, ease-of-use, business insight, collaboration, and flexibility in addition to transactional efficiency (what we typically think about when we think about productivity). As I started to learn more and more about the Dynamics NAV 2009's user experience, I realized just how well it captured all these characteristics. It is familiar – Role Centers make users feel at home with the data and work they see upon entering the product; it is easy to use - Activities and the Action Pane make it very apparent how things are done and what needs to be done; it provides insight through integrated reports and data that are showcased in the context of actions to be taken; it makes collaboration easy through notifications and by working well with Office; it is flexible - personalizations permeate the experience and are very simple to make; and, finally, it is efficient - keyboard shortcuts and data positioned well with actions make performing tasks fast.

But this isn't brilliant. This isn't a work of art. This is just good engineering. What makes the user experience brilliant is that users with it. I recall an email thread I had with Jakob Nielsen, our Director of UX, sometime this past summer. In a larger forum, he was talking about getting our customers to have an emotional connection to our user experiences. I thought, "What's he talking about?" I joked, "What's he smoking?" But over time, it sunk in. And then last week, I saw a video from a customer that had just recently gone live with Microsoft Dynamics NAV 2009 as a part of our early technical adoption program (TAP). In the footage, a warehouse manager showed off his Role Center and asked the Director of Operations for the company, "Can I keep it?" Here was a person who was emotionally attached.

People who love the tools they work with end up loving their work more. People who love their work more end up being more successful. They make fewer mistakes, they treat each other better, and they get to work on time. If we build a Microsoft Dynamics NAV user experience that users love, it's a win-win-win situation. The customer wins. The customer's employee wins. And we at Microsoft win. That's why this user experience is brilliant.

Of course, Microsoft Dynamics NAV 2009 has a lot more to it under the hoods. If you're an engineer, you can sense when a software product is getting "brittle." Just like a bridge that has had too much stress over time and suffers metal fatigue, so too does software age if it isn't refactored over time. Entropy creeps in as code is added that doesn't adhere to the original design principles or doesn't meet the original quality bar (assuming this existed). For 2009 we've made a conscious effort to modernize the core architecture. For instance, in addition to giving the user experience a new look and feel, we've also built it from scratch on .NET. It has a modern, modular architecture that will help us introduce new innovations in the future quickly and without compromising quality, innovations such as a new "channel" like Sharepoint or new visualization controls that are based on the dynamic capabilities of Silverlight or WPF. We've also made the architecture 3-tier from a 2-tier fat client. In addition to improving security, such as running the business logic from one, trusted place, this change gives partners the ability to do application-to-application integration much more easily with web services. With a click of a button in C/SIDE, a new web service is exposed for consumption.

On the server tier, we've taken advantage of .NET once again. C/AL business logic written in C/SIDE now compiles down to MSIL via a C# transformation. Consequently, we leverage the innovations that the .NET runtime team has worked on for the past eight years. This frees our team up to focus on problems more closely related to ERP. As I've already mentioned for the client and the server, we've taken advantage of Microsoft's world class platform stack, particularly with .NET. But we've also done this with SQL reporting services, which are now our tool of choice for charts and table reports that can be viewed in context in the user experience. In summary, these architectural investments have a tremendous impact on this release and future releases. Good, modern architecture gets the best technology in your hands over time and maintains high quality.
It's true that this release has largely been about technology. That was intentional. We made a commitment to modernize the product, and from our perspective, we're probably two-thirds done. We’ve finished the hard parts and the ones that impact partners and customers the most: the user experience, reporting, and the tiered architecture. We recognize that a fine balance must be made between innovation on the one hand and maintaining partners' and customers' investments on the other hand. There is no perfect formula here. Sometimes there are innovations that break changes that our customers and partners have made. In these cases, you have a couple of strategies to minimize the pain - you make the innovations "opt-in" and you create tools and provide support for completing the transformation. In Microsoft Dynamics NAV 2009, we've done both.

We allow our customers to run the "Classic" client and the RoleTailored client concurrently. This gives customers flexibility to move their users to the RTC over time. In addition, we've made sure that "Classic" reports, the most common customization that customers create, run in the RoleTailored client, so they do not have to be converted to SQL RS reports if the customer doesn't care to take advantage of RS's capabilities. As I mentioned before, the business logic in Microsoft Dynamics NAV 2009 is converted from C/AL to MSIL via C#. Though the runtime has changed, the actual code itself has not. This means that business logic changed or added by partners and customers is protected and migrates to the new version as-is. Finally, for partners, we've maintained the C/SIDE development environment, extended it with a page designer, and provided tools for converting "Classic" forms and reports to pages and RS reports, respectively.

Perhaps the thing I'm most proud about in this release is that we’ve substantially improved its quality. We're upping the bar considerably in a number of ways. The clearest indication is with the TAP and the Beta Access Program (BAP). As a result of these programs, we have 9 customers already running Microsoft Dynamics NAV 2009 in production, and over 80 different partners, including ISVs and implementers, trained and familiar with the new version. My favorite statistics are these - we have over 1 year of server uptime without a crash reported and over 135 user-months on the RoleTailored user experience. These should give you an indication of the stability and the attention to quality that we've paid on the release. There are a number of other quality initiatives and investments that we've made, including improving our stress test environment, improving our code coverage and automation, and testing on 100 configurations of the operating system, database, and other system elements. We think you're getting the highest quality NAV product yet.

As you can see, for me the story of Microsoft Dynamics NAV 2009 is one of tremendous success. The value proposition of end user productivity is core to our vision and very compelling to our customers. The investments in modernization of the architecture set the stage for innovation and product improvements in the future. The attention to partner and customer investments has made this release the best in terms of readiness. And the quality achievements have set the bar higher than they've ever been. While this is not a perfect release - it will require partners to learn new concepts like RoleTailored computing and new tools like the Reporting Services designer, it is one that I believe takes Microsoft Dynamics NAV, our partners, and our customers into a new, modern era of ERP! I hope that you're checking it out!

- Dan

Источник: http://blogs.msdn.com/freddyk/archive/2008...2009-ships.aspx