โ04-20-2017 02:49 PM
Hello all,
Weโre in the process of on-boarding our first Citizen Integrator in the SnapLogic Platform. Weโve previously federated the development of production integrations to LOB developers, but the Citizen Integrator has a different set of requirements and Iโd like to start a discussion as to how best to accomplish this.
Below is the criteria weโre trying to meet:
Weโre considering a few options, each with drawbacks and advantagesโฆ
We could make a new Project Space, as our current development teams have their own project spaces. This gives the marketing team access to shared assets, but puts them into the same production environment as mission critical integrations.
We could perhaps create an entire new org. This would keep them isolated and I think we could assign a node specifically to that node to manage resources. But theyโre not able to see shared objects unless we manually move them over. Iโm also not sure if there is a cost involved here.
Iโd love to hear from anyone else that has already gone down this road. What methods did you try? What worked, and what didnโt?
Thanks in advance!
Brett
โ04-28-2017 11:54 AM
Thanks for the thought-out responses!
Or environment currently consists of 3 Orgs (Dev, QA, Prod)
We have 2 SnapPlexes (Cloud and Ground) that are at the Org-Shared level.
We have defined Project spaces to align with line-of-business development groups
Org
Ecommerce
Corporate Systems
Store Systems
etcโฆ
Marketing is the first set of users that arenโt purely development groups but will not be the last. This needs to a be a practical and sustainable pattern going forward. Seeing as how Orgs cost money, it wonโt be accepted very well for departments with one or two users.
The solution weโre leaning toward is to
A) create a new project space called Marketing
B) create a new SnapPlex called Marketing within the Marketing project spaceโs share.
We have 4 additional nodes pending installation. As far as I know, we should be able to assign one or more of those nodes to the Marketing SnapPlex to isolate the server resources to that group. The problem that remains is keeping the Marketing users from running their pipelines on the Cloud or Ground SnapPlexes. I see two option here. First, as Time mentioned, is to move the existing SnapPlexes down from the org share into a lower level. The problem is that we have many Project Spaces that would all need to have SnapPlexes made. The second option is to remove access from โall usersโ to the org shared folder. Instead, put every user in a group and grant that group access. Keep marketing left out in their own group that only has access to their Project space. Weโd just need to move down common shared objects that we want the the Marketing group into their project space as well.
We do have an Integration Success Team in place to facilitate this sort of management within SnapLogic.
Side note: Seems a bit strange that a SnapPlex, which is merely a run-time environemnt, is shared along with other pipelines and accounts rather than their own type of entity that can have access granted outside of the project structure.
โ05-03-2017 02:58 PM
@tlui and I were talking about this the other day. Weโre certainly open to suggestions to make the workflow more logical; FWIW, Iโm with you on this one, but if weโre going to separate it out we want to make sure the redesign is actually a better user experience, so feedback is very welcome.
Shayne
โ05-17-2017 10:22 AM
@shodge, my feedback on this, without a lot of analysis to determine caveats, is to create an org-level configuration to host snaplexes (either instead of or in addition to project-level configuration). Then each project (or project space) could be configured to target any or all snaplexes at org level. Then permissions to certain org-level snaplexes (for user, pipeline, task, etc.) would be inherited from the project (or project space) permissions to related snaplexes.
use case: projA has access to snaplexA & snaplexB while projB has access to snaplexA & snaplexC and projMarketing only has access to snaplexMarketing.
โ05-22-2017 11:41 AM
Thanks for the feedback.
Am I correct that this doesnโt change the current permissions model / inheritance, it just moves the Snaplexes into their own (linked back to projects) UI area?
Thanks,
Shayne
โ05-24-2017 05:41 PM
@shodge, I think you mostly captured what I was saying. I think the paradigm shift is how we look at the globally shared project. Iโve reworked my thoughts and the use case a little bit below. Iโm going to use accounts instead of snaplexes to better demonstrate the case, but it works similarly for snaplexes and shared pipelines.
Use Case:
Current options are:
So, my platform enhancement suggestion might be to create a globally shared/restricted project space where access is not controlled by a user/group mapping, but by a project mapping. Everything else in the platform remains the same.