TagDynamicsNAV

Determining the right client

In certain scenarios, it may be important to know what client that the user is working in. Perhaps you have an action that doesn’t work in the Web Client, or maybe you have some code that interacts with a device camera that only works in the Device Client. Or maybe you want to send a link to your users that allows them to open a record, and we want to make sure the link is for the correct client?
First, I want to be clear that what I am describing here is based on the Dynamics NAV 2017 platform. Yes, this means the Dynamics 365 for Financials platform falls under this umbrella as well. Perhaps bits and pieces are supported on older platforms, but my intention is to never look backwards and keep this train moving forward!
Now to it…
There are some system variables that we need to get familiar with:

  • CLIENTTYPE
    • an option variable that contains the various client types:
      • Windows
      • Web
      • SOAP
      • OData
      • NAS
      • Background
      • Management
      • Tablet
      • Phone
      • Desktop
      • ODataV4
  • CURRENTCLIENTTYPE
    • Returns the client type that is currently executing the code.
  • DEFAULTCLIENTTYPE
    • Returns the default client type, as defined in the Dynamics NAV Server configuration. For more information click here.

Example 1: Show an action only in the Windows Client.

  • In the Development Environment, design the page that contains the action.
  • Make sure that the action does something. If it does not do anything, then it will always be hidden. For testing purposes you can add the following code to the onAction trigger for the action:
MESSAGE('A message for testing');
  • Add a global Boolean variable named ‘showMyAction’:

globalvariable

  • Assign the global variable to the Visible property of the action that you wish to conditional show/hide (you can show this property as a column in the Action Designer now!!):

actiondesigner

  • Add the following code to the onOpenPage trigger:
showMyAction := CURRENTCLIENTTYPE = CLIENTTYPE::Windows;
  • Close, save and compile your page.
  • If you run the page in the Web Client for example, you will not see the action on the ribbon of the page. Running the page from the Windows Client will show the action.

Example 2: Create a url that takes a user to the first customer record.

  • In the Development Environment, create a new codeunit.
  • In the onRun trigger, create the following local variables:

capture-globalvariables

  • In the onRun trigger, add the following code:
Customer.FINDFIRST;
url := GETURL(DEFAULTCLIENTTYPE,COMPANYNAME,OBJECTTYPE::Page,PAGE::"Customer Card",Customer);
MESSAGE(url);
  • Close, save and compile the codeunit.
  • From the Development Environment run the codeunit. A message should appear on screen with the url that was generated. In the example below, my default client was set to be the Web Client.
http://localhost:8080/DynamicsNAV100/WebClient?company=CRONUS%20USA&page=21&bookmark=27%3bEgAAAAJ7CDAAMQAxADIAMQAyADEAMg%3d%3d

Hopefully you get a sense now of how you can condition your code based on the different Dynamics NAV client types.

That’s all for today!

Timestamp fields in Dynamics NAV 2016

Have you ever needed to keep track of when records changed, or have you ever had to do an integration where you want to make sure you keep records in synch across multiple systems?
For master records, this was not a huge chore, as you typically were able to use the Last Date Modified field (if there is one of course), but of course you better hope that all updates to the record call the onModify() trigger. For transactional records though, this became more of a chore, as you would need to either keep track of the last entry you synchronized, or figure out some other way of keeping track what you’ve synched and what you haven’t.
I remember a particular integration that I had to do in which involved synchronizing the Item Ledger Entry table. Sure, I could keep track of the last entry no. so I could easily find all new records since the last synch session, however what became difficult was finding all of the older ledger entries that were updated as inventory transactions were applied to them. Remember that the Item Ledger Entry table is unique in that it gets updated even long after they get created.
Enter the Timestamp field. New to Dynamics NAV 2016, it will simply these types of integration and synchronization scenarios. As far as I can remember, all versions of Dynamics NAV running on SQL Server have had an internal system field name that holds the record timestamp. You could however, only access this field by querying the SQL table directly. Anything done via NAV would never even see the field.
Now with Dynamics NAV 2016, you have the ability for all records to determine which records have not only been inserted, but also modified. You still need to track your date/time reference (e.g. the last time the synch was run), and you are still left to determine what to do if records are deleted, but overall, this is a great new feature to the product!
Here’s how to use them…

  1. In any given table, create yourself a custom field, and assign it a Data Type of BigInteger. The name of the field can be anything you want.

  2. View the Properties of your new field, and set the SQL Timestamp property to Yes. It’s probably a good idea to make it a non-editable field as well, just for logic sake.

  3. Close, save, and compile your table.
  4. Voila, when you run the table, you now how your timestamp!

Umm, ok Mr. Blogger, I get all of this, but that field definitely does not contain either a date or a time!! What’s up with that??
Yes…this is true; the field does not actually hold date or time information. What it does hold though is a “version numbering” that is assigned to each row in a table, across all tables in the database, so every row in the database will have a unique timestamp value. This means that no matter what table you are dealing with, you can use a single reference timestamp and obtain all records that have been added or changed. AWESOME!
(as I said above though, finding deleted records is still a chore that requires coding)
One more note on Timestamp fields. You cannot add them to a table key, however you can still perform a SETCURRENTKEY using the timestamp, since NAV now allows us to sort on any field regardless of it being in a key or not.
So now you know, hopefully you can use this new feature to your advantage.
Happy coding….
MG

NAV 2015 is apptastic!

If you’re in the Dynamics NAV world, you probably already know that NAV 2015 has been released to partners (get it here), and will be available to the general public starting October 1.
One of the new features of NAV 2015 that has me very interested is the tablet interface.
This is a topic that has been kicked around a lot over the past few years with regards to the NAV products I’m involved with. At some point, there’s a line where adding more functionality just adds clutter to the end user. In an age where apps rule, users are quite adept at having a suite of apps that do fewer tasks, but more efficiently.
The tablet interface gives us a way to deal with in the ERP world. Yes I realize we could have been building apps for the past ‘x’ years, but that comes with a lot of overhead, especially if it means a NAV developer having to learn a new programming language. With the NAV 2015 tablet interface though, there’s no additional development that needs to be learned. If you can create pages, you can create tablet interfaces. For end-users, the ability to “pin” or “favorite” multiple NAV 2015 tablet URLs, means that they can essentially build their own toolbox of “apps”, based on the tasks they need to do. Of course, being cross-device compatible is pretty neat too!
I’ll cover more on this in the future as I get my hands dirtier with it, but for now let’s sit back and enjoy the fact that finally it’s easy to bridge the gap between ERP and your device.

© 2020 NAV Bits and Bytes

Theme by Anders NorénUp ↑