Share This:

 

 

Logging Table

$AR_SYSTEM_HOME default is "/opt/bmc/digitalworkplace"

 

Problem Area

Logging
Location
ITSM/SRM integrationCombined API/SQL/Filter logging while reproducing the problem, arerror log, remote action log

$AR_SYSTEM_HOME/db

$AR_SYSTEM_HOME/log

Workflow DesignerBundle log, F12 Browser Developer Mode/process log$AR_SYSTEM_HOME/db
UIBundle log, Jetty log, F12 Browser Developer mode & Fiddler$AR_SYSTEM_HOME/db
ConnectorsBundle log, arerror log, F12 Browser Developer mode, Connector logging$AR_SYSTEM_HOME/db
ReportingBundle log, arerror log$AR_SYSTEM_HOME/db
DWP Client Integration

Bundle log, UX debug on the MyIT side, F12 Browser Developer mode & Fiddler
DWP Catalog debug level

$AR_SYSTEM_HOME/db

$DWP_HOME/Logs/dwp-catalog.log

ApprovalsCombined API/SQL/Filter logging while reproducing the problem, remoteaction.log, bundle.log, arerror log

$AR_SYSTEM_HOME/db

$AR_SYSTEM_HOME/Logs

Installationarsystem_install_log.txt, startup logs

$AR_SYSTEM_HOME/Logs

/tmp

Post Install scriptsarerror log, post install log

$AR_SYSTEM_HOME/db

$AR_SYSTEM_HOME/Logs

RSSOarjavaplugin & bundle log, rsso agent logs, rsso debug$AR_SYSTEM_HOME/db
User Group Syncuser synch log, debug log combined api & SQL logging

$AR_SYSTEM_HOME/db

"/src" directory

 

Catalog File System

 

Most of the Catalog related files are contained within the "digitalworkplace" directory, some of the more important directories and files are highlighted in the following illustration

 

 

OSGI Console

 

The Catalog application is run through a variety of different bundles which are loaded once the "dwpcontroller" script is run as part of an platform restart. Unlike the DWP Client, we cannot restart the individual components of the Catalog (without negative consequence) however we can check the Catalog's bundle status by using the Eclipse OSGI Console (Open Services Gateway Initiative).

 

The logging level for OSGI is controlled in the  "$AR_SYSTEM_HOME/conf/config.properties" file

 

 

# Enable osgi console for debugging

osgi.console.enable.builtin=true

osgi.console = 12666

To connect to the console you simply telnet to the Catalog host and execute the "ss" command.

 

[root@clm-aus-123]# telnet localhost 12666

Osgi>ss

Some of the more important Catalog related bundles can be identified by "myservice"

 

If you notice any of these bundles are in a "RESOLVED" state you can attempt to restart as follows:

 

Stop "ID#"

Start “ID#”

In the event the Catalog login page becomes unavailable for all users, restart the "com.bmc.myservice.uiservice-war_0.0.1" and try again. If you are still unable to log in please raise a case with BMC Technical Support. Type "disconnect" to end the session !

 

The connectors and bundles are held within the $AR_SYSTEM_HOME/deployedsmart bundles directory.

 

com.bmc.arsys.myitsb.myitsb-approval-1.7.1.jar

com.bmc.arsys.rx.approval-17.5.0-SNAPSHOT.jar

com.bmc.arsys.rx.assignment-17.5.0-SNAPSHOT.jar

com.bmc.arsys.rx.dataload-17.5.0-SNAPSHOT.jar

com.bmc.arsys.rx.foundation-17.5.0-SNAPSHOT.jar

com.bmc.myservice.bundle-1.0.00-SNAPSHOT.2567-dev.jar

com.bmc.myservice.connect.ad-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.aws-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.azure-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.bao-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.clientmanagement-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.clientmanagementmobile-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.clm-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.cmdb-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.cmdb-api-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.flexera-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.hrcm-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.innovationsuite-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.jira-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.msoffice-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.remedy-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.rest-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.xenapp-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.xendesktop-19.5.0-SNAPSHOT.514-dev.jar

com.bmc.myservice.connect.xenmobile-19.5.0-SNAPSHOT.514-dev.jar

 

 

DWP Controller Scripts

 

The "rxscripts" directory and sub-directories contain many scripts which are called by the Catalog but in some cases you may also run them manually.

 

/bin/check_migrations.sh        Checks migrations

/bin/create_schema.sh             Gets called by the post install script

/bin/current-user.sh                  Checks the current user who’s in the current session

