5 Replies Latest reply on Aug 2, 2019 9:28 AM by Bob Anderson

    TPL - Test sync mapping block

    Alex Gravel
      Share This:

      Hi,

       

      Is there a way to test a sync mapping block like a pattern

       

      i.e : run the pattern against a manual group and see the logs?

       

      Thanks

       

      Alex

        • 1. Re: TPL - Test sync mapping block
          Duncan Grisby

          Not exactly, I'm afraid. You can test it without actually syncing to a CMDB though. Put CMDB sync into debug logging mode, then use the UI to view a Host or other root node and select Actions > CMDB Sync Preview. That performs all the evaluation of the mappings, without actually talking to a CMDB. You can then see output in log/tw_svc_cmdbsync_transformer.log that shows what happened, and a complete dump of all the CI states that it wanted to set.

          1 of 1 people found this helpful
          • 2. Re: TPL - Test sync mapping block
            Alex Gravel

            Thanks for the reply ! Will do that !

             

            If I myself put some log.debug in the syncmapping pattern, will if show there as well?

             

            Thanks

            • 3. Re: TPL - Test sync mapping block
              Duncan Grisby

              Yes, it will, although when you are first testing, I'd suggest using log.error, because that way it stands out much better in the logs. Once you are happy with it and put it in production, you can downgrade the messages to info or debug.

              1 of 1 people found this helpful
              • 4. Re: TPL - Test sync mapping block
                Lisa Keeler

                Yes.

                 

                Any log.info, log.debug, etc messages in the syncmapping patterns (custom or OOTB) will show in the log/tw_svc_cmdbsync_transformer.log.

                 

                To see the log.debug messages, the CMDB Sync logging has to be at DEBUG level.

                 

                To see log.info statements, you only need INFO level logging for CMDB Sync.

                 

                Since there will be many messages in the transformer log (and since you can't use Run Pattern) so it is hard to find your messages, I commonly use a convention for my messages to include my name in uppercase and a number for the message ... it is useful when debugging a syncmapping pattern.

                 

                Example:

                    body

                         log.info("LISA 1: In the body of the Host_ComputerSystem_extension pattern");

                        computersystem := Host_ComputerSystem.computersystem;

                 

                         log.info("LISA 2: computersystem CI Name = %computersystem.Name%    host name = %host.name%");

                 

                        computersystem.Description := host.name;

                         log.info("LISA 3: computersystem.Description is now set to:  %computersystem.Description%");

                    end body;

                 

                Then, you can just do something like this from command-line to see all of your messages:

                cd /usr/tideway/log

                grep LISA *cmdb*.log

                2 of 2 people found this helpful
                • 5. Re: TPL - Test sync mapping block
                  Bob Anderson

                  Taking Lisa's logging suggestion one step further.  I always include a set of pinchers (like --> and <--) around the variable bits (%something%) just to identify cases where the variable is empty or you need to see if there is other white space in the variable bits....so, somthing like:

                   

                  log.info("LISA 3: computersystem.Description is now set to: -->%computersystem.Description%<--");

                   

                  I also tend to use the pattern name or function name as the first part of the message as a tag as to why I logged the message, so something like

                  log.info("::::pattern_or_function_name : message to be displayed : -->%variable_data%<--");

                   

                  And as Duncan pointed out, in early development, use log.info or even log.error so you don't need to set logging to debug in have zillions more logging messages to filter through.

                   

                  Note: the grep Lisa suggested works great for singe line log entries.  If your logging message includes data with multiple lines, you will only get the first line as the next line(s) of data in the log will not have the logging timestamp prefix

                  1 of 1 people found this helpful