Easy question

[Former Member]

Hi,

I've been asked to set up a portal version of SAP Logon so we can look at SSO. We have ECC 6.0 portal and systems as well as some 4.6C.

I've got everything working, but have a few remaining issues.

I created seperate pages inside the same workset, one page per instance. The role is set as an entry point.

1. Does that sound like a sound approach?

2 The problem is when the user logs on, it attempts to immediately log them onto the system attached to the first page, in our case the development 4.6C system. Most people are not defined in the development 4.6C system and have no reason to attempt to log on, so this is inappropriate. I want to present the options to the end users, but not attempt to automatically log them on. Any thoughts?

Points will be awarded.

Thanks and best regards,

Russ Brooks

[Former Member · Accepted solution]

Hi Russ,

Your approach for Q1 sounds good. Just remember the standard Portal approach. Iview is to show what the user should see, the Page is the layout, the role is to assign to a user/groups of users.

As mentioned by GLM, the best way, since you already have most iof the setup done, is to have different groups/roles for

different target audience.

What the user can see is basically from the iview and with the iview, you setup different system of which it should be connected. This means that you can also actually setup a basic standard transaction (like transaction for workplace SBWP) iview to show to your user with your Quality/Prod system. This way, can you also show the benefit of SSO to backend system.

Hope that helps.

Ray

[Former Member · Accepted solution]

Thanks Ray.

It isn't a problem to recreate if there is a better overall design. Not really understanding your third paragraph. I'm using the SAP transaction IView, which can only be pointed one SAP instance at a time. So what you're suggesting is something like this?

Dev_folder

Dev_Role for client 1

Dev_Workset for client 1

Dev_Page for client 1

Dev_IView for client 1

Dev_Role for client 2

Dev_Workset for client 2

Dev_Page for client 2

Dev_IView for client 2

QA_folder

QA_Role

QA_Workset

QA_Page

QA_IView

PRD_folder

PRD_Role

PRD_Workset

PRD_Page

PRD_IView

[Former Member · Accepted solution]

Hi Russ,

Every transaction iview require you to fill in a system. So if you have created the systems for Dev, QA and Production in the Portal, then connect your transaction iview as below.

1) Dev_Role for client 1

Dev_IView for client 1: System target Dev (remember..its system alise that you use here). TC: SBWP (example)

20 Dev_Role for client 2

Dev_IView for client 2: System target Dev (remember..its system alise that you use here) TC: SU3 (example)

3) QA_Role

QA_IView: System target QA (remember..its system alise that you use here) TC: SBWP

4) PRD_Role

PRD_IView: System target Dev (remember..its system alise that you use here)TC: SBWP

So, to show SSO with different systems/enviornment, whenever a user is assigned with the role mentioned above, he/she will see the Transaction appear in the iview (of course, he/she should have the authorisation to run the transaction), be it if the transaction is in Dev or QA or Prod, the Portal will just show it and the user will not know which environment that transaction iview connected to which system.

Basically, you have have as many system as you want in the Portal and link as many iviews to different systems (one to one relationship that is). Hopwever, its a good rpactise to keep your landscape clean. For example on what was setup on my side. And of course, a good overview of the concept is important..agree )

What we have here is that we have 3 tier landascape Portal.

Dev Portal: Link to Sandbox/Dev systems (BI and ERP etc)

QA Portal: Link to QA systems (BI and ERP etc)

Prod Portal: Link to Prod systems (BI and ERP etc)

Hope that helps.

Ray

Edited by: Raymond HENG on Oct 9, 2008 4:54 PM

[Former Member · Accepted solution]

Hi Raymond,

Thanks for the great suggestion. Yes, I can see the advantages of having multiple portals. Not sure I can talk management into the hardware, but I'll certainly investigate it.

I'm curious about one thing, though. Most development systems I've seen have multiple clients (customization, unit test, golden, ...) The SAP Transaction IView points you to a specific client.

1. Are you therefore defining an IView (and role since the users could vary) for each development client?

2. If a user is defined to multiple clients/roles in the development system, how are you controlling which client they are initially sent to? Can they pick and choose which of the available clients they want to hit prior to being logged on?

Thanks again,

Russ Brooks

[Former Member · Accepted solution]

Hi Russ,

1) Yes, but we keep it simple for testing purposes. Meaning we have only 1 Dev system and 1 client; and 1 Sandbox system with 1 client as well for "playground" purposes. Thus, its not really alot that needs to be maintain. Once you are sure of the "tested" iview, you transport it to your QA Portal for "real" data testing before importing it to your prod Portal.

2) Hm..its more like a self descipline of the admin. Normally I keep a close eye on the testing assignments. Not sure if there is a monitoring tool that you can use (maybe some other guys can help you here). Your Dev Portal should not have much users playing but mainly consultants and IT users.

I do not think the user can choose the clients to log in if you have already setup SSO and tyhe system that the iview is connected to.

Hope that helps and award points for helpful suggestions.

Ray

[Former Member · Accepted solution]

Hi Ray,

Thanks for your reply.

Best regards,

Russ Brooks

[Former Member]

Wouldnt it be better to create different role for different groups of ppl based on which system they need access to?

Thanks,

GLM