This requirement is to facilitate the setup of multiple Syracuse users (with their designated Syracuse user name/email/profile, etc.) but linked to the same Sage X3 user (where their Sage X3 user code can be linked directly in Syracuse user setup)
Benefit: to minimize the time and efforts needed in creating and managing all those users at both level (Syracuse and Sage X3 Folder level) specially in larger implementation projects > instead creating User template/Profiles at X3 Folder level (thanks to Trade profile/Menu & Function profile setup) and just linking those Sage X3 Folder level users to each individual Syracuse user code
What would be needed (to avoid losing traceability and auditability):
Capturing Syracuse user code as separate CREUSR or UPDUSR fields across all tables (something like SYRCREUSR or SYRUPDUSR)
Please kindly vote if you and your clients have felt the pain of setting up and maintaining a lot of users twice in your projects (once at Syracuse level and again at Sage X3 level)
Victor Nia
Hi,
If you have capability to do some specific, you can address this topic in another way. On our own, we implemented a synchronization between the X3 User and the Syracuse User (the correlation key being [F:AUS]LOGIN).
This can be achieved by declaring a restWebServices pointing on /api1/syracuse/collaboration/syracuse which contains among others /users on which you can POST/PUT/DELETE according to action being done in GESAUS (cf. ASYRRESTCLI.EXEC_REST_WSCLB).
Thus we only maintain the X3 User as we did in V5 and the Syracuse layer is only its reflect. And we continue as well to use the historical CREUSR and UPDUSR as is (as we no longer mind with Syracuse users).
Having Syracuse's groups and roles named the same as your X3 profiles can save additionn boilerplate code (or you can synchronize as well them thru /groups and /roles if required by special cases).
There are some pitfalls, such as declaring the endpoint with a Syracuse user that has suitable security profile ; but, in our context, the investment on that feature had great ROI.
By the way, such explained improvement could (should ?) be a standard feature proposed by Sage as most of clients only have 1 single Sage product behind a Syracuse instance (whatever its indeed designed for more).