Promotion & Backup of BusinessObjects UNX Universes and Users — Design Behavior and Synchronization Logic

Promotion & Backup of BusinessObjects UNX Universes and Users — Design Behavior and Synchronization Logic

Overview

When promoting or backing up UNX universes and users with 360Plus, you may notice that UNX files are always overwritten and that user timestamps change frequently. This behavior is by design on the BusinessObjects side and cannot be modified by SAP or by 360Plus.
360Plus uses object metadata (including last-modified timestamps) to decide whether an object should be overwritten at the destination. Because BOBJ updates timestamps on very minor changes—and universes are complex objects—the safest and most reliable behavior is to overwrite UNX universes on each run.

Key Points

  1. BOBJ timestamps change on minimal interactions (e.g., connections for users), which affects synchronization decisions.
  2. For UNX Universes:
    1. They require an additional modification after copying to another CMS before they are usable. Without this update, the copied UNX is unusable.
    2. Changing the difference check to a simple source > destination timestamp comparison can result in missed changes, which is not acceptable for reliability and data integrity.
    3. Due to their complexity and timestamp behavior, 360Plus overwrites them every time to prevent missed changes and ensure consistent usability post-promotion.
  3. For users, 360Plus can work around timestamp changes and evaluate other properties to determine differences.

Symptoms You May Observe

  1. UNX universes appear to be overwritten on every synchronization.
  2. Attempts to promote a UNX without the required post-copy update result in an unusable universe in the target CMS.
  3. User objects show frequent timestamp updates even on lightweight actions (e.g., logins, connections).

Root Cause (Design Behavior in BOBJ)

  1. Timestamp sensitivity: BOBJ modifies the last-modified time with minor changes or connections.
  2. Universe complexity: UNX universes are complex and their internal structure makes safe, granular difference-detection impractical.
  3. Required post-copy change: Copying a UNX to another CMS requires a specific additional modification for it to function. Without it, the universe remains unusable.
  4. Immutability of behavior: This is a design issue in BOBJ; neither SAP nor 360Plus can change it.

360Plus Synchronization Logic

  1. Synchronization decisions rely on the time of the last modification (among other checks).
  2. Because this time is modified at the slightest change, relying solely on timestamps is unsafe.
  3. For user objects, 360Plus hashes a set of properties to detect meaningful changes irrespective of timestamp noise.
  4. For UNX universes, the safest approach is to overwrite on each run, as reliable verification of “no change since backup” is not possible.

How 360Plus Decides Whether Users Need Promotion/Backup

To avoid false positives driven by timestamps, 360Plus hashes selected user properties and only promotes/backups when the computed signature differs between source and destination. The following properties are used:
  1. SI_ID
  2. SI_NAME
  3. SI_DESCRIPTION
  4. SI_KEYWPORD
  5. SI_EMAIL_ADDRESS
  6. SI_USERFULLNAME
  7. SI_OWNERID
  8. SI_CHANGEPASSWORD
  9. SI_PASSWORDEXPIRE
  10. SI_FORCE_PASSWORD_CHANGE
  11. SI_USER_LICENSE_CUID
  12. SI_FAVORITES_FOLDER
  13. SI_INBOX
  14. SI_PERSONALCATEGORY
  15. SI_NAMEDUSER
  16. SI_ENABLE_ATTR_BINDING
  17. SI_FLAGS
  18. SI_USER_FLAGS
  19. SI_DATA
  20. SI_USER_NEW_BOOKMARKS
  21. SI_BIVARIANTS_OF_USER
  22. SI_ALIASES
  23. SI_PRINCIPAL_PROFILES
  24. SI_CUSTOM_MAPPED_ATTRIBUTES
  25. SI_USERGROUPS
Info
Note: Hashing these properties allows 360Plus to detect meaningful changes while ignoring timestamp-only noise.

Recommended Operational Approach

  1. Accept overwrite behavior for UNX universes: treat UNX promotion/backup as always-overwrite to guarantee correct, usable universes in the target CMS.
  2. Rely on property hashing for users: let 360Plus decide user updates via hashed property comparison rather than timestamps.

FAQs

Q1: Can we stop UNX files from being overwritten each time?
A: No. Due to BOBJ’s design and UNX complexity, 360Plus must overwrite UNX universes on each run to ensure consistent and usable results after promotion.

Q2: Why are user timestamps changing so often?
A: In BOBJ, even user connections can update timestamps. 360Plus avoids timestamp-only checks for users by hashing a robust set of user properties to detect meaningful changes.

Q3: Is there a configurable setting to disable timestamp consideration?
A: For universes, even ignoring timestamps won’t make verification safe. The overwrite strategy is intentional to prevent missed updates. For users, 360Plus already uses property hashing to minimize timestamp noise.