The Anomaly of the XMLport Request Page
2014-4-8 18:31

The user interface of the XMLport has always been somewhat of a black swan. On the classic platform it was absent and you had to work around it yourself. With the emerge of the windows client (RTC) we did get a request page as one of the incentives for us to start adopting the 3-tier technology. And of course, with NAV 2013, the XMLport became the lawful heir of the deprecated Dataport. Nevertheless, it remains a black swan as the request page does not meet some of the standard features we know from pages and report request pages, as I only found out a couple of weeks ago. Talking about a black swan. Geeked

Did you notice that the About This Page feature is lacking on the XMLport request page?

And what about that Copy Link to XMLport action on the ribbon?

Why has this been implemented different from the same on the report request page and page objects? Just for completeness have a look at the objects:

I wouldn't call this a consistent UX.

OK, the Link to ... does what it should do even though UX-wise it's not consistent, but the lacking About this Page is something different. I have no means to identify the ID of the XMLport  and use that in a bug report ...

Of course I created a misconnect entry here to ask for more consistency (or at least get an About This Page feature for the XMLport).

Poisson d'Avril - The Sequel, part #4
2014-4-1 15:46

4th time in a row Microsoft has given me the MVP award. Even though I personally feel I haven't been on the edge of things as in the previous years, I know I have been doing my best the past year to share my knowledge and experience and bother Microsoft enough. Having been engaged primarily with a dev team at an end-user clearly got me off-edge, not saying that it hasn't been worthwhile as it clearly was, not in the least due to the people I have been working with, but also the change of perspective. Thanx, guys!

I surely haven't been writing a lot recently having been very busy with different projects like SEPA updates, conducting and organizing course, the Dutch Dynamics Community, TFS consulting, etc. And of course, trying to balance it all with the rest of daily live, which continues to be challenge for me.

A big hand to all who have been part of this all and supported me very well.

Workshop NAV ALM using Team Foundation Server
2014-3-4 17:45

In close cooperation with the Plataan I will be conducting a 2 days workshop on NAV ALM using Team Foundation Server. You're welcome to join!

Plataan - Microsoft Dynamics - Learning + Competence Management

Please check out below our new workshop 'NAV ALM using Team Foundation Server'.

“A perfect - no, even better - alternative to the various home brewed source control and product planning systems is Visual Studio Team Foundation Server (TFS).”

TFS for NAV Development

Did you know that TFS is a powerful ALM (Application Lifecycle Management) tool that can support your NAV development projects? Do you know that you can build your fobs by using the TFS build systems?

In this unique two day workshop (10-11 April in Hasselt), Dynamics NAV MVP Luc van Vugt will show you how you can manage and control your developments projects better by using Team Foundation Server (TFS) for NAV development projects.

A hands-on development exercise

Luc van Vugt will learn you how to use TFS in your NAV development projects for source control, product and project planning, test planning and execution, requirements gathering and documentation, code history tracking, bug tracking and activity planning. Students will have the ability to practice these new insights with a hands-on development exercise.

You will learn how to use TFS with the NAV development environment that is not integrated with Visual Studio.

This unique MVP workshop will answer questions like:

- How can I get my organization to work with TFS?
- Which software and hardware do I need for TFS integration?
- How to integrate the NAV development environment with TFS?
- How to build fobs with the TFS build systems?
- How can I secure my code and get better insight in the history?
- How can I better manage and track my product development?
- How can I design and plan testing?
- How can I track bugs?

This is a unique session by an experienced NAV MVP specialized in integrating TFS and NAV.

Extend Go To Definition with Navigation History
2014-1-15 10:36

... and enable back and forth browsing.

I often find myself in the situation that I have been navigating through some C/AL code using the Go To Definition feature of which I recon each NAV developer is still very pleased with since the introduction of it in NAV 2009 R2. For sure I am still using it on a daily basis.

Now finding myself at the end of a "chain of Go To Definition actions" I would like to navigate back towards my starting point. Having navigated from one object to another this isn't to difficult as this simple means closing each object that has been opened. But when this chain occurs in one object I have no way of easily doing this.

