-
Suggestion
-
Resolution: Unresolved
-
None
Problem
Currently External Imports and their mappings are designed for one import configuration per object type (root object type).
For instance if we have the the following structure:
and want to have 2 different import configurations for each of Toyota and Mazda object types, in the mapping of both imports, should provide the mapping for the root object type (Car) with all children. Even though, the import configuration for Mazda should not need to know about Toyota object type and vice versa. Otherwise, if only Mazda object type mapping is provided, Toyota object type will get deleted when the `POST .../importsource/{id}/mapping` endpoint is hit.
Suggested Solution
Allow mapping of children object types in multiple import configuration so that each import configuration can only define the child object type they are dealing with and doesn't have to provide all children object types of the same parent.
Why This Is Important
Flexibility of bringing data for children object types from different sources (through different import configuration).
Workaround
Currently each import configuration needs to provide all the hierarchy of the root object type in the mapping. Even the children object types that are irrelevant to the data that is being imported.
[JSDCLOUD-12083] External imports: Allow mapping of children object types in multiple import configurations
Description |
Original:
h3. Problem
Currently *External Imports* and their mappings are designed for *one import configuration per object type* (root object type) h3. Suggested Solution Allow mapping of multiple child object types along with parent object type in the same import configuration h3. Why This Is Important Flexibility of mapping parent as well as child object types in the same import configuration of External imports h3. Workaround Currently there is no known workaround for this behavior. A workaround will be added here when available. |
New:
h3. Problem
Currently *External Imports* and their mappings are designed for *one import configuration per object type* (root object type). For instance if we have the the following structure: !image-2022-12-16-00-14-07-161.png|width=187,height=115! and want to have 2 different import configurations for each of Toyota and Mazda object types, in the mapping of both imports, should provide the mapping for the root object type (Car) with all children. Even though, the import configuration for Mazda should not need to know about Toyota object type and vice versa. Otherwise, if only Mazda object type mapping is provided, Toyota object type will get deleted when the `POST .../importsource/\{id}/mapping` endpoint is hit. h3. Suggested Solution Allow mapping of children object types in multiple import configuration so that each import configuration can only define the child object type they are dealing with and doesn't have to provide all children object types of the same parent. h3. Why This Is Important Flexibility of bringing data for children object types from different sources (through different import configuration). h3. Workaround Currently each import configuration needs to provide all the hierarchy of the root object type in the mapping. Even the children object types that are irrelevant to the data that is being imported. |
Attachment | New: image-2022-12-16-00-14-07-161.png [ 431825 ] |
Summary | Original: External imports: Allow External imports: Allow mapping of children object types in multiple import configurations of multiple child object types in one import configuration | New: External imports: Allow mapping of children object types in multiple import configurations |
Summary | Original: External imports: Allow mapping of multiple child object types in one import configuration | New: External imports: Allow External imports: Allow mapping of children object types in multiple import configurations of multiple child object types in one import configuration |
Thank you very much for opening this feature request on behalf of me. Very clear description of my request!