Snom Service Hub

Content

Page tree

ParsingRules extract or create a string from/for an XML. They consist of 0 or more level-tags (up to 42 levels), each enclosing an Xpath or since 8.7.3 a sip-header evaluation (SHE). Example:

<level1 translates_to="available">/tuple[@id=42]/status/basic[.="open"]</level1>
<level1-1 fetch_content=true>Header:Content-ID==<$(ResourceCid)></level1-1>
<level2 fetch_attribute="plain">/tuple[@id=42]/status</level2>
<level3 translates_to="unknown"/>

The level tag determines in which order the tags are matched. It starts with level1.

  • If a level matches and there are no sub-levels no further levels are evaluated and the matching stops.
  • Otherwise, the search continues with the next level.


The order in which the levels are written in the XML is not important, the mathematical order is used (level1, then level2 etc).

To make the resulting string dependent on more then one Xpath or SHE, you can use sub-levels, ie. if you have level1-1, it is evaluated only when level1 matches. If then level1-1 matches, its result is taken, else the result is determined by level1.


When the Xpath or SHE is found in the associated notify, the resulting string is indicated by the attribute in the tag. Those may be(mutually exclusive):

  • translates_to="anyResultingString"
  • fetch_content=true, this will get any plain-text-content the found tag encloses or the sip-header content
  • fetch_attribute="id", this will get the value of the attribute named "id" which should be present in the identified tag


Xpath or SHE may contain $()-placeholders which allow for dynamic insertion of variables and arrays from the XML entity context (since 8.7.3).

It is good practice to not include an Xpath or SHE in the highest level-rule (the one evaluated last). This way one can be sure that it matches 100% and the ParsingRules deliver a result.


Further Information


Related articles