/bin/tenant/find.sh                     Lists all the tenants

/bin/tenant/delete.sh                 Deletes a tenant

/bin/connector/refresh.sh         Refreshes the available connectors

/bin/healthcheck_core.sh         Checks if the Catalog is up or down

/bin/login.sh                               Used to log into Remedy from the command line

/bin/run_migrations.sh             Get's called when DB migrations are required

/bin/setenv.sh                            Sets up the environmental variables to allow the API endpoints

/bin/tenant_seed.sh                  Get’s called by the post install script

/bin/version.sh                          Get's current version by running

/bin/service/search.sh              Lists all catalog services visible by the current DWP user

/bin/process_def                      Remove/find workflow

In order to run these scripts you need to set up your environmental variables by sourcing the "setenv.sh" script

[root@clm-aus-123 bin]# source setenv.sh

 

Once you source the "setenv" script you then need to log into the Catalog from the command line and generate an authentication cookie. Once the mycookies key is generated subsequent scripts (provided they are in the same directory as the mycookie.txt) will run.

 

[root@clm-aus-123 bin]# ./login.sh hannah_admin@coffee.com password

 

eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0NjI0NzMzNjAsIl9pbXBlcnNvbmF0ZWRVc2VyIjpudWxsLCJzdWIiOiJlSHVDUXo5ZUliUFg1UmtxaTlZUkZIMTQwbjhpWXd5SDhkc2FtdmhcL3VMZDF1dzBjbXg5UVM3Y2F2Wm85bWplR1o1T2tRMVE0MFRrQVRmY3lFdUd4Y0V6TGtVTjA0aldieVF3MDZUMGVlVkFcLzhRSEZ0ekpTVHc9PSIsIm5iZiI6MTQ2MjQ2NjA0MCwiaXNzIjoiY2xtLWF1cy0wMTQ1MjciLCJqdGkiOiJJREdBQTVWMEdFTUJDQU9HUFFFQUFBMjQ2MlgzUFciLCJfY2FjaGVJZCI6MzIxOTE2LCJpYXQiOjE0NjI0NjYxNjB9.CHebPeTu8y3JLFnIU8IjozKONMSA28xaaam9ww-e2Gg

 

[root@clm-aus-0123 bin]# ls -lrt

-rw-r--r-- 1 root root   610 Jun 15 14:59 mycookies.txt

 

In the following example I'm running the "find.sh" script to obtain information about a problematic tenant. We can also delete and recreate a tenant using the post install scripts (be careful deleting..)

[root@clm-aus-123 bin]# tenant/find.sh

{"totalSize":1,"data":[{"name":"coffee","domainIdentifier":"coffee.com","tenantId":"f53893b1d382","databaseName":"ARTenantCoffee","status":"Enabled","overlayGroupId":"f53893b1d382","activationStatus":"Completed"}]}[root@clm-aus-0123 bin]#

[root@clm-aus-123 bin]# tenant/delete.sh coffee   

 

Stopping & Starting the Catalog

 

We use the "dwpcontroller" script from the $AR_SYSTEM_HOME directory to restart the Platform and Catalog application

This script also restarts the Platform

[root@clm-aus-0123 digitalworkplace]#./dwpcontroller [-u $user_name] [-p $password] <stop|start|restart>

 

The "start" option calls “/sb/start.sh” which does the following:

 

  • Runs “$AR_SYSTEM_HOME/bin/arsystem start”
  • Checks if the DB/Port is up
  • If the DB is up it calls another script which checks the bundles status
  • If bundles are up another migration script runs which checks the DB to see if anything has changed (such as JARs) and may update a column or add a new table.

 

logback_server.xml debug

 

Logging level is controlled within the "logback_server.xml" which is located in the $AR_SYSTEM_HOME/conf directory

 

Please backup the logback_server.xml before making any changes, XML mistakes may impact the Catalog on start-up.

level=all    Best level of debug but can impact performance

 

      

  <appender name="BUNDLE" class="com.bmc.arsys.logging.ReconfigurableRollingFileAppender">

                <file>${com.bmc.arsys.homedir}/${com.bmc.arsys.server.dbdir}/bundle.log</file>

                <append>true</append>

                <rollingPolicy>

                        <fileNamePattern>${com.bmc.arsys.homedir}/${com.bmc.arsys.server.dbdir}/bundle.log.%i</fileNamePattern>

                        <minIndex>1</minIndex>

                        <maxIndex>10</maxIndex>

                </rollingPolicy>

                <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">

                        <maxFileSize>99MB</maxFileSize>

                </triggeringPolicy>

                <!-- Extra param to say log file creation at startup -->

                <needPreLoading>true</needPreLoading>

                <encoder>

                        <pattern>%d{MM-dd HH:mm:ss.SSS} %-4le %c %m%n</pattern>

                </encoder>

        </appender>

 

 

