Template structure

Simply put, the template is organized by preset Process diagram variables, Process diagrams, and configuration files (config.xlsx files).

Process variables

Multiple Process chart variables are preset in the template, and certain naming conventions are followed:

• When adding main flow diagram variables, you can follow the naming convention: g_+ Structure type abbreviation + variable name (initial capital)
• When adding sub Process variables, you can follow the naming convention: in_/ out_ + Variable name (initial capital)

Main flow diagram variable

g_ dicConfigData —— Configuration data (Dictionary), that is, read the local configuration file config The data in xlsx (the user-defined configuration data can be Extension by itself), and then used in the global Process diagram as a global public configuration (the sub Process can be used only after input of assignment); This variable is used and assigned in the "configuration initialization" Process block, and is also used in other Process blocks and sub Process.

g_ dicTransactionItem —— Transaction items (null by default). When the template runs, it circulates transaction items with the same steps. Transaction items have the same structure but different values. For example, it circulates multiple table files with the same structure, and one of them is a transaction item; This variable is used and assigned in the "get new data" Process block and passed to the "execute Process" sub Process for use.

g_ iRetryNumber —— The number of repeated retries is generally 3 by default. If an exception occurs when processing a transaction item, you can retry the processing step, but it cannot exceed the number of repeated retries; This variable is used and assigned in the "configuration initialization" and "retry count" Process blocks.

g_ iCount —— Retry counter, the initial value is 0. If the transaction item fails to be processed and retried once, the count will be accumulated. If it is greater than or equal to g_ Iretrynumber, then it is cleared to 0; This variable is used and assigned in the "configuration initialization" and "retry count" Process blocks.

g_ bRetryStatus —— The retry status is false by default. The "retry" judgment component will check the retry status of the current transaction item. If it is true, the branch condition is true and points to the "Process execution" sub Process component, and the current transaction item starts to retry; If false, the branch condition is not valid and points to the get new data Process block component to start the execution of a new transaction.

g_ bFirstRun —— For initial operation, the default value is true; This variable is used and assigned in the "configuration initialization" and "get new data" Process blocks.

Sub Process diagram variables

inTransactionItem —— It is used to receive the transaction items input by the main process and is used within the sub Process.

inConfig —— The public configuration used to receive the main process input and used within the sub Process.

BusinessException —— Sub Process global custom business exceptions, used in combination with try/catch blocks, can be distinguished from the use of "exception dashed lines" and system variables ($blockinput).

    Try
        Log.Info("Started executing transaction process!")
        //todo something
        
        
        
    Catch Exception
        BusinessException = Exception
        Log.Error("Failed to execute [execution process]:"&CStr(Exception))
    End Try

Process chart

The template includes two layers of Process diagrams, one layer of main Process diagrams, Process diagrams organized by "Process start", six "Process blocks", three "judgments", one "sub Process" and "end" components, and one layer of sub Process diagrams, Process diagrams organized by "Process start" and one "Process block" component; Main flow diagram

Main flow diagram

The "main flow diagram" above will be described later in this section.

• Configuration initialization In the "source code" view of the Process block, the notes at the top have listed the overall step descriptions: initialize the Process diagram variables, set the global log level, and load config Configuration information and custom Extension in xlsx file.

This Process block is the first step of the main process execution. Common practices such as "Declaration pre" and "initialization" are all concentrated here. The key operation is to assign values to the global public configuration data of the main Process (that is, read the local or remote configuration data and assign them to the Process diagram variable g\u dicconfigdata). At the same time, these public configuration data must be passed into the "execution Process" sub Process as input values; When an exception occurs in this Process block (not handled by try/catch itself), if the local configuration file (config.xlsx) is lost, the Process will go to the "exception handling" Process block, and finally enter the "Process end" Process block to stop the execution of the entire Process.

• Object program initialization It is defined as the starting point of the dependent environment of the transaction Process to ensure that the target application software notified in the public configuration data is in the starting point (ready for execution) state. When an exception occurs in the "execution Process" sub Process (without self try/catch processing), it will return to this starting point under the retry mechanism, so as to ensure that the transaction retry is feasible. Of course, if an exception occurs in the Process block (without self try/catch processing), The Process will go to the "exception handling" Process block.

