# Inline Image or File Synchronization ## Overview space.vars.SITENAME supports the synchronization of images and files across end systems in fields, comments, and as attachments on the entity. * There are certain types of end systems based on how they add images/ files on their entity fields and comments. 1. **Entity Storage:** * Upon adding an image/ file to rich text fields, the same image/ file is also added as an attachment to the entity. * Example: If image/ file is added to rich text field in Rally, the same image/ file will be visible in attachment section of the entity. * Entity Storage Systems: Rally, Jira, OpenText ALM Quality Center (Formerly Micro Focus ALM/QC), qTest, DOORS NG, ServiceNow, Codebeamer, Windchill, TestRail, OpenText ALM Octane, Enterprise Architect, Aha!, Redmine 2. **Server Storage:** * Upon adding an image/ file to rich text fields, they are uploaded to an end system location itself, but the image/ file will not be added as an attachment to the entity. * Example: If image/ file is added to rich text field in Azure DevOps, this image/ file will not be visible in attachment section of entity. Instead, it will be uploaded to an end system. * Server Storage Systems: Version one, Jama, Aras, Readyone, Salesforce, ETM, DOORS, Hubs=Spot, Azure DevOps 3. **Base64 Storage:** * Upon adding an image/ file to rich text fields, they are not uploaded anywhere. The raw data itself is encoded in Base64 and is set in the rich text field. Image/ file will not be added as an attachment on the entity. * Example: If image/ file is added to rich text field in Broadcom Clarity, image/ file will not be uploaded anywhere. Also, it will not be added as attachment on the entity. * Base64 Storage Systems: Broadcom Clarity ## Image/ File Synchronization Behavior with Storage Combinations ### Server/ Base64 Storage System Combinations
* Between server/ base64 and server/ base64 storage combination systems, if an inline image/ file is added to the entity upon synchronization by space.vars.SITENAME as shown in the above image, it will be similar to the way image/ file is added to the source end system entity, i.e., it will only be added on inline field/ comment. ### Entity Storage System Combinations
* Between entity and entity storage combination systems, if an inline image/ file is added to the entity, upon synchronization by space.vars.SITENAME as shown in the above image, it will be similar to the way image/ file is added to the source end system entity, i.e., it will be added on inline field/ comment and also as an attachment on the entity. * Due to the entity storage system's behavior of auto-adding the image/ file as an attachment to the entity regardless of whether attachment synchronization is enabled/ disabled in mapping. space.vars.SITENAME will also add the attachment on the entity to synchronize the image/ file. ### Server/ Base64 Storage and Entity System Combinations ![](https://818964384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FK5eA7qMDBFu0HHHMDehi%2Fuploads%2Fgit-blob-b149522282dc71c0270744139ae01844706fb397%2FServer_to_entity_inline.png?alt=media) * Between server/ base64 and entity storage combination systems, if an inline image/ file is added to the entity, upon synchronization by space.vars.SITENAME above shown image will be the way image/ file will be added to the entity. * When the entity storage system is the target, space.vars.SITENAME will auto-add the image/ file as an attachment to the entity. * When server/ base64 storage system is the target, space.vars.SITENAME will not auto-add the image/ file as an attachment to an entity. It will only be added in the rich text field/ comment. * View parity between these storage combinations will be due to end-system behavior differences. ## Image/ File Synchronization Behavior with Text Fields/ Comments * In the case of a Text type field/ comment, we cannot add renderable images/ files. * Hence, we will add a custom tag with the uploaded image/ file URL and the filename of the uploaded image/ file. ```xml img1.png ``` * In case of backward synchronization of such fields: * The original uploaded image to the original source will be preserved. i.e., in backward synchronization, we will ensure that the renderable source image is not removed. * For Base64 end systems, since a custom tag was not added in backward sync, the original image added to the source entity will be removed. > **Note:** If the target end system is Base64 storage and the mapped field is text type, then bidirectional mapping with a rich text field is not advisable due to the removal of the image at the source field ## Image/ File Synchronization Behavior with Target end system not supporting Inline Synchronization * In case the target end system does not support inline synchronization, and an inline image/ file is added to the source entity rich text field/ comment, then upon synchronization by space.vars.SITENAME, below mentioned will be the behavior: * Data synchronized to the target entity will not have any renderable images/ files or opshub custom tags for image/ file when it is not a renderable field/ comment. * Images/ files will be uploaded to the entity as attachments. * In backward synchronization, from such end systems, the originally added images/ files will be removed from the fields. ## Image/ File Synchronization Behavior with Comment * If a comment has been synchronized by space.vars.SITENAME with an inline image/ file, the target comment will also have the image/ file. * Now, even if the comment is deleted in the source end system, the image/ file will persist in the target comment and also as an attachment on the entity in case it is an entity storage end system. ## Synchronization Behavior Following are the **Before** and **After** behaviors for the given scenarios: | **Serial No.** | **Scenario** | **Source Applicable To** | **Target Applicable To** | **Behavior before 7.195** | **Behavior after 7.195** | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------ | ------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 |

