Preparation for your NAV development career is like setting the plays for the championship, and choosing your starting lineup.
The three-pointer
Why three? Because we NEVER ever develop in production! (If you do
that now, take a chair. You’ve fouled out!) NAV is a very integrated
system, and all changes need to be fully tested before they are
implemented. If you put your changes directly into production, you have
no way of testing. Removing your changes can be costly and time
consuming, at the very least. Therefore, you will need a test database
that mirrors your production environment’s data and objects. This
database will allow users to test your code before you place it into
production. And if something goes wrong and your code adversely affects
your test database, you’re still in the game! You just build a new
test database.
The third database is your practice court. This is the database where
you do the development and your own testing. Let’s face it. None of us
are perfect. There are things that we don’t anticipate in development
tasks and things we overlook as we code. Why air your dirty laundry to
your users by putting it in the test database before you get a shot at
cleaning up your code? A development database allows you to complete
your task and test it before you have to let a user have a crack at it.
It also allows you to set up test scripts (a series of situations that
you find possible in the production environment) that can be reviewed in
the test phase to see if the user can identify missing test scenarios.
All three databases can reside on the same SQL server, but you will
want to do a little housecleaning after you’ve created the databases. If
your database has sensitive data, such as credit card numbers, social
security numbers, personal information, etc…, you will want to remove
this information or assure that it’s not accessible in your testing. At
the very least, lock down permissions on the database via NAV security.
If your database has external links, such as the ability to send
emails or process credit cards, you will want to disable these
functions, and possibly remove relevant data as well. Sending your
customer’s emails from your test documents or charging their credit
cards from them will result in a personal foul. Your best bet is to
remove the data, and disable the processes. This can usually be done
through the application setup.
The uniform
Just like you can’t get on the court without a uniform, you can’t
develop NAV without a developer license (which is just a set of granules
in your current license). But don’t let that keep you out of the
game! You can obtain these granules from your VAR, who can discuss
their abilities with you, to help you determine which you need, and give
you the cost for obtaining them. Regardless of which granules you
obtain, you are allowed to only change the objects within your licensed
applications.
You’d be surprised at how easy it is to add a field to a form or page,
or add a piece of data to a report. Even if you stop at this point,
you’ll not only gain the ability to do these things, but learn more
about how NAV is designed, and what developing in NAV is like. If
you’re not sure if you really want to develop in NAV, try this first.
You can always obtain a higher privileged license later on.
A house divided
Likewise, NAV has two flavors as well with the Classic Client and the
Role Tailored Client (RTC). Knowing which you are using is imperative
to creating the right development environment.
The Classic Client environment requires only the NAV application with
the Classic Client and the SQL database. All code, regardless of which
flavor you have, is written within the Classic Client. This is the
“default” environment for NAV.
If you’re developing in an RTC environment, you’ll also need an
install of Visual Studio 2008 for development of RTC reports, as well as
a
three-tier environment
for your NAV install. Talk to your VAR if you’re unsure which of these
you have, and they can assist you in creating a strong development
environment.
Talk to the coach
Even if you have all the tools for development, the environment is
created, your license is installed, and you’re already passing the ball
and going for the hoop, you need to talk to your VAR. If you have
ongoing development with your VAR’s developers, the last thing you want
to do is modify your objects without checking with them first.
NAV’s object set is very integrated. A change to a single object
could result in necessary changes to other objects. Likewise, your
VAR’s developers may have copies of your same objects involved in other
development endeavors. The last thing you want to pay them for is
reworking their code to include your modifications.
Have a quick conversation with your VAR and discuss how you will keep your code and their code synchronized.Work with in-house developers and have developed a version control
system whereby we incorporate our client’s code into our code and
prevent rework.
Get in the game!
You will have obstacles and you will have days when you just feel
defeated. But don’t walk away. Team up with the NAV community. We are
here for you when those bad days come. Just as any profession, we grow
strongest when we grow together.
Regards,
Sathish