GP Upgrades – know your environment part 4

My last post was a few months ago and since then I’ve gotten a little distracted with other things (summer, nicer weather, etc.). I’m ready to try to catch up and finish this upgrade series, continuing on for now with the “know your environment” topic. So far I have covered some product terminology, product types & ISV products, and a bit about identifying external applications. In this post, I will talk about what I look for in terms of integrations and things to consider for upgrades.

Posts in the series

1. Series intro
2. Process overview
3. Know your environment (part 1)
4. Know your environment (part 2)
5. Know your environment (part 3)

Types of integrations

In general terms, there are many types of integrations but the most common would be user-driven or ad-hoc integrations and system-driven integrations (either real-time system to system type things like how external applications may integrate to GP or scheduled integration points between systems). This may be over-simplifying things quite a bit but for the purpose of this post, I think it will do!

User-driven integrations

These types of integrations are things where users are running an integration process often by opening the integration tool itself, i.e. opening Integration Manager or SmartConnect and running an import. What defines this group to me is it is not a scheduled integration nor is it automatic.

From an upgrade perspective, these are often the simplest to plan for and test. Typically the import format is file-based, such as .csv, .txt or .xlsx. The process often looks like this for a user:

1. Save your data in a file in a certain location.
2. Open the integration tool.
3. Run the integration.
4. Check the results in GP.

In most of the cases, looking at your integration tool for what items are listed will be the biggest clue as to what type of integration they are. SmartConnect tells you when something was run last and how many times it has been run so you have a good idea of what may be more important than others on the list. (It’s been so long since I used Integration Manager, I can’t even remember if it also has a “last time run” identified).

Assuming you are using the same tool after the upgrade, you’ll want to ensure the following is part of your upgrade plan:

• Ensure the integration tool itself is installed and configured where you will be testing your upgrade. It may be a new version or it may not, but depending on the type of tool, some part of it is tied to where it is connected to (i.e., server/database).
• Review the integrations, identify which need to be upgraded (if necessary) and which need to be tested. If the source data is file-based, make copies of the source files so that you can point to a temporary location for testing. This might require remapping some integrations to another pathname for testing (i.e., where to save the import file).
• Ensure the testing team knows they cannot simply open their existing templates or whatever they use and import to test the exact same way they do day-to-day. If paths where they need to save the source file changes, ensure they are aware of the new location.
• Review the integrations for any scripting that may be involved. Often integrations have scripts that may contain additional references to a server/database/environment and need to be updated for testing. For example, a customer import may have a step that looks in Dynamics GP for the last customer number of a certain pattern, and then increment by 1 to create a unique customer ID automatically. That implies a connection to a database that needs changing in addition to the destination location for the import itself.

From a test tracking point of view: list every integration you see in your IM or SmartConnect (or other tool of choice) integration listing. For each one, the decision to be documented is “is this still needed?”, and if yes, it needs to be tested. This is a good time to clean up old integrations that may no longer be required and don’t need to be carried forward to a new server/environment.

Track whatever changes you need to make to get it ready for testing. Some of the same changes may be required at go live if there is a server move involved in your upgrade.

System-driven integrations

When you get into system to system integrations, it is much harder to define clearly what your options may be. There are so many different types of integrations I cannot do this justice but I can provide some high level thoughts around what I would be looking at.

First, if it’s application to application, such as CRM to Dynamics GP, you need to understand if there is going to be a “Test CRM” system you will be connecting to for the purpose of testing.

Second, if it’s “home-grown” systems connected to each other, i.e., custom integrations, you also want to know if there are test versions of those systems, and how the integration works between them. For example, the upgrade I was working on when I started this series has a custom integration I built for the Harris Northstar system into Dynamics GP. It’s a nightly scheduled integration, SQL to SQL via SmartConnect. The client had a “test” version of the source system that we could connect to in order to upgrade and test what we needed to.

Third, if it’s scheduled (as opposed to real-time), remember you need to test the integration itself between the two systems and test the scheduling part. If your upgrade involves moving servers, scheduling typically involves some kind of service account and permissions may need to be checked. Once you know the integration works by running it manually, then try running it via schedule the way it would on day 1 after go live.

Lastly, plan carefully what occurs on these system to system integrations from a go live planning perspective. If there are schedules, you may need to pause them until the upgrade is completed as there may be upgrades on either the integration tool or the integrations that are needed during the go live upgrade. Determining the proper timing for stopping the integration of data, ensuring whatever the source is “keeps” that data for when the upgrade is ready for it is another thing to consider. For example, using the Harris Northstar example above, the previous integration would archive the days’ transactions without checking if the integration was successful. I have since changed that so archiving only occurs on records that have been integrated but if you’re not aware of that end-to-end process, would you miss out on some important data coming into GP?

During testing, the point is identifying what it takes to make it work, so you know what you need to do at go live. Some things can be saved/copied for go live, some things are just steps you need to perform again based on what you did during testing that worked.

Summary

In conclusion, there are many things to think about from an integration standpoint, and many are hard to clearly define in a blog post like this without knowing your environment. The more you understand what you have and why you have it, the better your testing and go live plan will be.