EMERALDCUBE BLOG

Dev 101 Part I: Setting Up a Business Function Debugging Session In Visual Studio


As a Senior Managed Services Developer, I find myself in this sort of conversation all the time with my Apps teammates:

“Mike, can you figure out why X won’t work?”
“I’ll need to run that in debug to be able to see what is going on.”
“Can you just look at the code and get an idea of what is happening?”
“Kind of…”

Hence, the topic of this blog.
But first, let’s step back a little further in that conversation.

“The customer says when they exit the row, the extended weight is not being converted into the correct unit of measure. They expect this value, and they are getting this value”.
(That’s an important sentence, because if it wasn’t offered, the developer would have asked for this information eventually.)

“Can the scenario be reproduced?”
(That question is what the developer truly wants to know first thing off the bat.)

“Yes and no.”
(That’s the last thing a developer wants to hear.)

“I’ll need to run that in debug to be able to see what is going on.”
“Can you just look at the code and get an idea of what is happening?”
“Kind of.”
“What does it LOOK like is happening?”
“It looks like it would be a lot easier to see what is happening if I was able to run it in debug.”

And so it begins.

In JDE, all the modules are constructed in a basic sort of way. They call it Event Rule Logic, because the logic/code is executed based on user executed events, like in an application, or events that occur within a report or a UBE.

Given the scenario above, the developer would open the application in the Form Design Aid and look at the code behind the Row is Exited and Changed event on the grid. There will be a lot of code there. The tool JDE uses to debug Event Rule code is the ER Debugger. It could be run over that event and a “watch” placed on the desired grid column or variable that is being calculated.

Stepping through the code, the developer watches the values change from what it is, to what it will be, once the event ends.

In the case of the scenario described above, the developer would discover that the value is being calculated in a call to a Business Function.

The ER Debugger can only take the developer so far when troubleshooting this type of issue. He/she can see the value before the function call and see the difference in value when the function is returned, but there is no way to tell how the value was calculated without having the ability to debug the Business Function in Visual C++.

 

Definition Time:

A Business Function is a consolidated program that can be called from multiple places, so code does not have to be reproduced in the application or UBE every time that functionality is required.

Business functions are created in two ways, but ultimately end up in the same format. Whether is a Named Event Rule Business Function or a Business Function written directly in the C programming language, they are debugged in the same way using Microsoft Visual C++.

Now we are at the meat of the story.

In order to debug a Business Function in C, a project has to be set up Microsoft Visual Studio.

These are the steps this developer follows to set up a project in Visual Studio:

    1. Open Microsoft Visual Studio
    2. The first time it opens, no matter what version, it will ask you to select a Project Template. Select Visual Studio C++
    3. From Start Screen, select New Project.
    4. Next, Select Makefile Project

    1. Enter any name (I use Default)

    1. Click OK and Blank out Default.exe (or whatever you named your project) and click OK.

    1. You’ll now have a project that looks like this:

    1. You are now ready to begin adding C Source files to your project.

    1. Select Existing Item then find the Source directory.

    1. Find the function you wish to debug and select it.

    1. Now the function is in your project and can be debugged.

There are a few more steps required to begin debugging, but the setup is complete.

The process to this point will allow you to setup a project, view the code and get a feel for the structure.

Next time, I will demonstrate the process of Attaching to the Process (Activeconsole.exe) and actually debugging a Business Function!

Happy Developing!