So I am longing for a navigation history that allows me to navigate in reverse order; even select from this history an individual intermediate stage, likewise with any internet browser; or Dynamics NAV. Cool

If you think this awesome please go to msconnect and vote for the suggestion I created there.

by Luc van Vugt | 1 comment(s)
Filed under: ,
NAV ALM with Team Foundation Server | How-to Videos
2014-1-15 8:48

As you probably have noticed I have been detailing my NAV TechDays starting with branch and merge strategies. Meanwhile "TFS brother in arms" Soren Klemmensen has taken off with how-to videos. Very instructive!

Click on the image to go to Soren's blog.

Soren has already created two videos:

NAV Branching & Merging Matters: Incorporating Standard NAV
2014-1-11 13:09

Reading my posts NAV ALM with Team Foundation Server | Branch Strategy and NAV ALM with Team Foundation Server | Merge Strategy you probably have been thinking: "Thanks and well done Luc, but doesn't sound like NAV specific."
You're totally right! The setups I discussed there are totally product independent; and these are only three of them. You might even study the wider range of setups discussed in the Branching and Merging Guide by the Visual Studio ALM Rangers and choose (or conceive) one that fits your needs better.

Now the logical question following would be: "Aren't there any NAV specific matters to consider?"
Sure there are, such as:

  • In most cases we use NAV standard as the basis of the product we are developing
  • Potentially we are not the only one making changes to this standard code as MS is frequently releasing hotfixes that we might want or need to incorporate into our product
  • Using (other) add-ons into our product in the same matter as NAV standard
  • Developing a product for an international market, i.e. being released to various local countries

In this post I am going to elaborate on how you could incorporate NAV standard in case you are developing a product for a local market (bullets 1 and 2). In later posts I might pay attention to the more broader picture of the third and fourth bullets.

Local Add-on

So your add-on is being developed for a local market in, let's say, the Netherlands (NL), meaning your code is added to NAVNL. Partly new objects and partly customized NAVNL objects.
Therefor we need a container to hold the NAVNL code (NAV/main) which we branch to our add-on (add-on/main):

To this add-on branch we will apply a strategy as discussed in NAV ALM with Team Foundation Server | Branch Strategy.
The schematic TFS structure would then look as follows:

Applicable hotfixes issued by MS will first be checked-in into NAV/main from where it will be integrated into the add-on:

Additional Layers

In the different development setups I have been working so far I have implemented a number of extra layers, which more or less results in a structure as displayed below:

Note that ...

  • NAV contains copies of the RTM code of all versions that have been relevant to us so far; this not only has historical sense, but has proven its worth dozens of times when needing to compare current code with previous versions of NAV
  • NAV/main is the folder as discussed above and always contains the code of the NAV version we are currently "on" with our product
  • Above NAV you might have noticed that the folder dynamics_NAV_development; this is the name of the Team Project that holds our NAV code (next to possibly other team projects holding .Net code)
  • Anywhere product (or add-on) is mentioned this can also be applied to project
feliz NAVidad and much more for 2014
2014-1-1 12:16

... to all of you.

I hope on next New Year's Eve you will all be able to look back upon 2014 concluding that it has been worthwhile, whatever it was that crossed your "road". Goosebumps on your skin, love in your heart, even though that "road" can be very, very, very tough.

Thanx to all that across my road in 2013.

by Luc van Vugt | with no comments
Filed under:
NAV ALM with Team Foundation Server | A Day in the Life of ...
2013-12-31 13:46

After our exploratory talk a couple of weeks ago, I was booked for yesterday by a Dutch NAV partner to help them out on their first steps 'into' TFS. Using Visual Studio Online we did setup a collection and a team project, drafted and implemented a branch structure and discussed the use of work items in relation to code check-ins and scrum methodology.

And among this all these basic questions recurred: what does it basically mean to be a NAV developer in a TFS environment? What are the specific task to be executed?

So here we go for a typical day in the life of … Luc, NAV developer happily using TFS.

  1. My Work
  2. Sync my TFS workspace
  3. Sync my NAV "workspace" - Import
  4. Do my "thing"
  5. From NAV to TFS workspace - Export
  6. Inspect pending changes
  7. Check-in change

