Tips & Tricks - Handling Error Messages and Debug Info

When a Data Migration job fails, you will normally see the error-rows from menu path Execute Job/folder Details.
The error-message is generated by Business Logic, and will normally be the same as you'd see if you manually entered data from the client.
Below you will find recommendations for the most frequent error-alternatives.
Sometimes it is difficult to understand the reason for the error-message. It might help to start the clients Debug Console with the Trace_SYS option and restart the job.
Below you will find explanation of the trace information as well.

Contents

File Job Errors

The error info may look like this. You will see the File String, formatted Attribute String and Error Message for Business Logic. How the migration job behaves on errors depends on the Rules IGNOREADERROR and IGNOREXEERROR

These are the main scenarios :

 

  1. Create an Output Channel for a text file

2. Search in the context of 'Detail' tab for lines which are not OK.


3. Temporarily hide all the columns except for 'File String' using the 'Column Chooser'.

4. Since only the non executed lines are listed now, output 'All rows' from the channel.

5. RMB on the column header and 'Reset Current View'

6. Fix errors in the file

7. Clean Up the details in the execute job window and 'Start Online' the job again

Source Job Errors

If errors occur, you may see error rows from menu path Execute Job/folder Details.

  1. Double-click on column Attribute String, and it will appear formatted in a pop-up window.
  2. Double-click on column Error Message, and it will likewise appear in a pop-up window.
  3. If you can fix the cause of the error (missing basic data, missing Source Mapping), you may
    Restart the job (RMB 'Restart Online') after the fix is applied.
  4. If the error cannot be fixed as described above, you may remove error-lines by RMB Clean Up.
    When selecting this option, the lines cannot be reprocessed.
  5. When you Restart the job, Data Migration will start with moving the error rows from this LU (IntfaceJobDetail)
    to the history LUs IntfaceJobHistHead and IntfaceJobHistDetail.
  6. When the dynamic SELECT-statement is built, it will be similar to the previous, except for the WHERE-clause.
    The mapped ROWID from SourceMapping has been stored in column SOURCE_ROWID on INTFACE_JOB_DETAIL_TAB
    and later on INTFACE_JOB_HIST_DETAIL_TAB.
    Now it is used to create a sub-query that replaces the original WHERE-clause.

Understand Debug info

When executing a File Job, the debug options are not so many. Normally, you will see the attribute-string that caused the problem, and trying to enter similar data manually from the client will very often reveal the cause of the problem.

When executing a Source Job (procedure = MIGRATE_SOURCE_DATA or REPLICATION), there is a great variety of possible causes for the problem.

To view a trace of how the migration job progresses,

Open the debug console before starting the migration job from client. After the job runs, select the entry for Server Invoke of Intface_Header_API.Start_Job procedure. In the bottom tab pane, select the pl/sql trace and filter for 'Trace' and 'Application'


The list below explains each step in an example flow (blue text=Trace Messages, black text=Explanation):

TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTING CONNECTED JOBS
                                                                    
Job #1 for a Connected Job is executed here
TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTING JOBS BEFORE LOOP
                                                                    
Methods with Action=BeforeLoop are displayed here
TRACE >>>>>>>>>>>>>>>>>>>>>>> BUILDING SELECT STATEMENT
                                                                    
Dynamic SELECT is built, based upon the setup and Mapping
TRACE >>>>>>>>>>>>>>>>>>>>>>> BUILDING DYNAMIC PL-TABLE
            TRACE >>>>>>>>>>>>>>>>>>>>>>> Exec_Seq_
            REPL_CRITERIA : XX
                                                                    
Each entry in the MethodList is loaded into a table in memory.
                                                                    
You see the sequence-number from the method list (Exec_Seq_) +
                                                                    
Replication Criteria (XX=NO REPLICATION, other alternatives are COMPANY or CONTRACT).
            MODIFY ATTR :
            KEY ATTR : PART_NO
            Get_Objid_Stmt BEGIN SELECT objid, objversion INTO :objid, :objversion FROM PART_CATALOG WHERE PART_NO = :PART_NO; End;
                                                                    
For standard New/Modify, there will be one row in the table for each method.
                                                    First the MODIFY data is loaded into the table, and the 3 items above are important here.
                                                    MODIFY ATTR is the attribute string based on what columns are checked for OnModify in MethodListAttributes
                                                    KEY_ATTR contains the columns from the MethodListAttributes that have Flag equal P or K
                                                    Finally, you see the statement generated to fetch objid/objversion for update. Note that key-values
                                                    are parsed as bind-variables

            NEW
            NEW ATTR :
                                                    Second,  the INSERT data is loaded into the table. Main issue here is the attribute string.
            OTHER ATTR :
            ARGUMENT ATTR :
                                                    For procedure calls besides New/Modify, the IN-parameter for the procedure
                                                    will appear in ARGUMENT_ATTR. If one of the arguments is an Attr-string,
                                                    the items of the attribute string is shown in OTHER ATTR.
                                                    (As specified in MethodListAttributes)
           
