laiye rpa
streamline your operations, improve productivity
when running a process in laiye rpa, we always hope for a successful result. however, sometimes the expected results are often not achieved, especially for novices. laiye rpa can either report an error when running, or simply let the program run without results. at this time, you need to debug the program.
program debugging is the process of correcting grammatical and logical errors by manually or automatically testing the compiled program before it is put into actual operation. it is an essential step to ensure the correctness of computer software programs.
in fact, we have already used the simplest, most common, and most practical method of program debugging before: the "output debugging information" command. add the output debugging information on the previous or next line of the key code to check whether the parameters and return values are correct. strictly speaking, this is not a method of program debugging, but it can be used to test and eliminate program errors. it is also an important supplementary method in some cases where debugging is not supported.
this section will introduce the "real sense" program debugging method, which can accurately locate the cause and location of the error based on the error information prompted and the runtime variables monitored.
first of all, we must clearly realize that: a program is a means of implementing processes in the human brain to programming tools; program debugging is essentially a way to help clarify the human brain. therefore, in the process of debugging, the human brain must be clear, so that problems can be quickly and accurately located and resolved.
calmly analyze and think about the prompt messages related to program errors.
be open-minded and avoid dead ends. if a method has proved to be unworkable, you need to try another way of thinking.
avoid aimless temptation, which is to purposefully reduce the scope of the investigation, and ultimately locate the wrong place.
debugging tools are just auxiliary methods to find the location and cause of the error. using debugging tools can help you clarify the data flow logic in the program, which can assist thinking, but it cannot replace thinking. when solving actual problems, you still need to make correct judgments after thinking according to the debugging prompts.
do not just stop at correcting a mistake, but instead think about the essential cause of the mistake. did you write the wrong name carelessly? or did you use the wrong command? or is there a problem with the process design? only when the essential cause of the error is found can the error be circumvented fundamentally, and similar errors will not be made in the future.
first of all, we must be very clear about the business process of the system. business generates data, and data reflects the business. the operating logic of the program also represents the operating process of the business and data. when an error occurs, you should first think of and know the business processes and data on which this problem occurs.
for example, let's say when you click the "submit" button, an error occurs in the form submission. at this point, you should think about: what data transfer occurred after clicking the "submit" button? then according to the error message, speculate where the error may have occurred in the process of business data flow, so as to determine the location of the breakpoint we debug.
add and remove breakpoints
in the "code view", to add a breakpoint, click to the left of the line number for any line of code. click this location again to delete this breakpoint.
figure 63: adding and deleting breakpoints
commissioning
click the "debug run" or "debug run full process" menu item in the "run" menu or "run" toolbar to debug the running program. the difference between the commands is that one just debugs and runs a single process block, and the other is debugs and runs the entire process.
figure 64: debug operation menu item
figure 65: debug run toolbar
single step debugging
when debugging is running, the program stops at the first breakpoint, and the four common debugging operations are listed in the debugging status bar: continue to run (f6), step over (f7), step into (f8), step out (f9). "continue to run" means to continue to the next breakpoint; "step over" means to continue to run the next command; "step into" means to continue to run the next command, if the next command is a function, then enter function, stop at the first command in the function; "step out" means to jump out of the function of this layer and return to the previous layer.
the bottom left of the debugging status bar lists the values of the variables of this process block. when the program runs to the breakpoint, the next step of debugging is performed. at this time, special attention needs to be paid to observe whether the data at each step of the program is processed by the business process. correct data to judge whether the program is executed correctly. these data include input data, return data, etc. if the program does not enter the breakpoint we set in advance, then it is necessary to re-estimate the location of the error based on the error information and business process flow logic, and reset the breakpoint. in the end, we will continue to refine and dismantle a big problem, and finally locate the wrong point accurately.
figure 66: single-step debugging
the bottom right of the debugging status bar lists a list of breakpoints in this process block. you can enable, disable, and delete breakpoints as needed.
figure 67: breakpoint list
tips for breaking points
the general method and location of the break point are:
break the program at the first line of the logic program where the error may occur.
break the program breakpoint in the line where the error is most likely to occur.
source code version control is a very important engineering method in software development. it can save the historical version of the code and can trace back to the code progress of any time node. version control is a necessary means to ensure the normal progress of the project. for beginners, it is recommended to start source code version control at the beginning of a small project, which will be of great benefit in future work.
laiye rpa does not integrate git, svn and other third-party source code version control software, but provides laiye rpa native version control: "timeline". the timeline refers to the version of the code at different points in time.
save the timeline manually
the "save timeline" button appears on the toolbar's "timeline". click "save timeline" to save the code. when saving the timeline, you need to fill in the remark information to describe what content of the code was modified at that time.
figure 68: save timeline
automatically save the timeline
if the user does not remember to save the timeline, it is not a problem, since laiye rpa automatically saves the timeline every five minutes. if the user does not modify the code during this time, the timeline will not be saved.
view the timeline
click the "timeline" button on the toolbar, the "timeline" page lists the saved time points according to "today", "within seven days", and "earlier". click any time point to view the current file and the difference of the content of the selected point-in-time file will be marked with a red background.
if you want to restore part of the code in the timeline, you can directly click the blue arrow in the code comparison box to directly restore the code to the existing code.
figure 69: timeline comparison code
on the "timeline" page, click on the details of the note at any time point to view the detailed information of the note at that time point, as shown in the figure:
figure 70: view timeline notes
on the "timeline" page, click the restore button at any time point to restore the code content of the timeline to the existing code. at the restored time point, there will be a green r mark in the upper left corner, indicating revert, move the mouse to the r mark, it will display the specific time point from which time point to restore.
figure 71: recovery timeline
the idea of modularity has long existed in many industries and is not unique to computer science.
for example, the construction industry has long proposed the concept of modular construction, that is, prefabricating various house module components in the factory and then transporting it to the project site to assemble various houses. the modular components are prefabricated in the factory, which facilitates the organization of production, improves efficiency, saves materials, and is less harmful to the environment. the module construction is simple, fast, flexible, clean, and environmentally friendly.
as another example, the functions of modern electronic products are becoming increasingly complex, and the scale is getting increasingly bigger. using the functional decomposition and combination ideas of modular design, you can choose modular components (such as integrated circuit modules) and use their standardized interfaces to build a complex functional electronic system. modular designs can speed up the development cycle, and the modular components tested have greatly improved the reliability of the electronic system. the standardized and universal components make the system easy to build and maintain.
in short, the idea of modularization is to decompose the product into several functional modules on the basis of functional analysis of the product.
the blocks are then assembled to form the final product.
modular programming is a software design technology, which breaks the software into several independent, replaceable modules with predetermined functions. each module realizes a function, and the modules are combined through an interface (input and output part) to form the final procedure.
almost all high-level programming languages support modular programming, but the supporting technologies and terms, such as subprograms, procedures, functions, modules, and packages, may vary. we will collectively refer to these as "functions" below.
function construction generally involves the following:
function call and return: call is to request the execution of the function, and the control should be returned to the caller after the function is executed.
parameters: equivalent to the input data required by the function. generally, you need to declare the parameters in advance, and provide specific parameter values when calling.
return value: equivalent to the output data of the function.
the prefabricated parts in laiye rpa are a typical example of modular programming. laiye rpa currently has provided more than 300 prefabricated parts, covering the operation of mouse and keyboard, various interface elements, automated operations of common software, data processing, file processing, and all aspects of network and system operations. these prefabricated parts are modular and relatively independent, but can be combined to complete complex functions.
in addition to the prefabricated parts in laiye rpa, users need to pay attention to the rational arrangement of processes and process blocks when writing their own processes and process blocks, as this is also an important application of modularization. as mentioned earlier, laiye rpa does not specify how detailed a process block should be. a process block can have many commands, or just have one command. when all business processes are put in one process block, if the business process is not complicated, it works out. however, when the business process is more complicated, there can be many disadvantages: large chunks of code, unclear logic, inconvenient debugging, and difficulties in judging emerging problems. therefore, for business processes, we strongly recommend putting relatively independent business processes together into independent process blocks, and complete complex business processes through data transfer and cooperation between process blocks.
in addition, you can also extract some common functions into independent process blocks and make it a plug-in for others to call. we will discuss extension plug-ins in the next chapter.