1. My Work

Having had our stand-up with my team, I pour myself another cup of tea - yes, tea, as after half a century I still abhor coffee - and start up my laptop. I open my Visual Studio client and in the Team Explorer Home pane I click My Work to see what tasks are desperately waiting for me to get finished.

Nearing the end of our sprint unsurprisingly not very much. Some unfinished work (suspended work > participants) and two development tasks.

As one of my colleagues had pointed out during the stand-up that the … error when adding seminars … issue needs to be finished first to allow it to be tested, it's clear what I need to pick up. So I drag and drop 109 from available work items to in progress work

2. Sync my TFS workspace

But before I can start I need to make sure that my local development environment is in sync with TFS.

Get Latest

So I right click on the add-on node in the Source Explorer and select Get Latest Version. Any code change that has been checked into TFS by others will also now reside in workspace.

Forward integrate (optional)

If we are using a branching strategy with separate branches for each developer, like in the DTAP setup in my branching strategy post, I might also need to perform a forward integration (FI) - and check-in - to incorporate the latest changes in the beta/test branch into your own.

3. Sync my NAV "workspace" - Import

Now that I have updated my TFS workspace I need to make sure that my NAV "workspace" is synced too; i.e. import the updated objects into my local NAV development database.

I can do this per object, which makes sense when it concerns only a handful of objects. Or I could use some tricks to get this done more efficiently. I will dive into this in another post.

4. Do my "thing"

Now I can go ahead to do my "thing". Looking at the info the already resides on work item 109 (and the accompanying bug) I see that it's a simple issue due to an incomplete table relation definition, fix it in a couple of minutes and verify the fix with some straightforward unit tests.

5. From NAV to TFS workspace - Export

As the change has been implemented, it has to be exported to my TFS workspace.

6. Inspect pending changes

As I overwrite the existing version of the object in my TFS workspace TFS automatically checks it out for me appending it to the pending changes list to which I already have added the work item.

But before I will check-in this change I make sure I provide (1) some useful description of this change, (2) add the bug work item and (3) …

…, last but not least, will inspect the changes I made. This is one of these TFS features that makes me feel happy every time I am using it. I just have to right click on a changed object and select Compare with Latest Version to get a comparison between the current version on the server and the (changed) version in my workspace:

A simple, efficient and powerful way to check whether the changed objects do contain the fix or feature I implemented. Or did I forget to export the latest version from NAV?

7. Check-in change

Now that check, double-check proved me that all changes reside in my workspace I can check it in.

Using a branching strategy, like in the DTAP setup in my branching strategy post, I probably should propagate my changes to the consolidation branch beta/test. For this I need to perform:

  1. forward integration (FI), including a check-in, to incorporate the latest changes in the beta/test branch into my branch
    note that this is needed to make the next action simpler as it will first handle any changes in beta/test separate from mine
  2. a backward integration (BI), also including a check-in, to incorporate my change in the beta/test branch

Ouch …

… you might say as this seems typically more actions than you might be used in a traditional NAV setup where all devs code in a centralized database. You might be right, but we should not forget the broader picture of the setup we are in now.

  • Linking each check-in to the relevant work items ensures that code changes and information like requirements and design decisions are bounded
  • Each changeset can be propagated in a controlled way from one branch to another
  • I have current and previous versions of each objects at hand that can help me to easily check my changes against
  • ...
Christmas Eve: Merry, Merry Xmas
2013-12-24 13:54

Christmas Eve. Rain outside and moderate temperature. Cosy inside, having set the tree and decorated it with silver, red and gold, and the old electric candles that I inherited from days gone. Haven't used them for ages and still shining bright. Preparing our Kerststol with the dough to rise and now waiting for it. Wife and children gathering in our kitchen for some bread and setting up Smallworld. And urging me to join them.

So have to keep it short and thus remains to wish you all a merry Xmas!

by Luc van Vugt | with no comments
Filed under:
The Next Generation PartnerSource/CustomerSource?
2013-12-2 16:02

Did you see this communication on PartnerSource/CustomerSource?

