[QUESTION]Are there any limitations for number of externalIds for each soql query in export.json file?

[kvenkatasivareddy]

exportjson.txt

I'm trying to migrate the records from one to another org. I have marked Account object master:true and for other referenced objects as master:false. I'm not sure whether there are any limitations for number of external ids in each soql query.

I'm getting the below error 2023-07-03__17_57_55.log

[18:00:24.279] [ERROR] Error during execution of the command:

Bad Message 414

reason: URI Too Long

. [18:00:24.282] [ERROR] Execution of the command sfdmu:run has been completed. Exit code 4 (COMMAND_EXECUTION_ERROR).

Can you please help me to resolve the issue?

thanks in advance.

[hknokh2]

Hello,

Thank you for contacting me. There is no limitation on the number of external IDs, but it's important to consider that each field included in the complex external IDs will be part of the SOQL query for this object and all related objects. The generated SOQL query is sent to the Salesforce API as a GET request. However, there are limitations on the URI length and Salesforce REST API in this regard.

Based on the export.json file you provided, the resulting SOQL query is quite large, which could explain why it failed. The purpose of an external ID is to create something unique that is consistent between the source and target organizations, specifically for this object. Typically, it is sufficient to use 1-2 fields to ensure uniqueness. You do not need to include the external IDs of related objects or anything of that sort in the external ID for this object.

I suggest reducing the number of fields in the external ID parameter to a maximum of 1-4 fields, if possible. By minimizing the number of fields, you should still be able to achieve uniqueness.

Best regards

[kvenkatasivareddy]

Hi @hknokh2

Thanks for the quicker response. After excluding the referenced objects external ids as part soql query, i'm able to migrate the data.

can you answer the below questions as well? 1.Can we omit the externalIds if it don't have any fields which can be considered as an externalids? Eg: In case of PricebookEntry object migration SELECT Pricebook2Id,Product2Id,ProductCode,SystemModstamp,UnitPrice,UseStandardPrice,IsActive FROM PricebookEntry . I think we shouldn't consider the Pricebook2Id and Product2Id as an external Ids directly. in this case i don't have any external ids.

Will the migration works in this case without giving externalIds for PricebookEntry object? https://help.sfdmu.com/faq/configuration/can-i-omit-external-id-definition-for-the-object as per the above documentation, i see for Insert operation alone we can go ahead with migration. What about the Upsert or Update operations.

2. In which order export.json will execute if the export.json contains objectSets?

[hknokh]

Hello,

1. You can omit the externalId field only for Insert operations since others require comparing source and target records. In your example of Pricebook, Pricebook2Id and Product2Id are not externalId fields used to compare source and target records. They are lookup fields that should be filled out with the target data.

So, if Pricebook2 and Product2 have operations set to anything other than Insert, you should determine any unique field of these objects which values are equal between the source and the target, and set these fields as the externalId for these objects. That would be sufficient.

Regarding PricebookEntry, it is the same. If it has an insert operation, you can omit the external id for this sobject. Otherwise, you should detect a unique field for PricebookEntry and set it explicitly. In summary, for the externalId fields, consider the uniqueness of the given object for which you set the externalId, and disregard other sobjects.

2. When executing the export.json file with multiple object sets, first it executes the primary 'objects' array (if it contains any objects), and then it executes the rest of the ObjectSets in the order they appear in the file.

In addition, if your query string contains a reference to an sobject that is not listed in the export.json, SFDMU has logic to detect the best external id field for the given sobject type and automatically includes this object in the job with a readonly operation.

Regards,

[github-actions[bot]]

This case has been marked as 'to-be-closed', since it has no activity for the 3 days.
It will be automatically closed in another 3 days of inactivity.

[github-actions[bot]]

This case has been closed, since it has no activity for the last 6 days. Feel free to reopen it, if you need more help.