• First run Read Process variable G_ Bfirstrun is used to judge whether the overall cycle in the Process is running for the first time. If it is true, the Process points to the "get new data" Process block component to get new transaction items; If it is false, the Process points to the retry judgment component to perform retry logic judgment on the current transaction item.

• Retry Read Process variable G_ Bretrystatus determines whether the current transaction item needs to be retried. If it is true, the Process points to the "execute Process" sub Process and continues to run; If it is false, the Process points to the "get new data" Process block and continues to run. This "judge" component is used to skip the failed transaction items and continue the execution of new transaction items.

• Get new data Obtain new data from the specified transaction source, i.e. event item; The transaction source can be the data queue specified in the commander, the specific row specified in the excel table, the specific field data specified in the database, the specific mail in the mailbox inbox, the webapi or others that can return the same structure data, etc; If a new transaction item can be obtained, it should be assigned to the Process variable G_ Dictransactionitem. At the same time, the new transaction item will be imported into the "execution Process" sub Process as an input value; If a new transaction item cannot be obtained, that is, the "g\u dictransactionitem = null" status, the Process will point to the "Process end" Process block after being judged by the "with data" component. The essence of a transaction item is a "dictionary". If there is a Process scenario, multiple accounts need to enter the same system every day to download report data. The download steps are the same. Only the passwords of each logged in account are different. At this time, these account information can be gathered together (to ensure security) and used as a transaction source. If one of the transaction items is:

    {"UserName" : "Laiye", "Pwd" : "!@#QaWSZ2021qeWRrer2Dq2w4oL"}

After this transaction item is obtained, it is given to the Process variable G_ Assign value to dictransactionitem:

    g_dicTransactionItem = {"UserName" : "Laiye", "Pwd" : "!@#QaWSZ2020"}

In this Process block, only 2 commands are prefabricated: "G_bfirstrun = false" and "g_dictransactionitem = null"

Special instructions are required here. The above two commands cannot be deleted, otherwise the operation logic of the "template" will be destroyed. At the same time, after the new transaction item is obtained, it will be given to the Process diagram variable G_ When dictransactionitem is assigned, the order must be under the above two commands.

• Have data Read the value of the condition expression "(not isnull (g\u dictransactionitem))", that is, judge whether a new transaction item has been obtained. If it is true, the Process points to the "execute Process" sub Process and continues to run; If it is false, the Process points to the "Process end" Process block, and finally ends the entire Process gracefully.

• Execute Process In this template, the specific business operation steps are agreed to be carried out in this sub Process, such as user login, home page navigation, report query, download and other business automation logic. This is also where the RPA developers need to invest the most energy in the template.

This sub Process defines two input value parameters: intransactionitem and inconfig, which are respectively controlled by the main flow diagram variable G_ dicTransactionItem、g_ The dicconfigdata assignment is passed in. If an exception occurs in this sub Process (not handled by the try/catch block), the Process will continue to run from the "exception dashed line" to the "retry count" Process block, and execute retry logic on the current transaction item (the default retry is 3 times, and if the 3 times are unsuccessful, the Process will jump to the new transaction item to continue running the Process).

• Exception handling It is used to uniformly handle the exceptions in the three key Process blocks involved in the Process. If exceptions occur in the Process blocks of "configuration initialization", "target program initialization" and "get new data", the exception information can be obtained in this Process block through the system variable ($blockinput), which also means that the RPA's dependent environment (precondition) does not meet the requirements or the environment itself is damaged, and the Process cannot continue to be executed.

When exceptions occur in Process blocks and sub Process, if they are not handled by the try/catch block, the exception information can be obtained through the system variable ($blockinput) in the Process block pointed by the "exception dotted line"; Try/catch blocks are recommended only when you need to handle exceptions by yourself for a single or multiple commands in the process block.

There is no preset processing of exception information in this Process block, and the repair or solution of such problems requires manual intervention. If you want to notify RPA maintenance management personnel of the exception, RPA developers can use commands in modules such as "HTTP", "smtp/pop" and "Outlook" in combination.