Having been harsh on MS various times with respect to PartnerSource I must admit I was quite astounded by this news. I really had to overcome some disbelief and force myself to read the article and let go of my prejudice. Yes, I still have to wait to January 11 before I will be able to believe my eyes. And yes, I will do my utmost best to be positively surprised and fiercely hope this promise will stand.

And as the Microsoft Dynamics Community Team writes:

Let us know your thoughts!

Again, this is just the first step in a longer journey. At launch in January, we’ll provide a detailed 2014/2015 roadmap and show you a list of the capabilities we’re shooting for, not just in PartnerSource, but also in how we evolve the customer journey. We also recommend reviewing the Next Generation PartnerSource and CustomerSource FAQ to help alleviate some general questions you may have. If you’d like to submit questions or comments prior to launch, please contact us at mbsexp@microsoft.com and we’ll get back to you quickly.

Book Review: Microsoft Dynamics NAV 2013 Inside
2013-11-26 18:19

When Rene Gayer informed his fellow Dynamics NAV MVPs, me included, about his new book on NAV 2013, I directly volunteered to read it and provide him with feedback. Looking back I guess I did not fully understood the implication of the first lines in his May 28, 2013, mail to us:

finally..uff our new Book NAV 2013 Inside will be available on 01.06.2013..
puuhh deferral of 6 month .. hard work ..

Now finally having read this 500+ pager, I do. I guess you understand why it took me almost half a year to get to finish the book, next to doing some many others things. As said a 500+ pager, discussing zillions of useful things about NAV 2013. Both Technical and functional.

But let me, before I continue, first make a small, but essential, correction here: it's not his, i.e. Rene's, book alone, it's a joint cooperation of three Dynamics NAV pros, who did a darn good job by compiling all this information into this Inside. Thumbs up for Rene, Michaela and Christian. Yes

Table of Contents

Just a simple glance at the table of contents shows the extend of the book:

  • Chapter 2 – General Introduction to Microsoft Dynamics NAV® 2013
  • Chapter 3 – Usability improvements
  • Chapter 4 – Application Enhancements
  • Chapter 5 – Installation, Configuration and Maintenance
  • Chapter 6 – Page Design in Microsoft Dynamics NAV 2013
  • Chapter 7 – Report Design in Microsoft Dynamics NAV 2013
  • Chapter 8 – Query Design with Microsoft Dynamics NAV 2013
  • Chapter 9 – Introduction to the Web Client
  • Chapter 10 – Introduction to the SharePoint Client
  • Chapter 11 – General News in C/AL and C/SIDE
  • Chapter 12 – Debugging in Microsoft Dynamics NAV 2013

Being around in the NAV world for almost 15 years now, and having been included in the TAP program of NAV 2013, I had some smug internal voice wondering if it would really be worthwhile for me to read it at all; to spend my precious time on it. Luckily there were still other voices taking a so much different standpoint. Thank you!

Now having taken the trouble of reading the book, I am glad I did. Now I know that, next to the standard Microsoft Dynamics NAV 2013 resource on MSDN, I can turn to this resource and most probably find answers regarding NAV 2013 issues. Or direct others to, and herewith do!

Of course you might wonder, if I am only positive to help Rene et al, and that's not the case. I really like the book for what it is, forwhat I said above. But indeed, there are a couple of minor points:

  1. Being nonnative English writers, they did quite a good job, but it's not always smoothly to read
  2. I do miss an index; of course using a .pdf I have the Adobe Reader text search functionality, but if you buy a hardcopy, you will have that and then searching for something specific might prove a hard job to do

But these will not keep me from using the book. Stick out tongue

Buy

Did I convince you of the value of this book? Then go out to msdynamicsbooks.com and buy a copy yourself.

NAV ALM with Team Foundation Server | Merge Strategy
2013-11-24 8:51

With my branch strategy post, I have provided you with a basis to design a source control structure to store your code in TFS. However, this is just half the story when it comes to how to keep the various branches in sync to the right extend. So here comes in the merge part of the strategy, i.e. the "what about all those FI and RI arrows going up and down?" question I left hanging in the air at the end of my branch strategy post.

