1). Each time a message is received by BizTalk, its properties are determined, and are recorded in the MessageProps table.
2). Once BizTalk has recorded the properties of an inbound message, it next finds all subscriptions which match the incoming message using the bts_FindSubscriptions stored procedure. Each subscription is defined within the Subscription table as a separate record with a subscription ID (a Guid) and a creation time.
3). The further processing based on the term 'message property predicate'. To describe for which purpose it used, consider you want to filter receiving messages.
In order to evaluate the filter expression, it needs to cooperate with other conditions upon on which subscription is determined. If more than one filter is intended to apply, all of them must be coordinated. The term for such coordination is 'predicate'. BTS knows the following predicates:
- Bitwise AND
- Equals
- Exists
- GreaterThanOrEquals
- GreaterThan
- LessThanOrEquals
- LessThan
- NotEquals
Each predicate in BTS has unique ID and fits into one of the existing tables in BizTalkMsgBoxDb. (BitwiseANDPredicates, EqualsPredicates etc. )
The predicates are groupped with logical AND or OR operators. Such a grouping is managed in PredicateGroup table, that has separate column for AND(uidPredicateANDGroupID) and OR (uidPredicateORGroupID) grouped predicates. Again, each PredicateGroup has unique ID that, in turn, associated with subscription within Subscription table. If no AND or OR group exists, it anyway has an unique ID (in PredicateGroup table) and simply skipped by subscription evaluating mechanism.
The predicate itself obviously consists of a operator, value and propery to be evaluated. Depending on the operator, the predicate is stored in one of the corresponding tables which all have a common structure. In each of them the predicate's value is stored in vtValue column typed as sql_variant.