• Retry count If the Process runs to the "execute Process" sub Process and an exception occurs inside it (without self try/catch processing), the Process will point to this Process block to continue running, that is, the Process diagram variable G_ Icount is incremented, that is, the counter of transaction item retry. If "g_icount > = g_iretrynumber", the counter is cleared, that is, G_ The Icount is reassigned to 0, G_ Bretrystatus is re assigned to false to re count when an exception occurs in the next transaction item; In this Process block, the current screenshot can be uploaded in combination with the "upload screenshot" command (enterprise version is required), and the abnormal scene can be recorded for analysis and investigation in the commander.

• End of Process The running of this template will eventually be collected into this Process block. Currently, two general information, Laiye Automation version information and Process running time, are preset to be recorded, and then point to the "end" component to complete the Process; RPA developers can Extension some statistics at the end of Process or other outputs in this Process block to meet specific RPA scenario requirements.

Sub Process chart

The "sub Process diagram" above will be described later in this section.

• Process block This Process block is the preset original "Process block". It is only a simple example of how to obtain the data in the incoming transaction items and public configurations. The specific business automation operations need to be Extension by RPA developers.

    Dim configField1 = ""
    Dim configField2 = ""
    Dim itemField1 = ""
    Dim itemField2 = ""
    Try
        Log.Info("Started executing transaction process!")
        Rem  Start the specific RPA business operation here
        
        configField1 = inConfig["key1"]
        configField2 = inConfig["key2"]
        
        itemField1 = inTransactionItem["itemA"]
        itemField2 = inTransactionItem["itemB"]
        //todo something
        
        
        
    Catch Exception
        BusinessException = Exception
        Log.Error("Failed to execute [execution process]:"&CStr(Exception))
    End Try

Configuration file

After creating a Process in the "Enterprise process template" mode, the configuration file config. can be found in the res/data directory of the Process Xlsx - contains three worksheets (global settings, constant settings, local parameters), and has preset several configuration items, which can be added according to the project situation.

The files in the res directory of the Process will be automatically packaged into the BOT file when the Process is published. If config Xlsx files can be independently controlled and maintained locally and can be moved outside the res directory, such as C: \ data \ config Xlsx. At this time, modify the document reading operation corresponding to the "configuration initialization" Process block:

    Excel.OpenExcel("C:\\Data\\Config.xlsx",True,"Excel","","")

Although the configuration file relies on the common office software excel/wps, it is convenient for business personnel to adjust the setting values at the maintenance stage of the Process, which can reduce the input of maintenance personnel.

The three worksheets in the configuration file have agreed formats, which are composed of name, value and description. If the format needs to be adjusted, it should also be adjusted in the template. It is recommended to name them with English nouns.

• Global settings Preset commanderqueuename and loglevel, corresponding to the data queue name and global log level in commander; Generally, the data queue is used as the transaction source, and the RPA developer can fill in the setting value according to the actual situation.
• Constant setting The maxretrynumber and exscreenshotsfolderpath are preset to correspond to the maximum number of retries during transaction item processing in the template and the saving path after screenshots of the current screen in case of Process exceptions. RPA developers can fill in the setting values according to the actual situation; When processing transaction items, if it is necessary to record some log information related to internal business analysis and audit, these log information usually has the same prefix. At this time, it is recommended to put the prefix part outside the "constant setting" to facilitate adjustment and maintenance.
• Local parameters Preset appsname and ukeysetuppath, corresponding to the process name of the target program and the installation path of the target program. RPA developers can fill in the setting values according to the actual situation.

Summary

After understanding the basic structure of the Enterprise process template, you will find that it is mainly used in the automation scenario of transactional Process; The "get new data" cycle obtains new transaction items, which are independent of each other, and handles exceptions and management log records in a transaction level manner, so as to provide more detailed information about each processed transaction item and make it easier to retry or finally skip failed transactions.

If you run the template directly, you will find that the running will end soon. Because there is no preset transaction source in the "get new data" Process block, the current transaction item status is "g_dicTransactionItem = Null", so the Process points to the "Process end" Process block, and the whole Process is ended.

The main function of the main process (main process diagram) is to load the global configuration, provide transaction items circularly, call the sub Process to process transaction items circularly, and control the retry of each transaction item after its execution fails according to the configuration requirements; The function of sub process (sub Process diagram) is to receive data (public configuration, transaction items) and execute specific Process steps, and it has independent operation capability.

In addition, the structure description of this template has been built into the Automation Creator application as a PDF file - Enterprise process template - User Guide.Pdf.