Note: the branch strategies discussed (and also not discussed but to be found in the the Branching and Merging Guide by the VS ALM Rangers) can also be applied to other source control systems like Perforce.

We'll use the DTAP setup to dive into details.

Scenario 1: hotfix implementation and propagation

A hotfix is typically issued on a release. Using the DTAP setup you would be ending up updating the code in the relevant release branch, say Release 2.1. So let's focus on this.

A bug has been reported on release 2.1 and this needs a hotfix that at ...

  1. ... will be implemented in the related branch: Release 2.1

    as this bug was also proven to exist in our current product, i.e. Main, you want to integrate this fix at ...
     
  2. ... from Release 2.1 into Main, which is called a reverse integration (RI) as Release 2.1 was branched from Main

    to bring the rest of our structure in sync with this change we also need to propagate this to the other branches starting at ...
     
  3. ... with a forward integration (FI) from Main to Test - forward as Test is branched from Main

    and at ..
     
  4. ... with a forward integration (FI) from Test to DevelopmentDevelopment is branched from Test!

As there are many roads that lead to Rome, there are various ways to achieve this hotfix implementation and propagation, the above being one of them. And alternative scenario could be the following, leaving it to you to fill in the details from steps 1 to 4.

You might consider this scenario to establish a double check before propagating the fix to Main.

Scenario 2: feature development

Clearly the development of a new feature will be done in (one of) the Development branch(es). You've got all requirements and some kind of technical design, thus ready to take off.

But before you start make sure at ...

  1. ... to bring your Development branch in sync with Test by means of a forward integration (FI) and then continue at ...
  2. ... to do the implementation of the feature; once ready, i.e. code ready and technically tested, you would like to propagate it to Test

    now before you do this, always makes sure that code in Development and Test share the same base as this will make the merging much easier, therefor at ...
     
  3. ... bring Development branch in sync with Test by means of a forward integration (FI) and then continue at ...

    Note that in our case this FI is strictly not necessary as we already did this at step 1, however, during the time you are developing the feature, and before you want to integrate it with Test, most probably other updates have been propagated to Test, thus this FI
     
  4. ... to integrate your feature from Development to Test

    for the sake of ease let's assume the feature has been fully tested and approved to be brought into Main, but, likewise step 3 above, you first need to bring Test at level with Main, so at ...
     
  5. ... bring Test branch in sync with Main by means of a forward integration (FI) and then continue at ...
  6. ... to integrate your feature from Test to Main

In a later stage the feature will be part of the release by means of the release creation (i.e. branch) at 7.

Notes

  • Reverse and forward integrations can be performed with the standard TFS merge functionality, either from the UI or cmd
  • So far this all is not NAV specific

References

NAV ALM with Team Foundation Server | Branch Strategy
2013-11-22 10:12

So after my manifold "pledge" to go there and start today you might have been playing around with TFS. You did put your code there and started to update it with bug fixes and code enhancements. Great, but then you might have wondered: how does this all relate to the NAV production environment you're working in daily? How does this relate to the DTAP paradigm? Here is where the branch strategy comes in and which I am going to elaborate on in this post.

Setup 1: from development to release

Let's say you have an add-on version 2.0. It's stored in a centralized database, well tested, thus stable, and as with any product, state of the art ... now. But as we all know, software contains flaws next to restricted functionality. So in the near future you will be updating the code, which will be released as v2.1.

Even without having any source control system, with Dynamics NAV, you will implicitly be ending up branching your code for release by means of a .fob file that is deployed to your customer as the objects in the .fob file contain all your code.

And the same applies for the next version, 2.2.

Translating this setup to TFS schematic, would look like:

Main holds the code you develop and test on, and Releases the code that has been put into production at your customer. A structure with the advantage of being simple, but as you might guess, some drawbacks 'cause how to handle parallel development and testing in general; or more specifically: how to handle parallel development once you approach the release date. In this simple setup you most probably have to set development on hold, apart from bug fixing, to be able to conduct the final tests.

Setup 2: development parallel to test (and release)