TRACE >>>>>>>>>>>>>>>>>>>>>>> START FETCHING DATA FROM SELECT
            DBMS_SQL.Fetch_row_
                                                    The dynamic SELECT has been executed and now we start to process the rows returned.
                                                    Row-number (Fetch_row_, selected order) is displayed
            After column LOOP, SELECT attr_ :
                                                    The data for each returned row is converted into an attribute string
            MASTER Key
                                                    If you use the OnMasterKey-option from the Method List, you can check the concatenated
                                                    values of the Master-columns here.
                                                    More of this under Advanced Method List setup

TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTE METHOD LIST
            Dyna count_
                                                    Now we start executing the methods in the PL-table.
                                                    The Dyna_Count_ variable tells us how many methods that will be executed for each selected row.
                                                     Remember that Insert and Modify are separate rows in the table,
                                                    so the value in Dyna_Count may be twice the number of methods in MethodList.

            TRACE >>>>>>>>>>>>>>>>>>>>>>> Checking method no

                                                    Checks if this is a standard update/insert or a stored procedure.
        
MethodList.column_name(i)
            MethodList.column_value(i)
            Selected column value
                                                    If you have specified ColumnName/ColumnValue in the MethodList, here is the comparison
                                                    between specified value and selected value. Mismatch will skip this method

            Method MODE UPDATE
            Send key-values to cursor :
            Objid/objversion found/not found :
                                                    Modify is executed first. The Get_Objid_Statement (above)
                                                    is executed with parsed key-values from the select.
                                                    Modify/New is executed depending on whether objid/objversion is found,
                                                    i.e. the row already exists or not.

            Method MODE INSERT
                                                    Here the row does not exist, and method New__  will be executed
            REBUILD method_attr for view <view_name>
                                                    Here you can see the empty attribute string belonging to this method.
                                                    This attribute-string is compared with the SELECT-attr, and.....
            REBUILD OUT_attr :
                                                    ..here you can see the attribute-string with values.
            Method Statement
                                                   Displays the method statement that will be executed.
            RETURN attr:
                                                   With normal termination of the method, you will see the content of the attribute-string
                                                   that is returned from the method (if any)

            Method XXX failed :
            ROLLBACK to SAVEPOINT new_method_
                                                                   
If the method fails, the error message will be displayed +
                                                   ROLLBACK will be performed. In this case, all methods executed for this row
                                                   will be rollbacked, and the job will continue on next row,
                                                   because Rule IGNOREXEERROR=Active.

            TRACE >>>>>>>>>>>>>>>>>>>>>>> JOB ABORTED -
                                                   If you get this trace message, Rule IGNOREXEERROR=Inactive,
                                                   i.e. the complete job rollbacks when first error occurs.

TRACE >>>>>>>>>>>>>>>>>>>>>>> EXECUTE METHODS AFTER LOOP
                                                                    
Methods with Action=AfterLoop are displayed here
TRACE >>>>>>>>>>>>>>>>>>>>>>> JOB CLOSES NORMALLY WITHOUT ERRORS
                                                                    
The complete job executed without errors
TRACE >>>>>>>>>>>>>>>>>>>>>>> JOB CLOSES NORMALLY. ERRORS HAVE OCCURED
                                                    Rule IGNOREXEERROR=Active, and errors have occurred

 

Debug info after App7 SP3

The item-names on the attribute string from the SELECT-statement will no longer be column name from the SourceMapping, but from now on it will be Pos prefixed with hash as shown below.

TRACE >>>>>>>>>>>>>>>>>>>>>>> START FETCHING DATA FROM SELECT
#10^015^#20^TRLY2307950035^#30^SPRING^#40^Make Onhand Analysis^         

On start of the job, each methods individual attribute string has been pre-mapped with hash+pos in FixedValue :

REBUILD method_attr for view INVENTORY_PART :
DESCRIPTION^#30^ONHAND_ANALYSIS_FLAG^#40^

Now, we can easily match item name from SELECT and build the final attr-string :

REBUILD OUT_attr : DESCRIPTION^SPRING^ONHAND_ANALYSIS_FLAG^Make Onhand Analysis^

The benefit of this will be :

  1. The SELECT-attr will become much shorter and also easier to fetch data from.
  2. Each methods attr will only contain items that are mapped in Maintenance Job/SourceMapping.
  3. Direct reference between item-name on SELECT-attr and each individual attr makes processing faster