On a bright sunny day, without any prior warning (as it usually happens in DEV environment) our HP BSM Connector decided that it doesn’t want to show any policies in the UI and instead to present me with “An unexpected error occurred” kind of message:

After asking for more details this message box was kind enough to reveal some more information:

Here is the exception in a more readable form:

faultCode=Server.Processing
faultString=com.hp.opr.policymanagement.exception.PolicyManagementException : Error parsing XML [JDOMParseException]: Error on line 1: Premature end of file.
faultDetail=null
message=(mx.messaging.messages::ErrorMessage)#0
  body = (null)
  clientId = "5350AC36-3C0F-81F1-8467-BF33183EE63A"
  correlationId = "E601AE91-C1FD-E6E5-4635-39106774BBC1"
  destination = "policyManagementService"
  extendedData = (null)
  faultCode = "Server.Processing"
  faultDetail = (null)
  faultString = "com.hp.opr.policymanagement.exception.PolicyManagementException : Error parsing XML [JDOMParseException]: Error on line 1: Premature end of file."
  headers = (Object)#1
  messageId = "53510DD2-070E-D6D9-870F-3307D13C1DAA"
  rootCause = (Object)#2
    cause = (Object)#3
      cause = (Object)#4
        cause = (null)
        columnNumber = 1
        exception = (null)
        lineNumber = 1
        localizedMessage = "Premature end of file."
        message = "Premature end of file."
        publicId = (null)
        suppressed = (Array)#5
        systemId = (null)
      columnNumber = 1
      lineNumber = 1
      localizedMessage = "Error on line 1: Premature end of file."
      message = "Error on line 1: Premature end of file."
      partialDocument = (null)
      publicId = (null)
      suppressed = (Array)#5
      systemId = (null)
    exceptionCode = "XML_PARSING_ERROR"
    localizedMessage = "Error parsing XML [JDOMParseException]: Error on line 1: Premature end of file."
    message = "Error parsing XML [JDOMParseException]: Error on line 1: Premature end of file."
    suppressed = (Array)#5
  timestamp = 1409706649591
  timeToLive = 0

Cause

When HP BSM Connector policies and XML are mentioned in one sentence the 2 locations that come in mind are

• %OVDataDir%\datafiles\policies – that’s where all the policies that appear in the HP BSM Connector UI exist
• %OVDataDir%\datafiles\policymanagement\store – that’s the “main’ store location of the policies.

After having a quick look at the XML files in the first location and not seeing anything interesting I switched  my focus on the second location and here I’ve noticed one “anomaly”. One of the _header.xml files’ size was 0 bytes.

Apparently someone (not excluding myself from the list of suspects) was working on a policy when the machine, BSM Connector is installed on, ran out of space. It is very possible that some warning message was displayed back then or the UI just hang, but since it’s DEV environment no one really cared and just restarted the HP BSM Connector service. The space issue was solved but the _header.xml file, of the policy that has been edited at the time of the crash, became “corrupted”.

Solution

After deleting the .lock and .active files and replacing the _data and _header.xml files of the problematic policy in the %OVDataDir%\datafiles\policymanagement\store with the ones from %OVDataDir%\datafiles\policies , saying a short prayer to the Lords of policies and hitting the refresh button in the HP BSM Connector UI I was pleased to see the UI showing all of my lovely policies and not the annoying error message.

The post HP BSM Connector fails to load policies list into UI with “Error parsing XML” exception appeared first on ISbyR.

Not sure about the reason’s, may be some OM veterans can shred some light on it, but the syntax of regular expressions (or patterns as they are known in the OM world) is very different to Perl style regexes that most of us were used to.
I won’t get into the depth of explanation about the syntax of pattern matching since there are many places you can find that information (offical  documentation and community articles) but rather present to you a command line utility (that comes as part of OA installation) that allows you to test the patterns that you’ve crafted (with sweat and blood I assume) against a test text.

opcpat – pattern matching expressions utility

The utility is located at the %ovinstalldir%\bin\win64\OpC\utils folder on a machine that has OA agent installed, for example BSM Connector.

Note: At the end of this article you will find the full help output of that utility (which you can get by running opcpat with -h option).

There 2 ways of using the pattern matching utility – opcpat:

• Interactive; You will provide the pattens and the search text using command line prompts.
• Non-interactive: You specify the location of pattern and search text files.

Interactive use of opcpat

The interactive way of using opcpat could be useful if you want quickly to test your pattern matching expression and don’t want to bother yourself with creating  pattern and values files.

Here is the flow of the pattern test:

1. Specify the pattern you want to test
2. Specify the separators
3. Specify the text to you want to test your pattern against
4. Verify the results
5. Either repeat step 3 or hit RETURN to test a new pattern

opcpat
using singlebyte mode

Enter a pattern and the separator characters used for <@>, <S>
pattern (<RETURN> to exit): foo <@.txt> foo
separators:

