Dev 101 Part II: Debugging A Business Function In Visual Studio
In Part I of this blog, we walked through setting up a project in Visual Studio, so a business function can be “Debugged”.
Refresher: Debugging is running an app, UBE or Business Function (code) through a tool that allows the developer to see the logic and calculations take place, line by line, in real time, in order to discern where a problem is located.
We discussed how an application can be debugged using the ER Debugger Tool in JDE, but when an app or a UBE calls a Business Function that is not working as desired, and the developer needs to find out why in order to correct it, a Visual Studio Debug Session is what is needed.
As a VERY simple example, I’ve created a Demo App that calls a VERY simple Business Function. There is a problem in the application and the ER code does not provide any answers. Therefore, we get to debug in C!!! (Only developers will get excited about that…)
As you can see, the instructions for the app are simple.
The user enters a number into the Inbound Parameter box and clicks the button. If all goes well, a message will appear if they enter a ‘1’, and a different message will appear if they enter a ‘2’.
If any value other than ‘1’ or ‘2’ is entered, the program will explain why this is not correct. 🙂
The App Demo:
Being a good tester, I test what SHOULD work, before testing what might not work.
It’s good to start things off on a positive note.
I enter a ‘1’ and click the button.
Ah. Positive reinforcement is always good.
Next test. See if entering a ‘2’ results in a different message.
Oops. The instructions indicated a different message would be presented, but it said a different POSITIVE message. Something is amiss.
While the app DID let the user know that the functionality is incorrect, the error description could be a bit more specific. Deeper investigation is required.
One more test to see what happens.
I give the program something it won’t expect and see how well the “Help” explains how to correct the issue:
Well, again, the app DID let the user know that the functionality is incorrect…
Next, we get to open the application up in Form Design Studio and see what is going on.
Looking at the ER behind the “Get Message” button, we see that it is calling a Business Function, ECS – Return Values.
We open the function call and verify that the correct parameter is being passed in to the function as indicated by the direction arrows, and that the remaining logic that decides what message to display is dependent on what the function returns.
The “VA evt_cOutBoundVariable_EV02” always receives what is returned from the function, so the error must be in the function.
Referring to Part I of this blog, the developer would then BusBuild the function in JDE, then add the function to their project in Visual Studio C++
Reviewing C Code and Running Debug
As stated, I’ve followed the guidelines in Part I and opened my project in Visual Studio and added the B59DEMO function to the function list.
Scanning the code, a good programmer would be able to see the problem without using debug.
For the rest of us, we will go ahead and run this in debug. 🙂
These are the steps to begin a debug session in VS C++:
- Having opened VS and added the function, place a “Breakpoint” at the desired line you would like the program to begin debugging. Do this by setting the cursor to the line and hitting ‘F9’ on your keyboard.
- Before opening the application, click on ‘Debug’ on the Menu Bar and select: “Attach to Process”
- This window will appear. Ensure the “activeconsole.exe” line is selected and click, “Attach”.
- The window in VS C++ will adjust to Debug View and we are now in Debug!
- Return to E1 and run the application. Go to the scenario you KNOW doesn’t work first. No use debugging what you know works in this case…
- The process is now in debug, and we have stopped on the first line of the function. Notice that the Inbound Parameter is, indeed, a ‘2’ and the Outbound Parameter is ‘ ‘, blank.
- Stepping through the code, the issue becomes apparent.
There is no logic that accounts for an Inbound Parameter of ‘2’. There is no error, per say, but the function is returning a BLANK because there is no code that populates the outbound variable if the inbound parameter is ‘2’!
- We know from the ER Code, that if the function returns an error, or the return parameter is blank, we get our “descriptive” error message.
We now have enough information to correct the bug and test.
Go back to the menu bar and select “Stop Debugging” to end the debug session.
Correcting Code and Retesting
Edit the function to correct the “If” Statement like this:
Save the function, then build it by running it through Busbuild.
Run another test.
We see now that the function is corrected, and the application gives the user the second Positive Message!
That concludes this blog entry. I hope you take from this basic demo/example, a positive message: Debugging is not as complicated as it may seem and the more you do it, the easier it gets!!!