Implicit and explicit binding in Jitterbit App Builder
Overview
The following are the current list of rule types:
| Rule Type | Explicit/Implicit Binding | Target Columns | Comments |
|---|---|---|---|
| Notification | Explicit | Data source must be linked to the App Builder (Sealed) data source. Target fields ending in () can have multiple columns target them. | |
| Business Object | N/A | Writeable fields Primary keys | |
| Control | Implicit | Metadata | Columns are targeted with values: 0 - hidden 1 - visible (required) 2 - visible (optional) Primary keys are generally not targeted. |
| CRUD | Explicit | CRUD rules are bound explicitly via Action Bindings. XP CRUD rules are executed a single row at a time, in batches, based on the batch size defined in Be_Config. When executed in batches, the row count of the XP CRUD rules should not change between batches App Builder will sort rows by the primary keys as they are indicated in the XP CRUD rule and/or the underlying source table. Do not mark generated values (newuuid()) as primary key or the results of repeateadly running a rule will change. | |
| CRUD Create | Explicit | Data | Auto-generated values are not auto-generated with CRUD-Create (Use XPCRUD-Create). Generally all fields in the target table / data object are targeted. |
| CRUD Update | Explicit | Data | 2 Different target types are used for CRUD Update rules Target - Bind - used to target the columns you want to perform the update (often the PK, but it doesn't have to be the PK) Target - |
| CRUD Delete | Explicit | N/A | Primary keys of a delete rule should be targetted |
| Default | Implicit | Data | If you see an error about "too many rows returned", check the following: 1. Does the default rule include the target table in the from clause (see implicit binding below) 2. If you are getting duplicate results back, you may need to set the DISTINCT flag on your rule 3. Run your rule and verify that the results are as expected |
| Migration | N/A | Used during package management and App Builder upgrades. | |
| Subquery | N/A | N/A | Used by other rules, not used directly themselves. |
| Validation | Explicit Implicit - Most validation rules will use implicit binding |
How implicit binding works
When building a rule with implicit binding, the first instance of the target table or data object in the rule is substituted with the "current" row:
The from clause in your rule should be the storage table for implicit binding to work as desired.
Example 1: defaulting OrderDetails.UnitPricewith ProductPrice (target is OrderDetails)
Select Products.UnitPrice
from OrdersDetails, Products
where OrderDetails.ProductId = Products.ProductId
Becomes:
Select Products.UnitPrice
from OrderDetails, Products
where 1234 = Products.ProductId
(where 1234 is used from OrderDetails)
Example 2: Joining back on table
Sometimes there is a need to join back on the target table (default City based on matching Zip of another Customer):
select Customer2.City
from Customer, Customer as Customer2
where Customer.Zip = Customer2.Zip
Becomes (Customer replaced with current row, Customer2 just a reference to a table in the database):
select Customer2.City
from Customer, Customer as Customer2
where '90210' = Customer2.Zip