From 19.02 + you can control Catalog logging from the settings page:

 

RSSO debug can be written to the bundle log by adding the following lines under the existing bundle section.

       

   <logger name="com.bmc.rsso" level="DEBUG" additivity="false">

                <appender-ref ref="BUNDLE" />

        </logger>

 

RSSO logging is enabled by making the following two changed to the  the $AR_SYSTEM_HOME/pluginsvr/log4j_pluginsvr.xml file

 

<logger name="com.bmc.arsys.pluginsvr">

<level value="debug" />

</logger>

......

<root>

<priority value ="error" />

<appender-ref ref="PluginLog" />

</root>

 

RSSO Diagnostics

 

Starting with 19.02 we have a new diagnostic tool which checks RSSO configuration is correct. This tool is located in the $AR_SYSTEM_HOME/sb/configure_rsso directory. To run open the "run_diagnostic.sh" script and make sure it's the paths and diagnostic file name is correct:

 

#!/bin/bash

 

# Path to Catalog directory.

#catalog_home=/opt/bmc/digitalworkplace

catalog_home=/opt/bmc/digitalworkplace

 

DIAGNOSTIC_JAR=rsso-diagnostic-1.0-SNAPSHOT.jar

 

if [ $# -eq 0 ]; then

  params=("${catalog_home}")

else

  params="$@"

fi

 

if [ "X${JAVA_HOME}" = "X" ]; then

  JAVA_EXEC="java"

else

  JAVA_EXEC="${JAVA_HOME}/bin/java"

fi

 

${JAVA_EXEC} -jar ${DIAGNOSTIC_JAR} ${params[*]}

~

Once run the output should look like this:

 

[root@clm-aus-123 configure_rsso]# ./run_diagnostic.sh

05:13:11.164 -

Common validations:

05:13:11.167 - All RSSO agent jar files are in place in '/opt/bmc/digitalworkplace/deploy' and '/opt/bmc/digitalworkplace/pluginsvr'

05:13:11.167 - All RSSO agent config files are in place in '/opt/bmc/digitalworkplace/conf'

05:13:11.167 - Your RSSO agent version is '9.1.03.001'.

05:13:11.167 - It is recommended to have RSSO agent of version '19.5'.

05:13:11.167 - Your RSSO server version is '18.05.00'.

05:13:11.167 - It is recommended to have RSSO server and agent of same version.

05:13:11.167 -

Validating 'rsso-agent.properties' file in '/opt/bmc/digitalworkplace/conf':

05:13:11.168 - agent-id is dwpid

05:13:11.168 - Agent id should be the same on all DWP-Catalog nodes

05:13:11.168 - sso-external-url is http://<servername>:8080/rsso

05:13:11.168 - HTTPS is recommended for external URL

05:13:11.168 - sso-service-url is http://<servername>:8080/rsso

05:13:11.168 - http://<servername>:8080/rsso is accessible

05:13:11.169 -

Validating 'rsso.cfg' file in '/opt/bmc/digitalworkplace/conf':

05:13:11.169 - rsso.cfg file is configured correctly

 

Web Server (Jetty)

 

Jetty logging can be very useful to capture HTTP traffic and is enabled by un-commenting the following section and changing the log level

       <!-- Jetty Logging - uncomment block if jetty logging is required -->

    <appender name="JettyLog"

                class="com.bmc.arsys.logging.ReconfigurableRollingFileAppender">

                <file>${com.bmc.arsys.homedir}/${com.bmc.arsys.server.dbdir}/jetty.log

                </file>

                <append>true</append>

                <rollingPolicy class="com.bmc.arsys.logging.StoredRollingPolicy">

                        <fileNamePattern>${com.bmc.arsys.homedir}/${com.bmc.arsys.server.dbdir}/jetty.log.%i

                        </fileNamePattern>

                        <minIndex>1</minIndex>

                        <maxIndex>8</maxIndex>

                </rollingPolicy>

                <triggeringPolicy

                        class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">

                        <maxFileSize>128MB</maxFileSize>

                </triggeringPolicy>

                <needPreLoading>true</needPreLoading>

                <encoder>

                        <pattern>%d{EEE MMM dd HH:mm:ss.SSS yyyy} %m%nopex%n</pattern>

                </encoder>

        </appender>

        <logger name="org.eclipse.jetty.server.Server" level="all" additivity="false">

 

Connector logging

 

Connector logging is available from 19.02. To enable, change the log level to "all"

 

</appender>

        <logger name="com.bmc.myservice.connect.remedy" level="all" additivity="false">

                <appender-ref ref="connect-remedy" />

        </logger>

        <logger name="com.bmc.myservice.connect.commons-ar" level="all" additivity="false">

                <appender-ref ref="connect-remedy" />

        </logger>

 

 

Process logging

 

Backup the logback_server.xml and add the following to the end of the file.

<!-- Process -->

        <appender name="ProcessLogToForm" class="com.bmc.arsys.logging.SubscribableAppender">

        </appender>

        <appender name="ProcessLog" class="com.bmc.arsys.logging.SiftingTenantAppender">

                <appender class="com.bmc.arsys.logging.SuspendableRollingFileAppender">

                        <file>${com.bmc.arsys.homedir}/${com.bmc.arsys.server.dbdir}/arprocess.log

                        </file>

                        <!-- <param name="Encoding" value="UTF-8" /> -->

                        <append>true</append>

                        <enableThreadLogging>true</enableThreadLogging>

                        <rollingPolicy class="com.bmc.arsys.logging.StoredRollingPolicy">

                                <fileNamePattern>${com.bmc.arsys.homedir}/${com.bmc.arsys.server.dbdir}/arprocess${threadId}.log.%i

                                </fileNamePattern>

                                <minIndex>1</minIndex>

                                <maxIndex>10</maxIndex>

                        </rollingPolicy>

                        <triggeringPolicy

                                class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">

                                <maxFileSize>99MB</maxFileSize>

                        </triggeringPolicy>

                        <encoder>

                                <pattern>%m%n</pattern>

                        </encoder>

                </appender>

        </appender>

  <logger name="com.bmc.arsys.rx.services.process" level="debug"

                additivity="false">

                <appender-ref ref="ProcessLog" />

                <appender-ref ref="AlwaysOnLog" />

                <appender-ref ref="ProcessLogToForm" />

        </logger>

        <logger name="com.bmc.arsys.server.rx.services.process" level="debug"

                additivity="false">

                <appender-ref ref="ProcessLog" />

                <appender-ref ref="AlwaysOnLog" />

                <appender-ref ref="ProcessLogToForm" />

        </logger>

        <logger

                name="com.bmc.arsys.server.rx.services.action.DefaultCustomActionExecutor"

                level="debug" additivity="false">

                <appender-ref ref="ProcessLog" />

                <appender-ref ref="AlwaysOnLog" />

                <appender-ref ref="ProcessLogToForm" />

        </logger>

        <logger name="com.bmc.arsys.server.rx.services.action.ActionServiceImpl" level="debug"

                additivity="false">

                <appender-ref ref="ProcessLog" />

                <appender-ref ref="AlwaysOnLog" />

                <appender-ref ref="ProcessLogToForm" />

        </logger>

        <logger name="com.bmc.arsys.server.rx.services.action.DefaultCustomActionManager" level="debug"

                additivity="false">

                <appender-ref ref="ProcessLog" />

                <appender-ref ref="AlwaysOnLog" />

                <appender-ref ref="ProcessLogToForm" />

        </logger>

        <logger name="com.bmc.arsys.server.rx.services.connector.ConnectorCustomActionManager" level="debug"

                additivity="false">

                <appender-ref ref="ProcessLog" />

                <appender-ref ref="AlwaysOnLog" />

                <appender-ref ref="ProcessLogToForm" />

        </logger>

Then log into the mid-tier (Catalog) as dwpadmin and navigate to Sever Information > Log Files and tick "Process Log".

You need to perform an "dwpcontroller stop/start" for the changes to take effect

Startup issues

 

Navigate to the $AR_SYSTEM_HOME/sb/rxscripts/bin directory and uncomment the following line from the setenv.sh script

#export rx_trace="--trace-ascii ./trace.log"

unset rx_trace

 

Stop/start the Catalog again and check the trace log for errors.

 

Catalog Bundle log

 

Almost every troubleshooting scenario will require analysis of the bundle log. Here's an example of what a "healthy" bundle log looks like.

 

05-05 15:56:26.419 DEBUG com.bmc.myservice.connectors.service.ConnectorSrvImpl testing URI http://localhost:8008/api/sbe/connect/remedy]

05-05 15:56:26.520 DEBUG com.bmc.myservice.connectors.service.ConnectorSrvImpl connector URIs [http://localhost:8008/api/sbe/connect/baopoc]

com.bmc.myservice.connectors.service.ConnectorSrvImpl connector URIs [http://localhost:8008/api/sbe/connect/ad]

 

As you can see, DEBUG is enabled and it's constantly looping around checking each connector status. The following example demonstrates how you would use the bundle log to troubleshoot a typical problem.

 

  • In the screenshot below I have submitted a Service Request in DWP and you can see it's gone into a fault status.

 

WBYeats.png

 

 

The first step is to open a session in the “$AR_SYSTEM_HOME/db” directory and run a "tail" on the log.

  • [root@clm-aus-0123 db]# tail -f bundle.log

This command gives you a live feed of what's happening within the log.

 

  • In the example below I can see my Service Request is faulting because a required field is empty...

 

at sun.reflect.GeneratedMethodAccessor636.invoke(Unknown Source) ~[na:na]

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_95]

        at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_95]

        at com.bmc.myservice.common.util.SrvInterceptor.invoke(SrvInterceptor.java:23) ~[com.bmc.myservice.common-1.0.00-SNAPSHOT.jar:1.0.00-SNAPSHOT]

        ... 94 common frames omitted

Caused by: com.bmc.arsys.domain.etc.ARException: ERROR (100): Required Entry ID is empty.; form: rxn:/myit-sb/ServiceRequest

        at com.bmc.arsys.server.domain.validation.EntryValidatorImpl.validateEntryId(EntryValidatorImpl.java:335) ~[na:na]

        at com.bmc.arsys.server.domain.validation.EntryValidatorImpl.validateGetEntry(EntryValidatorImpl.java:323) ~[na:na]

        at com.bmc.arsys.server.domain.validation.handler.EntryValidationHandler.validateGetEntry(EntryValidationHandler.java:79) ~[na:na]

        at com.bmc.arsys.server.domain.service.impl.EntryServiceImpl.getEntry(EntryServiceImpl.java:366) ~[na:na]

        at com.bmc.arsys.server.facade.impl.EntryFacadeImpl.getEntry_aroundBody10(EntryFacadeImpl.java:143) ~[na:na]

        at com.bmc.arsys.server.facade.impl.EntryFacadeImpl$AjcClosure11.run(EntryFacadeImpl.java:1) ~[na:na]

  • Here's another example where I submit another Catalog Request from the DWP Client and the bundle log is telling me that I need to define an Work Order Manager on the ITSM side.

Caused by: java.lang.reflect.InvocationTargetException: null

        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_95]

        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_95]

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_95]

        at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_95]

        at com.bmc.arsys.rx.business.action.impl.ActionServiceImpl.invokeMethod(ActionServiceImpl.java:710) ~[na:na]

        ... 80 common frames omitted

