In this video, Mark and I discuss the new features of ‘Debug‘ in Scribe Online.
Previously, the debug feature let you run a map, and use the ‘next’ button to step though each block of a map and view the values that are in scope. This was useful, but it was slow.
Now debug lets you set breakpoints very much like modern IDE environments. This lets you have debug run until certain conditions arise making it a more efficient process, because you don’t have click ‘next’ to go through each and every block in your map to find the value or issue you are looking for.
With the introduction of breakpoints, we have added to debug the flexibility you have been asking for. Breakpoints can be conditional as well as active or inactive depending on your needs. Debug can be paused and continued as need just like Visual Studio.
Finally, you can now use debug to reprocess failed records. This lets you step through a record that caused a failure in as much detail as you need to troubleshoot the problem.
Here are some important things to remember when debugging.
- Scheduled maps—debug begins with values from the first source record found and processes all records in order.
- If a scheduled solution is scheduled to run while you are in debug mode, the solution does not start until you stop debug mode.
- Event-based message maps—debug queries your source and uses the values for the first record found.
- Event-based request/reply maps—debug processes the map using the values from the sample value column of the wait for request block.
- When running in debug mode, other users see the status for this solution as ‘in progress‘.
- Batch processing is deactivated when running in debug mode.
- Debug does not update the value of the most recent record processed for the solution. For example, if you have a solution with a query block configured to select all the records that have changed since the last time the solution ran, running a solution in debug mode will not update that latest record date processed.
Useful link: Debug Help