Debug in the WebMethods

The most common thing to do in program development is debug, which is also true in WebMethods. Mastering the effective debug method can improve the efficiency of the program development, while knowing more about the debug mode makes the bug ubiquitous.

Here I list a few common debug methods.

One, the most commonly used single-step debugging and trace.

In developer, the shortcut key for single-step debugging is F6,trace is F5. I found that the program is wrong when the first to use the wrong way is to run the program with Trace, when the program ran to an unusual place, trace will be interrupted, and can leave a running flag. We can see exactly where the error is. Then we can take out a single-step debugging, trace to the vicinity, and then step by step in, to see what the value of pipeline inside, whether it is logical.

Second, the specification: Try-catch

We can try to catch this exception by using Try-catch when we find that there is an exception to the program. By analyzing the exception information in the GetLastError, it is possible to find out where and why the anomaly occurred. Of course there is no reason to analyze the situation, which requires rich experience and logical reasoning ability. Try-catch is also a very important specification when writing programs, because once an exception occurs, we do not want the program to break, but let the program run, but the exception information needs to be kept to us to view. The advantage of this method compared to trace is that the debug time is short because we just need to run the program directly. Try-catch is a good tool when we want to debug a very long code, or if we want to do a cycle.

Third, Pipeline debug

This method is very effective when using the Invoke invoke program. First, we need to set the service's pipeline debug value to save, then run the program, then go back to pipeline debug to restore (override) after running the program, and then run the program that needs to be debugged separately. This time pipeline will save the last parameter we used to run the program. In addition to this setting, we can also use the Savepipeline and Restorepipeline methods in Wmpublic/pub/flow. This method can be very useful to help us debug a program that cannot be accessed with one-step debugging.

Iv. Debuglog

In addition to the Savepipeline and Restorepipeline methods just mentioned, there are Debuglog methods in Wmpublic/pub/flow. This method sends a message to the server's log-server when it is called, and through this message we can know if the program has run to that location. This method is useful in some cases, for example: when we call the service of the IS on the remote client, we may not know if the program is called, and if we add the Debuglog method to the program, we can go to the log of the server to find the message we reserved. , the call was successful when we found it.

Five, small tricks

In the process of debugging we can use far more than these, for example, we want to detect if a parameter exceeds a certain number of digits will not affect the time, we can directly hardcode this parameter to debug, or if we can't find where the error occurred, We can find a reference to this program to see if there have been errors in some of the references, and there are some common methods that could bring bugs, and we can figure out how to run it directly, and of course, there is a good tip--ask experienced colleagues.

Debug in the WebMethods