So how do we go about this? By setting up a separate database for Development. That's no rocket science. Geeked

Now, parallel to whatever is happening in the Main database, coding can continue in Development. Once the isolated development, relevant to your release, has finished, the code can be (reverse) integrated into Main, where test will be performed to prove the code valid (or not). Of course this reverse integration will be happening various times during your next release project. For every feature being delivered to test, for fixes for bugs found during test, etc.

As said: no rocket science, and TFS will be helpful on this as it

  • facilitates automatic creation of branches, likewise from Main to Development and Main to Releases
  • remembers the relation between these branches based on which you can perform the (reverse) integration by means of standard functions

Depending on your exact need, we could continue building even more complex structures, but we will not, apart from one case: the setup I used in my NAV TechDays presentation. For more setups please refer to the Branching and Merging Guide by the VS ALM Rangers.

Setup 3: DTAP with multiple developers

Looking at the setup I used in my NAV TechDays presentation, we can clearly distinguish separate branches for Development, Test, Acceptance and Production and in addition we also have separate branches for (feature) development.

Or schematic in TFS:

You might wonder: what about all those FI and RI arrows going up and down? I will elaborate on that in a next post, on merging.

Notes

  • DevelopmentTestMain / Releases is a standard terminology
  • So far this all is not NAV specific
  • For those who know labeling: to a big extend you might derive the same result by labeling, but in general I'd rather create separate branches to keep overview and prevent unwanted code changes

References

NAV ALM with Team Foundation Server | My Top 5
2013-11-17 17:16

Misty, autumnal Sunday late afternoon. Lost our field hockey match. Shoot. But won - again! - a game of Stone Age. YES! So now, time to sit down and start my elaboration on my NAV TechDays presentation on NAV ALM with Team Foundation Server, while my dear wife is preparing our diner. Thanx, Sas! Left HugRight Hug

I had set, as primary goal for my presentation, to convey my enthusiasm for TFS and rouse it with my audience. Given the number and character of reactions I got there after, I gladly can conclude I did reach my aim. To achieve this, however, I deliberatly left out details, that might be of importance for you, once you get started with TFS within your NAV development. In the next sequel of posts I will work out on My Top 5, being the central framework I had composed my presentation around.

Whereas the chronology of my presentation served the aforementioned goal, the chronology of my posts are meant to help you make the right decisions in setting up TFS for your NAV projects or product development. This leads us to the last entry of my top 5: 5. Branch & Merge, as we first need to make sure that we set up a valid and useful structure for our source control before we can set off with any project or product development in TFS.

But stop: let's not run to fast here as I will put each of my elaborations in individual post and will create some kind of table of contents in this post. For each individual post a link will be added here:

1. Secure & Refer

2. Develop & Fix

3. Test & Bug

4. Plan & Execute

5. Branch & Merge

Visual Studio Online
2013-11-14 8:28

While me and my colleague Marcel were digging ourselves into NAV's cost calculation, Visual Studio 2013 was offically launched. Thus having missed all excitement and live communications, this morning I had a first and quick browse through all the news that was shared on this event. You might have seen some of the things I retweeted. Having been using Team Foundation Service for my NAV TechDays presentation this almost trivial thing directly caught my eye: the rename of Team Foundation Service into Visual Studio Online.

To get some more details read Brian Harry's article Visual Studio Online updates - Nov 13.

Based on the free availability of Team Foundation Service, uhhh, Visual Studio Online, I did my utmost best in my presentation to convey the message: Get there and start today. No complex installation to stop you from start using (or at least investigating th use of) TFS for NAV development. And also no cost to keep from starting. So go there and start today: http://www.visualstudio.com/.

For details on the 2-fold offering (Basic or Professional): http://www.visualstudio.com/en-us/products/visual-studio-online-Overview-vs.

So don't stop here, but get there and start today.

If you missed this "message" during my presentation I am sure you got it now ;-).

More Posts Next page »

Recent Posts

Search

Email Notifications

This Blog

Tags

Favorite BLOGS

MS BLOGS

Team Foundation Server BLOGS

NAV & TFS BLOGS

Syndication

Archives