Update Multiple Targets from a Single Source Record¶
Where a query or incoming payload contains data that requires multiple updates of a single target object.
Inbound SAP IDoc contains a single price, and the target SFDC system has one or more price book entries that need to be updated. This example uses 3 Operations. The first receives an Inbound IDoc from SAP, the second performs an update to SFDC, and the third performs an upsert.
The IDoc response is mapped to a flat file. Note that the source is hierarchical, while the target is flat. The dark black generator line is from the lowest node in the source. If the source has 1 record at the first level, two records at the second level, and three records at the third, six records will be generated.
Each node in the target assigns the value to a global variable. This is the 'Key' value:
By using global variables, we can individually call operations through scripting and pass the values. Typically, operations of this type have no source.
Since Jitterbit performs scripted actions in the target sequentially, the script that calls operations must be in the last node. An alternate, and perhaps preferred, method is to make a new condition and perform the assignments in the condition node (don't confuse with the Condition Tab). In this case, the original transformation wrote to a text file, and it was easier to make the value assignments individually. (If you use a condition node, don't forget to pass a true value as the output, or else it may never run!)
Turning to the script in Currency - there are two requirements. If a condition value is 923, run the upsert. If a condition value is 304, run the update.
First, the value for this record is assigned to a global variable, and written to the operation log. Then evaluate if a 923 or 304. If a 923, then run an operation. If a 304, we need to do more processing. Since there may be more than one price book that needs an update, we need to query SFDC to get a list, which is assigned to $pbeList. This is an array, so next we iterate through the array and call the update operation. Note that SFLookupAll will return an array, while SFLookup returns a single value.
$currency=OUTPUT$COND_A01.IDOC$E1KOMG$E1KONH.E1KONP.KONWA$; writetooperationlog("Currency "+$currency); if($ConditionValue == "923", RunOperation("<TAG>Operations/Jitterbit Connect™/Salesforce Upserts/Upsert Contracted Prices</TAG>")); if($ConditionValue == "304", $soql="SELECT Id from PricebookEntry WHERE Product2.ProductCode = '" + Right($material,4) + "' AND UseStandardPrice = TRUE"; $pbeList = SfLookupAll("<TAG>Salesforce Orgs/jitterbit@XXXXX.com.devpro1 (Sandbox)</TAG>",$soql); WriteToOperationLog('PbeList=' + $pbeList); $c = length($pbeList); $i = 0; while( $i < $c, $pbeId = $pbeList[$i]; WriteToOperationLog('PbeList=' + $pbeId + ' Price=' + $price); RunOperation("<TAG>Operations/Jitterbit Connect™/Salesforce Updates/Update Price Book Entries</TAG>"); $i++) )
When this upsert was built using the wizard, at the point where a source is selected, the choice made was 'None' (it is the last selection and frequently overlooked). This builds a transformation that will not read from a source file or a database, but rather uses global variables.
The customer elected to uses SFLookup to get the id's for Account and Product. Script for SBQQ_Account__c:
$material; $soql="select id from Account where SAP_Key__c='"+$material+"'"; SfLookup("<TAG>Salesforce Orgs/jitterbit@XXXXX.com.devpro1 (Sandbox)</TAG>",$soql)
The alternative to this is to pass the global variable to the relationships in the mapping, and leave the fields blank. That is, open SAP_Key__c and add $material. SFDC will perform the lookup for Account and Product automatically and fill in the Account__c and Product__c fields. (You'll find that in Jitterbit, there is usually more than one way to do the same thing!)
This is very similar to the previous example. Since it is an update, then the ID is required.
Also see: Processing Target Records Conditionally