• 1 reply
  • Latest Post - ‏2012-06-12T18:17:55Z by SystemAdmin
12 Posts

Pinned topic Running mixed entity in a runset

‏2012-06-12T18:17:55Z |
We are trying to run triggers in runset, where some trigger has entity type 'a', while other 'c'. However, only triggers with entity type 'a' fire. Does anybody know how to make the mixed entity type work in a single runset?

Anoter related issue: the table mapping for 'c' type triggers disappear after each run. Is there a way to make the mapping stay?

Updated on 2012-06-12T18:17:55Z at 2012-06-12T18:17:55Z by SystemAdmin
  • SystemAdmin
    12 Posts

    Even though the user can

    Even though the user can specify multiple entity types at runtime, Detect is able to process only one entity type at a time. For example, suppose the engine is run on entity types 'a' and 'c'. The engine will first process all the records for entity type 'a' and then process all the records for entity type 'c'. If you open the state history database, you will notice that a record was created for each id of entity type 'a' and for each id of entity type 'c'. When the logic for entity type 'c' is executing, it does not have visibility to the history accumulated for entity type 'a'. This is probably the reason why your 'c' triggers are not firing. In order for the 'c' triggers to have access to 'a' data, you will need to run the 'a' transactions again as 'c' transactions. For example, suppose 'a' represents account information and 'c' represents customer information. Suppose a transaction occurs for accountID A1 and customerID C1; and C1 is an account holder in A1. You will have to create two transaction files, one labeled the account file. It will contain all the transactions sorted by account. You will then have to take the same data and create another file, sorted by customerID. (Note that the feed files include the entity type in their name.) When the engine runs, it will process the account information and then process the customer information. 

    There only way to truly mix logic between entities, is to take the outcome from the 'a' run and feed it into the output of the 'c' run. Or vice versa. So if there are triggers that occur at the customer level that need to be processed at the account level, the outcome of the customer triggers will have to be packaged from the database and into a feed file and sent to the engine during the account phase of the processing. 

    Please expand on the table mapping issue. I don't understand the question.