For the intention of this blog post I assume a customer has been running only R/3 so
far and is adding a Gateway and SUP server into the mix. Additionally I assume
that until now there were few enough users using the R/3 system such that all
of them could be created manually, one by one. Our first incarnation of mobile
apps for casual use (e.g. Financial Fact Sheet or SAP Interview Assistant) do require
a user to exist in R/3, Gateway and SUP (when using basic authentication).
Now the challenge is that when such customer extends his roll-out to serve thousands of
employees creating the users manually and in 3 different systems it is tedious
and does not really scale. There might be 10s of new employees each day that
need to be added and when a new region receives a roll-out then 100s of users
need to created at once. In this blog I would like to point out some basic
ideas of how this can be addressed. In your particular situation few or none of
the suggestion might be feasible - so this is more of an overview to make sure
you are aware of all the options.
Suggestion 1: Move Gateway into R/3: Instead of a separate server you
can put Gateway onto the R/3 box directly. The necessary plugin is available
not just for Netweaver 7.03 but also for earlier releases down to 7.00. But
beware, only apps that support OData (and not the previous protocol called
SData) like the latest version of FinancialFactSheet work with a Gateway
version that runs on NW 7.00 or 7.01. Interview Assistant does not (yet)
support OData. Also, keep i mind the reasons why you might want the Gateway to
be a separate server (avoid load on the R/3 box, security by doing the protocol
translation on a dedicated server).
Suggestion 2: Use automatic user onboarding in
SUP: when using
basic authentication early versions of our apps and mobile sdk hardcode the
basic authentication method together with the manual SUP user creation. The
later part adds additional security as SUP has to have a positive (white) list
of users defined that are the only once allowed to onboard. But as SUP has
evolved (version 2.1.1 onwards) and the apps have been updated this is not tied
together anymore. So if you use a more recent version of the app (e.g. FinancialFactSheet
or any of the new apps we shipped in April or July) then you do not have to
create users manually anymore when using basic authentication.
Suggestion 3: Use the Central User Administration: This capability is a little trick
to set-up (http://scn.sap.com/docs/DOC-17019 and http://www.youtube.com/watch?v=v7h4S_His-g give an overview) but does
the job of replicating users created in a server (e.g. a client in R/3) to a
client (the Gateway machine). As there is a trusted connection set-up already
between Gateway and R/3 this is partially done if you already have implemented
Gateway. If your end users are true casual users that never log into the R/3
system then you should create the user in R/3 without (initial) password and in
Gateway with a password to ensure access for this user is only via Gateway. If
you happen to use Solution Manager then this can also be the leading system for
the central user administration (see http://scn.sap.com/thread/578177).
Suggestion 4: Create multiple new users at once: A simple approach is described
here: http://scn.sap.com/thread/1207325. Both this and the manual user
creation will trigger the replication of users to other ABAP-based system if
the central user administration is configured.
Suggestion 5: SAP Identity Management: If you will have additional
systems to distribute this user too it makes sense to consider going with a
dedicated server for identity management (http://scn.sap.com/community/netweaver-idm).
If you are aware of other options please let me know – I would like to find ways to
make the administration of 1000s of casual users as simple as possible. From an
IT point of view but also from a casual user point of view.
