One of the most important features (if not the most important) of Dynamics NAV ‘6.0’ is the innovative RoleTailored user experience (UX). As the name indicates, the aim of this is to make the content and layout of the screens fit the needs of the various roles of an organization, so there is one UI for the Order Processor, one for the Bookkeeper, one for the Warehouse Worker etc.
But hey, you might think, if I’m an NAV user, how would anyone know exactly which information or tasks I want or need to be available on the various screens I’m using? The answer to that is obviously not, only the user knows exactly what he or she really needs. This is why we made end user personalization a priority when we planned NAV ‘6.0’. The idea is that both when the system originally is implemented the various Roles and pages of ‘6.0’ will be customized to fit the needs of the customer - you could say that it is RoleTailored for the organization. But when each individual user begins using the system they will have their own preferences as to what is displayed and how it is displayed. And for each page in the system, each user can make their own changes and theses changes are being kept in the database so they will travel with the user from PC to PC.
So what can the user change? Well let’s take the Sales Order page as an example:
(click image to see larger size)
The blue area on the top it what we call the ActionPane and the purpose of this is to give 1-click access to actions or other menu items that are relevant and frequently used while editing or viewing the Sales Order. The user can add or remove actions from a list of relevant actions and can furthermore change the size of the icons to make the most frequently used more accessible. In case the user for some reason doesn’t want the ActionPane visible it can also be removed from the page.
If we move down we come to the FastTabs, and as you can see we have made some significant changes to the layout. By the new design we have made it possible to have more than one tab visible at the same time but we have also made it possible to have selected fields visible even if a FastTab is collapsed.
The personalization of the FastTabs is very rich. The user can decide which FastTabs to have visible, which fields are visible both when it is expanded and when it is collapsed, and as a supplement additional fields can be added that only are visible if the user expands the FastTab.
On the Lines you can obviously choose columns and their order, but we have also added a little nifty feature so you can freeze selected columns to the left which is really helpful when scrolling. (and in case you were wondering, YES it will be possible to have more than one line in the header by the time we release J)
Moving to the right we have the area with the FactBoxes that display information that is related to the content that has focus on the page, but also allows you to drill down to the details of that related information. So you could have a FactBox with additional information for the item with focus on the Lines and from there drill down to investigate substitution items etc.
Here the user can chose which FactBoxes are visible and for each FactBox which fields are shown. Also here the FactBoxes can be removed completely in case the user should want this.
Following personalization the Sales Order page could look like this:
Very different content but clearly still the Sales Order page, but now with the “Personal Touch”.
With this rich personalization functionality we believe that we will enable not only a RoleTailoring of the NAV UI but actually a “UserTailoring”, that truly will allow each individual user to create the work environment and become more productive and effective than with a more traditional UI.
Kim IbfeltDirector, Program Management
RFID technology simply put will someday become just as universal as barcodes are today bringing fully automated inventory management, asset tracking, retail checkouts benefits for all of us as consumers, retailers, distributors, shippers, manufacturers, suppliers, shippers or any other entity in the entire product life-cycle.
In Dynamics NAV group, we started discussing how best to bring forward a RFID solution for our partners and customers quite some time ago. It was however always difficult to find enough resource in the group to justify significant investment compared to other competing priorities (delivering NAV 5.0, making progress on NAV 6.0, service pack…). However we simply could not ignore the importance of RFID.
In my early days with-in the group, I had naïvely assumed that RFID was only relevant to large retailers such as Walmart who could invest heavily for technology adoption in the early days. But then I saw the technology in action in the recently renovated Seattle public libraries, where I could check out a whole stack of books just by putting them at a small pad (seeing all the Titles pop-up on the screen automatically was quite a thrill for a tech geek! – see related story here.), I was a convert on its global adoption at all scales and sizes. Also I was reminded by my team member Stuart that RFID adoption will most likely follow the similar route to Bar Codes.
As industry big-wigs start mandating RFID tags from their partners on their inventory items, partners in turn will look for outsourcing RFID tags printing and stamping work to dedicated suppliers who will invest in RFID printing solutions. And thus every manufacturer, distributer from large to small will easily be able to outsource RFID labeling of their merchandise just as they did so for bar codes in the beginning creating a viable marketplace for RFID enabled tags and scanners in a very short span of time.
Now it was left for us to how to provide a solution in a timely manner that our partners and customers could benefit from. To begin with we chose Microsoft BizTalk RFID technology that provides a device independent platform for integrating various RFID scanners, printers and solutions. This technology platform coupled with power of Dynamics NAV gave us ample opportunity to build a showcase implementation.
We narrowed down scope of our efforts primarily based on available resources, time to market and partner considerations. The end result is a white paper, coupled together with a sample implementation that helps our partners quickly get up to speed on Microsoft BizTalk RFID technology and build their own solutions using native extensibility and integration features of Dynamics NAV as they already know today. Note this sample itself is not a customer ready implementation, as it not only uses the sample RFID emulator device but also it uses a COM+ based events listener that is not ideal for production systems. Partners have already built numerous solutions using MSMQ or Microsoft SQL Server based integration solutions for Dynamics NAV and those will be better suited for production RFID systems.
Download the Dynamics NAV RFID Whitepaper and Sample Implementation (PartnerSource access required)
- Naveen Garg
IntroductionWith Microsoft Dynamics NAV 4.0 we had a job scheduling mechanism available in the Service Management module. The purpose for the job scheduler in Microsoft Dynamics NAV 4.0 is to give the possibility for scheduling tasks and their recurrence.
In Microsoft Dynamics NAV 5.0 the Job Queue was introduced. The Job Queue is primarily made for Outlook Integration, but has been extended to also include the previous job scheduling mechanism from Microsoft Dynamics NAV 4.0. The purpose of the Job Queue is to provide a mechanism for data processing on a server.
The new Job Queue in Microsoft Dynamics NAV 5.0 is build over the following concept:
The Job Queues Entry table is where users or processes can enter a request for execution of a report or a codeunit. The Server (NAS) will look periodically into the Job Queue Entry table to see if there is a Job to execute.
The NAS will when it finds a Job Queue Entry, read it, delete it from the table (unless it is a recurring job) and then start running the requested job (report or codeunit).
When the report or codeunit finishes, the NAS will write a ‘response’ into the Job Queue Response table. In case the calling process has requested this (as is the case for the Outlook integration). The NAS will also insert a record into the Job Queue Log Entry table to record that it has processed a Job (this is not shown on the drawing).
The Microsoft Dynamics NAV permission system determines whether a user has access to run the specified object or not. The permission system will also check if the user has access to the data accessed by the specified object.
Important Note: If permissions are copied from the demo data, users will have permissions to run all objects. Access for each user will in this case only be limited by permissions for data. The job queue will however use the NAS for executing the objects. The NAS is defined as a specific user with specific permissions in Microsoft Dynamics NAV. This means that the objects executed from the Job Queue will be executed with the permissions of the NAS-user. To prevent the situation where access to data and objects are not based on the user permissions and instead of being based on the NAS-user permissions we have introduced an extra requirement for objects to be run via the Job Queue; The user must have explicit permission to run the object that is requested to be run – even if the user has been given the usual default ‘all objects’. In other words, if the user needs to run report 1 via the job queue, the user must have explicit rights to run report 1.
If a codeunit have done some processing and generated a result it must be possible to pass the result back to the user or process. This is where it is beneficial to provide a Job Queue Entry record as a parameter to the codeunit being called.
The Job Queue Entry record has a number of fields whose only purpose is to carry parameters into and out of the codeunit. These fields are copied to the Job Queue Response record. This also means that codeunits that are to be run via the job queue must be specified with the Job Queue Entry record as parameter in the OnRun trigger. Actually this provides one extra level of security, as this prevents users from running random codeunits via the Job Queue. If the user needs to pass on parameters to a report, the only way to do so is by wrapping the report execution into a codeunit which then parses the input parameters and enters them into the reports before executing it.
Follow this link for how to setup
Follow this link for usage example
Martin NielanderProgram Manager
What if all posting routines in Microsoft Dynamics NAV could be scheduled to a more sufficient time of the day?
The example in this blog shows how the job queue functionality can be used to allow background posting of sales orders.
In this example the sales order will contain creation of a new field that indicates if the sales order has been scheduled for posting or not. A filter is also introduced, so that the user doesn’t see Sales Orders that are scheduled for posting. We will also create a Job Queue entry for every sales order and thereby handle every sales order independently. Another possibility could be to add functionality that could handle all scheduled sales orders at one go.
The example also includes some error handling – meaning that if the job queue for some reason can’t post the Sales order, the status is changed to failed, and the Sales Order will reappear on the list of Sales orders the user will have to handle.
To provide an overview, the modified (and the new) objects are listed here:
Note that we introduce space for an error message (in case of Posting Error). The error text could be made available as a ‘lookup’ value in the status field.
We need to make the sales orders that are scheduled for posting in the job queue disappear from the view in form 42. Note also, that we have made the Job Queue Status field visible on the form.
When the user presses Post or F11, codeunit 81 is called directly with the Sales Header record as parameter. So let’s modify codeunit 81:
Note that when inserting the JobQueueEntry, it’s primarily the User ID field that is filled other fields are filled with default values. Note also that we specify the job queue to run a codeunit “Sales Order Post via Job Queue”, which is new and created for this example. The sales order to be posted is specified using the GETPOSITION function and entered into the Parameter String field of the Job Queue Entry. The Job Queue Entry record has several parameter fields that can be used in various situations.
Note that a codeunit that is being run by the job queue has to have the Job Queue Entry record as parameter. And as described in the last section, you also need to explicitly give the users permission to run codeunit 9000 – unless they are specified as ‘SUPER’.
Some codeunits display some kind of progress indicators using the dialog. When executing code on a NAS, no GUI operations are allowed. Hence, all updates of the progress dialog window in codeunit 80 needs to be wrapped with a IF GUIALLOWED THEN...
The default security setup in NAV relies entirely on restrictions on data access. By default all users have access to all forms, codeunits, reports etc. except the data, they process or show. Since the Job Queue mechanism has no way of sensing what data will be affected by running e.g. codeunit 9000 (that then runs codeunit 80 that runs codeunit 12 …) we have chosen to require specific execution permission to codeunits and report that are going to be run by the job queue.
And that’s it. Now go on and post the sales order and see what happens.
I would like to add a special thanks to Rikke Lassen and Bardur Knudsen for making this blog a reality.
The Job Queue is handling the order of batch jobs and code units that are setup to run at a given time. The application server reads from the job queue and determines what job to run next. Several parameters can be set up to determine this.
Before you can setup and execute a job queue you will need to:
1. Install Microsoft Dynamics NAV 5.0
2. Install Microsoft Dynamics NAV Application Server
a. Make sure that the NAV Application Server service is a user registered in NAV and on the SQL Server, if SQL Server is the database server for NAV
b. Startup parameters for the application server: <jobqueue>
3. Create your job queue entries (See Job Queue usage example here)
4. Activate the job queue
The Job Queue Entry Card window in figure x-1 shows the actual job. It can either be a single instance or a re-occurring job. Therefore there are two tabs in this window: General and Recurrence.
Via the Job Queue Entry Card it is possible to setup a limitation for attempts to start a specific job. If a limitation is needed a value should be entered in the Maximum No. of Attempts field. The field No. of Attempts to Run will list how many times the current job has been attempted to run. Also the time intervals as to when the job should try to start are setup here in the Earliest Start Date/Time field.
Figure x-1: Job Queue Entry Card
The different Status codes are:
· On hold
· In process
If the job is performed successfully it will be removed from the list in the Job Queue Entries Card window unless it is a recurring job.
The Recurrence tab on the Job Queue Entry Card is used to setup recurrence of each Job Queue Entry.
The Job Queue Entry administrator should, as a good practice; set the Job Queue to On Hold before changing the different settings in the Job Queue Entry Card. Once the Job Queue Entry administrator is done with the setup of a Job Queue Entry the Reset Status will activate the job.
Figure x-2: Job Queue Entry Card – Reset status
On the recurrence tab, the jobs can be set to be scheduled only on specific week days.
The Job Queue Entries List will list all current job queues; the window is displayed in figure x-3. Go to the Administration menu - Application Setup - Job Queue and then click Job Queue Entries and press F5 to get the Job Queue Entry List.
Figure x-3: Job Queue Entry List
The Job Queue Entry List displays the Status of the job, the User ID of the user that initiated the job in addition to the Object ID in question. If the status is ready then the application server can run the scheduled job. The application server will run the listed jobs based on entries in fields: Earliest Start Date/Time and Priority. While the job is running, it will be listed in the Job Queue Processes window figure x-4.
Figure x-4: Job Queue Processes window
The Job Queue Log Entries displays a list of jobs which already have been running.
Figure x-5: Job Queue Log Entries
The Job Queue Log Entries will also display any error messages for Job Queue Entries that went wrong. Each line represents a Job Queue Entry. If the job ended with errors during the expedition of the Job Queue Entries the error message will be listed as the last column in the Job Queue Log Entries. The error message limitation is 1000 characters.
The Job Queue function is activated or deactivated in the Job Queue Setup window. Select the field Job Queue Active to make the job queue active.
Figure x-6: The Job Queue Setup
You should now be able to set up the Job Queue for CodeUnits and Reports in Microsoft Dynamics NAV 5.0.
When troubleshooting performance problems, a typical questions is: "which indexes can be disabled on SQL"? This blog shows a simple way to get some ideas of which indexes are used. The method will give some ideas of both how often they are updated (causing overhead), and how often the indexes are actually used. So it gives some ideas of costs and benefits for each index.
SQL2005 introduced the concept of Dynamic Management Views (DMVs), which show internal statistics from a lot of different areas in SQL Server. The DMVs can all be found in SQL Server Management Studio, if you expand System Databases -> master -> Views -> System Views. I would recommend to take a quick look, and get an idea of what other useful information is available here.
The view relevant to this blog is called sys.dm_db_index_usage_stats. To run it, just do a SELECT on this view. Or, to get results that are a bit more useful, run this:
SELECT db_name(database_id),object_name(object_id),* FROM sys.dm_db_index_usage_stats
Check the columns user_seeks, user_scans and user_lookups to get an idea how often an index is being used. Then compare with the column user_updates, to see how often the index is being used.
There are a number of other columns available, and the query above could easily be modified to for example ORDER BY user_updates, to see the indexes causing the largest overheads, and then check the actual usage of these indexes.
Note: The DMV will be reset every time you restart SQL Server. So the number is shows only represent index usage since last time you restarted SQL Server.