|
|
How to Read Our "Role-Tailored" Newsletter
Much like the approach Microsoft has taken with
NAV 2009, our newsletter provides a “role-tailored” experience. Because we work in different capacities with
different groups (direct support for end clients, and subcontract development work for partners) and aim to provide
some content for everyone, our newsletter articles range from end-user tips to technical developer notes. We
don’t want you to start into an article that may not be suited to your perspective, so our newsletter content is
colour coded. Below each article title you’ll find a colour coding scheme that identifies the target audience(s)
as follows:
 End Users
 Project Managers / Analysts / "Power" Users
 Technical Staff / Developers
Introduction - Spring 2009 Edition
Users
Analysts
Developers
Greetings and welcome to the inaugural issue of Epimatic NAVigations!
This quarterly newsletter will focus on topics related to Microsoft Dynamics NAV, ranging from end user tips and tricks to in-depth
technical discussions.
The first question you might have is, "Who is Epimatic?". To provide a short answer, we are a small group of senior level NAV
resources based in the Toronto, Ontario (Canada) area. All of our consultants/developers have at least 5 years developing and
supporting for the Microsoft Dynamics NAV platform (formerly Navision, formerly Navision Attain, etc.). We provide both direct NAV
support to end clients, as well as subcontract development services to Microsoft Dynamics NAV partners. Regardless of who we’re
working with, we collaborate closely to analyze, design, develop and deliver exception NAV-based solutions to business challenges.
Welcome again to our first issue. We hope you'll find some useful information that helps you rethink and expand how you're using
NAV to ensure you're tapping the full potential of your investment. We love what we do, are passionate about the product we support,
and you should be too! Microsoft Dynamics NAV really is a powerful application when properly deployed and extended, which is where
we aim to help.
If you would like to be removed from our distribution list, don't hesitate to email newsletter@epimatic.com
to make that request. Otherwise, read on and enjoy!
The Epimatic Team
Do You Feel Integrated Today?
BY JEFF LANDEEN
Users
Analysts
Developers
|
Microsoft Dynamics NAV will power the financial heart of a company,
but a big question is whether it can do it all on its own. In
any organization there are many physical and logical data flows plus user operations that allow the business to function and meet
strategic objectives. Some of these workflows will be contained completely within NAV while others may only be partially represented
in NAV (e.g. customer interactions in web based sales tool such as Salesforce.com). These distributed workflows and operations create
an opportunity to automate data flows in and out of NAV so that an organization can:
- Minimize data entry errors and data duplication
- Improve user response times and efficiency
- Allow greater visibility and accuracy of Inventory, Financial and other information
The goal of integration is not simply to integrate just because the systems are installed and in place – there has to be a business
need (e.g. importing sales orders from a website), and this need has to be matched with an integration solution that is reasonable
given budgetary and other resource constraints. Generally the more manual a solution, the less development time is required to build
and deploy while the more automated a solution, the more development time is required. This tradeoff must be balanced against user needs, business requirements and the project budget.
Some of the NAV integration projects we’ve encountered include:
- electronic bank reconciliation and fund transfers
- online equipment rental system interoperation
- automate existing MS Excel/MS Access based processes (saves implementation time as you don’t have to rebuild the process in NAV – and requires a minimal training effort)
- create sales orders in NAV based on web site sales
- create purchase orders in NAV from online purchasing tools
- web based Time & Expense entry/management processes
Some of the Integration Options available to a NAV install include:
- File based integration
- Usually user-driven processes that are more manual and require less development
- XML – Extensible Markup Language
- Supported by newer systems (.Net, Java, etc.)
- Contains data and meta data for easier processing and validation
- Flat File – normally comma/tab separated values or fixed field length
- Normally used by older legacy, mainframe & financial systems
- Web Service based Integration
- Allows interaction to and from other web service based applications
- This integration method is normally used to support real time operations
- Direct Table Access (Staging Table) based integration
- Allows interaction from other systems that can read/write directly to specially managed NAV based integration (a.k.a staging tables)
- This method is normally used on SQL based NAV installs running scheduled operations
- Biztalk Based Integration
- Can be used to replace older EDI processes
- Other File & Database Integrations
- Normally uses automation and allows NAV to read/write data to/from other systems
The latest versions of Microsoft Dynamics NAV (2009 and 5.0 SP1) can support all of the integration options outlined
here with manual execution, scheduled execution or real time execution of the integration logic. While newer versions
of the NAV client and server support the most integration options, an older installation can be upgraded to use newer
executables so all these features are available. Simply upgrading the executables is a cost effective way to support
the full range of new integration options without having to invest in a full object upgrade.
In summary there are many integration options available to any NAV site and these can be used to help a company’s
operations run more smoothlywith fewer errors. Effective integration processes allow users to focus on value-added
activities and less on repetitive data entry tasks. For more technical details and design considerations please request
a copy of our Integration Whitepaper from newsletter@epimatic.com.
NAV 2009 Role Tailored Development Quirks
BY ROB HANSEN
Developers
After over 8 years as a NAV developer, it's both exciting and scary to see the changes presented by the Role Tailored
Client interface in NAV 2009. It's exciting see the underlying base of NAV business logic that we know so well extended
with a more "dynamic" user interface. It's really the first big evolution of the product I've had to navigate, and it's
humbling to be on the learning curve somewhat once again!
As I've worked through some initial tasks with NAV 2009, I'm getting comfortable with concepts such as "Pages", "Actions"
and the new reporting mechanism through SQL Reporting Services. At the same time there have been some initial bumps that
have been frustrating and time consuming to understand/overcome, so I figured it would be helpful to relay these
tidbits to those who will follow in my footsteps. Note that this is certainly not intended to be a discussion of
"important" things to be aware of - it is really just a first hand account of some quirks I've hit during simple
development tasks after the architecture change from NAV 5.0 to NAV 2009.
With no further ado, here are the first few battle scars I picked up with NAV 2009 and will remember going forward.
1. I can't FindPrinter...where oh where is my printer?
I was working on a modification that involved overriding the printer to be used for certain scenarios. In the past I had
tackled this with logic in the FindPrinter function of codeunit 1...simple enough. So, I took that approach again. I
tested with the NAV 2009 Classic client and all was good. Then I tried the Role Tailored Client (RTC) and...no dice.
Hmm. Thinking something simple was off, I added a CONFIRM prompt to the FindPrinter function to make sure it was being
hit and...it wasn't. Grr. The Role Tailored Client doesn't call the FindPrinter function at all...well, at least for
any report with a SQL Reporting Services based layout defined. If it is a classic report with no SRS layout, then
FindPrinter and the usual "classic" logic WILL be triggered.
Alright...so FindPrinter isn't used in these cases. There must be similar logic somewhere else for use by the RTC,
right? A quick export and search indicated that the Printer Selection table was not referenced anywhere except the
FindPrinter function. At this point I figured I was missing something obvious, so I set up a Printer Selection record for
a test report and a blank User ID (i.e. for all users direct a report to a certain printer). I printed it through the
RTC and the printer did NOT default as it should. NOW I was baffled...how the heck can reports under the RTC be directed
to specific printers (eg. pick ticket to a warehouse printer, cheque to a printer with cheque stock) if Printer Selections
is never used? The product would be unusable for some scenarios with this limitation! After some more playing around,
though, I found that Printer Selections WERE implemented so long as a User ID is filled in. Whew. But the real mystery
was why it was working at all if FindPrinter was not being triggered. Some more digging around and confirmation by a
helpful fellow on mibuso.com confirmed that the logic seems to be handled at the executable level. The application itself
looks up the Printer Selections and passes them over to the SRS reporting client. So, it's good that the functionality
still exists (albeit without the ability to direct a report for ALL users to a given printer) but the logic can no longer
be controlled within C/AL code.
So, my modification required some rethinking on its approach. I had to write records into the Printer Selection table to
direct the reports to the appropriate printers, trigger the reports to let the RTC do its thing, then restore the original
Printer Selection records. This is working fine and serves the purpose, but has the downside that if the user cancels the
report (I still show the request page in some cases to allow filtering, option setting, etc.) then the manipulated Printer
Selection records are left in the table. A training issue for the time being...
2. It's all about perspective
This is a minor one, but we'll all need to think in terms of where processes are running. For the Role Tailored Client,
the logic is running on the service tier (on a server). So, where you might have written code in the past to use the
"File" virtual table to read folder contents on the workstation, this will now execute on the server and will show folders and
files from the SERVER'S perspective, not the workstation. A drive "H:" that is mapped on the user's workstation will not
be accessible from the server. The same concept applies for functions like EXISTS (to check for a file) and ERASE (to
delete a file). Understand that the path for these functions needs to be valid from the server's perspective, and if you
really need to perform a function on the workstation's local drive from the user's perspective, you need to take a different
approach (such as creating a workstation-side instance of the FileSystemObject along the lines of point 3 below).
3. Take a walk on the wild side...er, workstation side
You may have written code that would make use of third party (or your own) ActiveX components. Similar to point 2, by default
in NAV 2009 if you simply CREATE a component in code, it will happen ON THE SERVICE TIER (on the SERVER). In my customization
example earlier, I had a component that I had written to update the registry to automate the PDF writer I was using. This
needed to happen on the end workstation where the PDF writer was installed and where the destination path for the PDF existed.
For the most part a simple change in syntax of the CREATE statement will take care of this. Instead of:
CREATE(ComponentName);
We can use:
CREATE(ComponentName,TRUE,ISSERVICETIER);
The second parameter (TRUE) just indicates that a new instance of the component should be created (nothing related to
server/workstation location). The third parameter is the one that indicates WHERE the component should be created. TRUE tells
NAV to instantiate the component on the WORKSTATION side, and NOT the server. Using the ISSERVICETIER function will return TRUE
whenever the user is running the Role Tailored Client, and FALSE for the classic client. So, a small syntax change is all that’s
needed to keep ActiveX components running on the user’s workstation as always.
Just as we learned to set a TableView on a report DataItem in classic NAV to eliminate a filter tab for the respective table,
there are going to be new idiosyncrasies to pick up with NAV 2009. Over time some of these may go away through service pack
releases, but for now, new workarounds are the order of the day at times!
|
|
Scheduling with the Job Queue
Did you know that starting with version 5.0 of NAV there
is a job scheduling tool available with NAV out of the box? Job Queue allows you to schedule a codeunit or report to run
unattended via a Navision Application Server (NAS) – note that the objects must be capable of running without any user prompts
or user interface elements. A job can be run once at a specified time or it can be setup to run on a recurring schedule and
will log success or failure condition to a table for review.
An "ALMOST" Upgrade
If you’re on an older version of Navision, you can upgrade to
a newer version of executable files only. This doesn’t mean going through a full migration to a new release (which can
be very time consuming and expensive), but instead just moving your current version objects to run on the latest application
executable files. By doing this, you can enable your existing database to run on newer versions of Windows (if you’re on an older
version facing limitations), you can gain some performance improvements, and you can take advantage of some new features (such as
XML Ports for moving data in and out in XML format if you’re on version 3 or older, which don’t have those tools). An executable
upgrade is like throwing an inexpensive new coat of paint on your existing Navision database...so long as you’re on a current
enhancement plan with Microsoft.
Need Some Help?
If you haven't worked with Epimatic before, we'd welcome the
opportunity to speak with you to see how we might be of assistance on your next NAV-based project. Whether you're an end user
looking for additional support, or a Microsoft Dynamics partner in need of additional development capacity, please contact
newsletter@epimatic.com to get the ball rolling and join our list of satisfied
clients!
Don't Want this Newsletter?
If you're not interested in receiving
Epimatic NAVigations, please email newsletter@epimatic.com to request removal.
|
|
|