- Create entity with no attachment or inline images
- Add inline image to entity & start synchronization

| Entity Storage | Server Storage |

- An image will be uploaded twice, one as attachment & second as inline image
- Due to re-upload of image, one image of source will be in sync with multiple target images

| - An image will be uploaded on server & will be referred in rich text field | | 1 (contd.) | | Entity Storage | Entity Storage | - An image will be added to entity as attachment & will be referred in rich text field | Same | | 2 |

- Create entity with no attachment or inline image
- Add comment with inline image & start synchronization

| Entity Storage | Server Storage |

- First, image will be added as attachment
- When the image is detected as inline image, the same will be removed from the attachment
- A new image will be uploaded as the inline image. It will be referred from rich text field or comment.

| Same | | 3 |

- Create entity with one attachment
- Add the same file in rich text field

| ALL | ALL | Same | Same | | 4 |

- If the rich text field was not mapped previously and it had inline images
- After few revisions, rich text field is mapped

| ALL | ALL | - No image was added in target, OH\_IMG tag was added with a unique code | - Field will have inline images in target | | 5 |

- Create entity with multiple same name images referred in single rich text field & synchronize to target
- Update target entity & start other way synchronization

| ALL | ALL | - All same named images will be mapped to one source image | - Despite matching file names, a one-to-one mapping between source and target images will be preserved | | 6 |

- Create entity with same image referred in two or more rich text fields
- Update the content of image
- In later revision, both rich text field has some text appended

| ALL | ALL |

- Inline image will be updated twice
- Due to re-upload, one image of source will be in sync with multiple target images

| - Inline image will be updated only once | | 7 |

- HTML type of field is mapped with text field in target
- Source field has an inline image

| ALL | Server Storage |

- Two images will be uploaded, one as external image in target system and other as attachment on entity
- In target text field, it will be shown as \Img1.png\

|

- One image will be uploaded in the target system and this will not be visible in attachment section of entity
- In target text field, it will be shown as \Img1.png\

| | 7 (contd.) | | ALL | Entity Storage |

- Attachment will be uploaded twice
- In target text field, it will be shown as \Img1.png\

|

- Attachment will be visible in attachment section of entity.
- In target text field, it will be shown as \Img1.png\

| | 7 (contd.) | | ALL | Base64 Storage | - Inline image with base64 storage is not supported |

- Target text field will have \Img1.png\
- Image will not be uploaded to attachment or anywhere. Instead, an image tag with filename will be created

| | 8 |

- Same source field is mapped to two different fields in target & one of them is a text field and other one is a rich text field
- Source field has inline image

| ALL | Server Storage |

- Image will be synchronized both as inline image for rich text field and as attachment to the target entity
- Rich text field has inline image
- Text field has \Img1.png\
- Entity has attachment

|

- Rich text field will have inline image
- Text field will have \Img1.png\
- Image will be uploaded to external server and will be referred in these 2 fields

| | 8 (contd.) | | ALL | Entity Storage |

- Rich text field will have inline image
- Text field will have \Img1.png\
- The entity will have only the attachment due to the implicit behaviour of Entity Storage Connector

| Same | | 9 |

- Create entity with no attachment or inline image
- Add comment with inline image & start synchronization
- Target end system does not support inline image in comments

| ALL | Server Storage |

- Same image will be uploaded twice to the end system
- Attachment will be added to the entity also

|

- First, image will be added as attachment
- When the image is detected as inline image, the same will be removed from attachment & image will be uploaded to server again
- The comment will be added with \Img1.png\

| | 9 (contd.) | | ALL | Entity Storage |

- First, image will be added as attachment to entity
- When the image is detected as inline image, a comment will be added with \Img1.png\

| Same | | 10 |

- Comment synchronization is enabled
- Rich text field is mapped to text field in target
- Both have same inline image

| Entity Storage | Server Storage |

- Image will be uploaded to server system & text field data added with \Img1.png\
- Comment will be added with referred inline image

| Same as before | | 11 |

- Source HTML field is mapped to target text field
- Create entity with inline image & synchronize
- Update target text field & start reverse synchronization (from target to source)

| ALL | Base64 Storage | - Inline image with base64 storage is not supported |

- If same name image is found in source entity, it will be replaced with source URI
- In case, image with same name is not found, the image will be removed from the source entity

| | 12 |

- Create entity with rich text field having image 1
- In next revision, image 2 is uploaded on the same field
- If the events fail and are in retry but image 1’s base64 data is missing from the write-side cache

| Base64 Storage | ALL | - Inline image with base64 storage is not supported |

- Base64 content for image 1's hashcode will be queried in source entity
- Since, it is no longer present on entity now, image 1 will not be synchronized
- In the next revision, image 2 will be synchronized

|