******** next pattern ********
Pattern: "foo <@.txt> foo" using seps ""
value (<RETURN> for new pattern): foo bar foo
"" txt:"bar" ""

Pattern: "foo <@.txt> foo" using seps ""
value (<RETURN> for new pattern): fff bar fff
Pattern didn't match

Pattern: "foo <@.txt> foo" using seps ""
value (<RETURN> for new pattern):

Enter a pattern and the separator characters used for <@>, <S>
pattern (<RETURN> to exit):

Non-Interactive use of opcpat

I personally find the non-interactive way to be more convenient.

Let’s prepare the input files.

The patterns input file consists of pattern-separator pairs and has the following format:

# commentline (only allowed at the first lines of the file)
# comment ...
pattern1
separators1
pattern2
separators2 ...

In this example I will use a C:\temp\patternfile.txt with the following content:

JOB,NOTOK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>,<*.errorCode>

JOB,LATE,<*.jobId>,<@.runDate>,<@.runTime>

JOB,OK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>

Note the empty lines. I am using them to tell the utility to make use of the default separators (a blank and the tab character).

The values files will consists of lines of values we want to test our patterns against and it has the following format:

# commentline(s)
value_a
value_b
value_c

In this example I will use a C:\temp\valuefile.txt with the following content:

JOB,OK,JOB1,140521,080059,30883,D0
JOB,NOTOK,JOB1,140514,182035,01818,,JNRUN
JOB,LATE,JOB1,140520,030002

Now let’s run the utility and examine the output (which can  be seen in the CLI or redirected to a file using the -o option). You will notice that each pattern is matched against each of the lines in the values file. Each pattern – value matching attempt produces 4 lines of output:

• pattern: the pattern that is currently been tried
• using seps: which separators are been used in the current attempt ( displayed only if separators were specified for that pattern)
• value: the value that the match attempt s been run against
• result: result of the match attempt. Could have either “pattern didn’t match” sentence or the results of the matched pattern and it’s variables (if the pattern had any)

opcpat -fp c:\temp\patternfile.txt -fv c:\temp\valuefile.txt
using singlebyte mode
******** next pattern ********
Pattern: "JOB,NOTOK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>,<*.errorCode>" using seps ""
Value: "JOB,OK,JOB1,140521,080059,30883,D0"
Pattern didn't match

Pattern: "JOB,NOTOK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>,<*.errorCode>" using seps ""
Value: "JOB,NOTOK,JOB1,140514,182035,01818,,JNRUN"
"" jobId:"JOB1" runDate:"140514" runTime:"182035" runId:"01818" runNode:"" errorCode:"JNRUN"
Pattern: "JOB,NOTOK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>,<*.errorCode>" using seps ""
Value: "JOB,LATE,JOB1,140520,030002"
Pattern didn't match

******** next pattern ********
Pattern: "JOB,LATE,<*.jobId>,<@.runDate>,<@.runTime>" using seps ""
Value: "JOB,OK,JOB1,140521,080059,30883,D0"
Pattern didn't match

Pattern: "JOB,LATE,<*.jobId>,<@.runDate>,<@.runTime>" using seps ""
Value: "JOB,NOTOK,JOB1,140514,182035,01818,,JNRUN"
Pattern didn't match

Pattern: "JOB,LATE,<*.jobId>,<@.runDate>,<@.runTime>" using seps ""
Value: "JOB,LATE,JOB1,140520,030002"
"" jobId:"JOB1" runDate:"140520" runTime:"030002" ""

******** next pattern ********
Pattern: "JOB,OK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>" using seps ""
Value: "JOB,OK,JOB1,140521,080059,30883,D0"
"" jobId:"JOB1" runDate:"140521" runTime:"080059" runId:"30883" runNode:"D0"

Pattern: "JOB,OK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>" using seps ""
Value: "JOB,NOTOK,JOB1,140514,182035,01818,,JNRUN"
Pattern didn't match

Pattern: "JOB,OK,<*.jobId>,<@.runDate>,<@.runTime>,<@.runId>,<*.runNode>" using seps ""
Value: "JOB,LATE,JOB1,140520,030002"
Pattern didn't match

opcpat -h output

C:\Program Files\HP\HP BTO Software\bin\win64\OpC\utils>opcpat -h
Usage:
opcpat [-h] [-i] [-q] [-fp patternfile] [-fv valuefile] [-o outfile][-l length
-h: display this text
-q: quiet mode
-i: use case insensitive pattern matching
-fp patternfile: input file for patterns and separators (see below)
-fv valuefile: input file for value lines matched against each pattern
-o outfile: use 'outfile' for output
-l length: use 'length' for specifying max line length of input file

'patternfile' consists of pattern-separator pairs. It has the format:
# commentline (only allowed at the first lines of the file)
# comment ...
pattern1
separators1
pattern2
separators2 ...

'valuefile' has the format:
# commentline(s)
value_a
value_b
value_c
value_d

The post How to test pattern matching expressions in HP BSM Connector policies appeared first on ISbyR.