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 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 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 the 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 cases, looking at the integration tool for what items are listed will be the biggest clue as to what type of integration they are. SmartConnect shows when a map was run last and how many times it has been run to get a good idea of what may be more important than others on the list. (It's been so long since I used Integration Manager, that I can't even remember if it also has a "last time run" identified).

Assuming the same tool will continue to be used after the upgrade, ensure the following is part of the upgrade plan:

  • Ensure the integration tool itself is installed and configured where it will be tested during the 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 (i.e., server/database).
  • Review the integrations, and 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 users 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 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 increments 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 visible in IM or SmartConnect (or other tools 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 are needed 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 the upgrade.

System-driven integrations

When getting into system-to-system integrations, it is much harder to define clearly what the 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 an application-to-application integration, such as CRM to Dynamics GP, determine if there is going to be a "Test CRM" system that will be connected for testing.

Second, if it's "home-grown" systems connected, i.e., custom integrations, determine 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 from one 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 to upgrade and test what we needed to.

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

Lastly, plan carefully what occurs on these system-to-system integrations from a go-live planning perspective. If there are schedules, there may be a 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, and 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 custom integration 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 for those not aware of that end-to-end process, is it possible to miss out on some important data coming into GP?

During testing, the point is to identify what it takes to make it work, so the tasks for going live are documented. 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 understanding of what is there and why it is there, the better the testing and go-live plan will be.