Caused by: com.bmc.myservice.connect.exception.ConnectorException: ERROR (1440853): ; No work order manager group could be found. Manually select a group from the menus. If no group with an individual in the functional role of work order manager is defined, notify your System Administrator.

        at com.bmc.myservice.connect.ar.api.ArApiManager.createEntry(ArApiManager.java:448) ~[na:na]

        at com.bmc.myservice.connect.ar.api.ArApiManager.createEntry(ArApiManager.java:411) ~[na:na]

        at com.bmc.myservice.connect.ar.api.ArApiManager.createEntry(ArApiManager.java:400) ~[na:na]

        at com.bmc.myservice.connect.ar.common.services.WorkOrderService.createWorkOrder(WorkOrderService.java:14

Most errors are now visible by simply opening the Request from the Console:

 

SBException.PNG

 

Installation and Upgrade

 

The installation script will inform you if there are any problems. Full details are available within the "arsystem_install" log which is located in the /tmp directory. To obtain a live feed on installation progress, just run a "tail" on the log as follows:

 

[root@clm-aus-0123 tmp]# tail -1000 /tmp/arsystem_install_log.txt

 

The following extract is an example of a successful installation.

 

(Dec 15 2016 03:54:59.677 PM +0530),INFO,com.bmc.install.utility.logging.Log,

  --------------------------------------------------------

  BMC Remedy Action Request System 9.5.00 install succeeded.

  --------------------------------------------------------

(Dec 15 2016 03:54:59.697 PM +0530),INFO,com.bmc.install.product.base.installer.InstallCompletionInstallationTask,

  PROGRESS EVENT {Description=[installCompletion.installCompletion.description],Progress=[100],Detail=[installCompletion.installCompletion.complete]}

(Dec 15 2016 03:54:59.917 PM +0530),CONFIG,com.bmc.install.product.base.project.runner.ProjectRunner,

  LOG EVENT {Description=[COMPLETED InstallationTask],Detail=[com.bmc.install.product.base.installer.InstallCompletionInstallationTask]}

If the installer fails and the arsystem log doesn't identify the root cause, run the uninstall script (make sure you also remove any Catalog DB references if present) and run the script again in verbose mode as follows:

bash -x ./install-myit-sb.sh

This command will output a detailed log to the terminal. In the event of a failure the output will stop allowing you to scroll up and identify what was happening at the time.

Please back up the Catalog Databases and file-system before upgrading. In the event you encounter a problem you can quickly roll back and send the logs to BMC Technical Support.

Connector Refresh

 

There may be occurrences where your connectors are no longer visible in the Console. If this is the case try running the connector refresh script as follows:

 

[root@clm-aus-0123 rxscripts]# source bin/setenv.sh

 

./bin/login.sh hannah_admin@domain.com password

./bin/connector/refresh.sh

Approvals Integration

 

The 'MyITSB- Approval' process is responsible for sending the approval request from the Catalog to the ITSM Server. When a Service Request is raised from the DWP Client, the corresponding workflow on the Catalog machine is triggered which in-turn calls 'Request Approval' which communicates with the AR Server

SBApprovalStub.PNG

 

As a first step we would enable filter/API logging on the ITSM Server before reproducing the problem and we'll be able to follow the process flow within the log file. The next step would be to open the "SB:ServiceRequestStub" form on the ITSM Server and check the “Error Message” box. In the example below it's complaining about a timeout to the Catalog Server.

 

Make sure the "SB:LocalApprovalConfiguration" & "SB:RemoteApprovalConfiguration" Approval forms on the ITSM AR Servers have the correct information.

Once the Request has been approved by the manager, remedy workflow kicks in and attempts to send the data back to the Catalog via the "remoteaction.bat" file. This file along with the contents of the "remoteaction" directory are implemented by the Integration Server Patch.

 

Make sure the remoteaction script/batch file has the correct Java path

If the Approval status isn't being sent back to the Catalog, enable filter/API logging. You should be able to see the "remoteaction" command attempting to send the data back via the workflow. There is also a "remoteaction" log file (enabled in the logback_remoteaction file) which will allow you to track the status transmission back to the Catalog.

 

 

ITSM Integration

 

The following illustration depicts the process flow when submitting a request from DWP. As both Approvals and ITSM use a combination of the remoteaction.xml and associated JAR files in combination with remedy workflow, we will use the same troubleshooting methodology as above for Approvals.

 

 

The "Status Change" filters have changed names over the releases...

 

Browser Tools

 

Once Developer Mode (F12) is enabled check the network tab response and look for any exceptions. The screenshot below illustrates how I've captured the root cause of a problem by simply clicking on the REST call and selecting the response.

 

 

Ensure the DWP Catalog is reachable and the fully qualified domain name is being used.

 

Don't forget, the users must exist in both the user form on the Catalog Server (which is populated via the sync script) and CTM:People form within ITSM

 

DWP Client Catalog Debug

 

Open the logback-dwp.xml from the "/opt/apache/tomcat8.x/external-conf" directory and change these two extracts.

 

  <!--Logging of DWP Catalog -->

  <property name="LOG_DWP_CATALOG" value="true"/>

 

  <!--Optional DWP Catalog logger-->

  <if condition='${LOG_DWP_CATALOG}'>

    <then>

      <logger name="com.bmc.bsm.myit.service.sb" level="debug" >

        <appender-ref ref="DWP_CATALOG_FILE"/>

      </logger>

      <logger name="com.bmc.bsm.myit.rest.v2.assistance" level="debug" >

        <appender-ref ref="DWP_CATALOG_FILE"/>

      </logger>

      <logger name="com.bmc.bsm.myit.service.social.activity_stream" level="debug" >

        <appender-ref ref="DWP_CATALOG_FILE"/>

      </logger>

    </then>

  </if>

 

After the scan period of 60 seconds a new log file (dwp-catalog.log) will be created in the DWP/Logs directory.