Use  $GET($$$JobSuperSession)

A SuperSession ID is generated in a Business Service when the Generate SuperSession ID setting is checked, thereby giving an identity for messages streams that made up of multiple production namespace-based sessions. Subsequent Business Processes and Operations are expected to propagate it on (without overriding it with a new one).

The SuperSessionID identifies the originating instance and namespace, plus the original Session ID, and looks something like this: MYSERVER.COM^IRISHEALTH^PRODNAMESPACE^12345.

The  EnsLib.HTTP.OutboundAdapter will include the SuperSessionID in an HTTP Header if the Send Supersession setting is set.

The  Enslib.HTTP.InboundAdapter will copy the SuperSessionID from the HTTP Header into the new Ensemble message, if present (and the Generate SuperSession setting is not set to override it by generating a new one). 

That is, if only the first Business Server in the first instance in the message stream has Generate SuperSession ID set, and all of the Business Operations that send them on have Send SuperSession setting set, the SuperSessionID identity is propagated unchanged among instances in the message stream.

If you want to walk through a list of all the configuration settings for an item, not just those that have been set, you can find an example in the GetSettingsSubTree() method of the EnsPortal.DefaultSettings class.

  If $IsObject(pItem) {
       Set tSC = pItem.GetStaticSettings(.pList)
       if $$$ISOK(tSC) {
          Do pItem.PopulateVirtualSettings()
          Set n0 = $O(pList(""),-1)
          Set n = pItem.VirtualSettings.Count()
          For I = 1:1:n {
             Set pList(n0+i) = pItem.VirtualSettings.GetAt(i)
          }
    }

Each of the setting items in pList are a $LIST that contains:

Type = $LIST(setting,1)                               // "host"
Name = $LIST(setting,2)                             //"FilePath"
Value = $LIST(setting,3)
Description = $LIST(setting,7)
DataType = $LIST(setting,8)                       // "%Library.String"
LocalizedName = $LIST(setting,15)            // "File Path"
Setting Category = $LIST(setting,16)         // "Basic"
Localized Category = $LIST(setting,17)     // "Basic Setting"
Editor = $LIST(setting,18)                          // "directorySelector"

I suspect the Message Schema Category setting specified in your Business Service is NOT specifying category 2.2. This setting overrides whatever version number is in MSH:12 (since the MSH value is notoriously unreliable). You may be specifying another version or a custom schema.  When the message hits your rule, the docCategory constraint value is compared to what the Business Service assigned, not MSH:12. 

Look at a message that failed in the Message Viewer Body tab, to see the MessageTypeCategory value (which is compared to docCategory) and Name value (which is compared to docName). One of them does not match, otherwise the message would be sent.

The WHEN conditional expression in Rule 1 does absolutely nothing. The pair of AND conditions duplicates the docName filter in the Constraint so also has no effect. And therefore adding  OR 1=1 further has no effect. So the Constraint has to be your problem.

If you added the same constraints to Rule 2, it would also break, since your problem is with the constraints.