All About Epicor 10.2 Product Configurator
With the festive season charging forward like a white-tailed deer dodging a hunter’s shot, I began to reflect on some of the holiday gifts I had received as a child. I remember finding my brightly colored box named for me, ripping through the wrapping paper with glee, anxious to find just what was bottled up inside the cardboard box of the year—normally some elaborate plastic play-thing, composed of more components than angels on a pin. Pulling open the cardboard gates, I routinely discovered that the contents of a box never quite resembled the shiny images on its outer face. That is, there was one pivotal phrase that stood between the receipt of a gift and its actual usage: “Some assembly required.”
That single phrase was as impassible and looming as the Sphinx. Upon reading this riddle, I would rush to my father and beg him to figure it out for me, and in typical holiday spirits, he would lay his eggnog aside and curse his way through the necessary assembly. The lessons learned through these experiences stayed with me into adulthood. Now, as I’ve perused the aisles of the local box shop, looking for a suitable gift for my own, I’ve quickly learned to spot the familiar warning—and move on. I’ve become known as the parent who has bequeathed gifts like modeling clay for the holidays. It encourages the imagination, I’ve claimed. Moreover, there is no way for a parent to botch its assembly!
With Epicor’s version 10.2 similarly cresting the horizon like a jolly old man in a flying toboggan, I’ve come to notice how customers utilizing Epicor’s legacy Product Configurator react to the idea of an upgrade in much the same way I’ve reacted to a 600-piece dollhouse—they duck into the next aisle. In any version, Epicor’s Product Configurator is a complex module—it is part functional setup, part development toolkit. And companies spend a lot of work in developing the configurators that will support their business requirements. That is, there is a lot of assemblies required, once this gift is unwrapped. And the idea of reimplementing Epicor 10 configurator for a new version feels, to some customers, like their dollhouse just got smashed, and they are required to reassemble it again, only now with a new set of assembly instructions.
In spite of these understandable concerns, I believe Epicor’s 10.X configurator platform is a tremendous improvement to its previous iterations: it is more scalable, more flexible, and allows for better-designed solutions that yield a better end-user experiences. And try as I might, I can find no CPQ solutions made of modeling clay…
While there are no easy instructions when it comes to upgrading Epicor 10 configurators, I have found, in working with customers, that there are a few lessons that we’ve learned, lessons that could be thought of as “reassembly instructions.”
A few might include the following:
I have found that it benefits customers to run an early initial trial upgrade of their existing Epicor database, strictly for purposes of reviewing the upgraded configurators. With each new version of 10.X.XXX, the upgrade process gets tweaked and improved, so issues upgrading configurators in one version may be resolved in another, and the upgraded configurators may be sufficiently intact, as to constitute a decent starting point from which to begin their efforts.
In terms of business logic, companies benefit when they look for opportunities to utilize UD methods in lieu of the on-leave event handlers in legacy versions. These can be a helpful way of centralizing code, and even a nice way just to pull it out and give it a clear and distinct definition, which allows for more logical designs and greater maintainability.
In terms of Method Rules, companies should look to consolidate the many individual rules from legacy versions into single statements in 10. In the Epicor 10 configurator rule designer, the option to “execute specified expression” allows for great freedom in developing blocks of code to update multiple fields at once. This allows customers to consolidate all of their efforts into a single place, which usually makes for better maintainability.
In most cases, the development of a solid C# skillset is a must for working in configurator 10.X, in much the same way that Progress ABL/4GL skills were central to Epicor’s legacy configurators, particularly if the configurator being upgraded has a lot of custom code to manage its business logic.
Converting code need not require a .net savant. There is the web page for converting 4GL to C#–that can get you in the ballpark, one block at a time. But for the absolute novice to C#, it helps to have someone available who has worked in C# and Progress-based configurator environments.
C# has a few particularities that are critical to handle right away, as they will prevent a block of code from passing syntax check. These include:
The use of a semicolon: all statements end with a semicolon.
Braces: multi-line blocks of code (such as if-then blocks, switch statements, or for each blocks) are wrapped in braces (“{}”).
Case Sensitivity: C# is a case-sensitive language. That is, the .net compiler will interpret “cmbPartNum” to be something other than “cmbpartnum.” This is an infuriating peculiarity for someone coming from a Progress environment, where the case did not matter.
Object Orientation: in the .net platform, interaction with any program involves the use of object properties and methods. This involves commands that differ somewhat from the legacy design. For instance, a command to update a field in 10.X, you might look like ‘Inputs.chrPartDesc.Value = “lalala”’ whereas the same command in the progress-based configurator would look like “chrPartDesc = ‘lalala’”. Understanding these small differences can go a long way in making steady progress in configurator conversion.
I find it a good approach to have a customer review their existing configurator code base prior to the upgrade, and identify each unique king of logical activity they perform. This might include, but is not limited to the following:
- For each loops
- Switch Statements
- If then else logic
- Reading UD tables
- Writing to UD Tables
From there, the customer can develop a solution catalogue for addressing each unique code construct—how the each unique activities performed in Progress 4GL would be performed in C#. The idea here is to document each code conversion best practice, so you don’t have to reinvent the wheel the next time you encounter the same construct in another configurator.
