If I understand correctly, you have a list ?
If this is the case, what happens if you cast the list to a map? This is going to be highly dependent on the context of execution but this might help.
Map<Id,bObj__c> mapOfAwesome = new Map<Id, bObj__c>(bObjectList);
Again, not knowing the context of execution this could be another red herring.
In this scenario, from your description, the Master is Order__c and the Detail is Order_Item__c. From there, it would seem that Order_Line_Number__c is then a child of Order_Item__c or are they the same? That part is a bit unclear. My sense from what I'm seeing is that they're the same.
You already know that Order__c has an external ID field named ext_Id__c which is your concatenated field. Your schema shows this under Order__c, but it actually applies to Order_Item__c. In a M-D relationship, the child always has a field with the Id of the Master record, which in this case would be Order__c.
It's my sense that your external Id is set up to give you both the Order__c and the Order_Item__c; thus the concatenation. Otherwise, you'd have multiple external Ids for Order__c, so it must actually be the external Id that's meant to be applied to Order_Item__c instead.
I would recommend you try using the concatenated field as your external Id for Order_Item__c as it cannot possibly be the external Id for Order__c if it also contains ALL of the Order Items too as opposed only one of them.
Edit in response to comments
First, I'd highly recommend you go through the Trailhead Integration Module.
I'd suggest you try including the Master record Id to establish the link to both the Master record and the detail record since that Id is referenced on both of those records. How you put them in your SOAP or REST call will be important if you try to do it that way.
If using data loader, it would make sense to use a foreign key for the line item record. What's not clear to me is whether or not you have multiple Ids in the Master Record. Is that a many to 1 relationship? Your schema would indicate that it is, but perhaps not. If it's not, then you'd only need the additional foreign key to use for line_item. Again, I recommend the trailhead Integration Module. The final one will help you see how some of this can work using REST.
Best Answer
The underlying issue here is that, no matter what your approach is, you have to somehow deal with the fact that
Description__c
is being set on the SObject instance you're using to upsert.Even if it's being set to null, it still counts as the field being set/populated. All populated fields in an update/upsert will overwrite the current values stored in Salesforce.
If it's possible for you to simply not set
Description__c
when you convert your external data to anSObject
instance, that'd probably be the easiest and least resource-intensive approach.Beyond that, I think the only approach I can come up with involves creating a new in-memory instance of your SObject and using
getPopulatedFieldsAsMap()
.If you simply want to disregard a specific set of fields, something like the following should do the job
This is necessary because Salesforce does not provide us with a way to unset/un-populate a single SObject field at time of writing (Spring '20, API v48.0).