Bex Analyzer - Broadcast Creation User

[DanH1]

Hi folks,

Appreciate any insight or best practice on this one.

In creating an information Broadcast schedule (BW 3.5) is it most common to use an individual business account or a common generic account to create broadcasts.

We have the issue of traceablity/accountabilty with the generic user.

Thanks !

[Former Member]

Broadcast setting is scheduled by an individual user but the actual execution is done using generic system user as a background job / SAP background processing.

How was the broadcasting scheduled in your case? And why is there an accountability issue?

[DanH1]

Thanks for the reply..

In our case the business wants a generic user to be able to create the broadcast. The dilema here is a generic user with dialog access, shared password among power users-(not favored from our compliance) . The downfall of having a individuals create the broadcast is that if they leave the company

and there accounts are deleted the schedules will all have to be recreated. Just wondering what the typical approach was for this.

[Former Member]

If the user can be defined in customizing (like it is in workflow) then you can assume that the foreseen scenario is a generic user, and for traceability you need to go back to the source application or system.

In some options, you can save the user ID as a variable, and they will be prompted to logon as themselves.

If someone leaves the company, it is best that you do not delete the ID, but rather use it either in a delegation (the calling application would perhaps like to know this...) or use hierarchies in the called application.

bname, ename, sy-uname, call them what you want... these checks cause nothing but trouble...

Cheers,

Julius

[DanH1]

Thanks Julius ..not familiar with some of the areas you are referring to but the development may have something here. The variant you were speaking of that more in the workbook ?

[Former Member]

What I meant was that you can still use RFC integration, but leave the user name empty or set as a variable of field syst-uname. The person (a.k.a. the caller) will need to logon (intended use: as themselves) to open the connection and broadcast or transfer data or read details or whatever.

On the otherhand, logon prompts (particularly when unexpected) are not a nice design for the user to get used to either... and perhaps the broadcasting functionality should not be called directly by the end user either, hence the generic destination defined user (although that it not a valid excuse in my books for bad integration design in interfaces).

I know about some scenarios like this where ALEREMOTE is defaulted in BI, and generally with the principles, but not specifically about requirements for Broadcasting from BEX though. Is that what you are refering to?

Cheers,

Julius

[DanH1]

Thanks Julius ... This would be specific to Broadcast scheduling from Bex, where the used logged in to

broadcast a workbook is the creation user of the batch schedule even though an alternative auth user can specified to actually perform the job run,we have the issue of an open generic dialog user on the system.

Wondering what the typical approach is for a standard generic or the named business user.

Thanks Again !

[Former Member]

Then I seem to have misunderstood the scenario. Sorry.

Using the logged on user to submit a job is nothing new and okay. Using it to schedule a periodic job is a rather ugly design, but as long as you are not deleting the user ID you can move it into a secure "retired" user group.

But ideally you would want to apply an administrator lock or restrict validity and then lock the idle password (perhaps better...).

> Wondering what the typical approach is for a standard generic or the named business user.

The named business user is always better IMO, as long as it does not conflict with other requirements or create dependencies on keeping itself "alive".

I would suggest moving this thread (I can do that for you) to the BI-BEX forum to continue the discussion and see what other gurus there think about it and which solutions they have found to work best (althought security might not be the initial or main focus).

Do you agree?

Cheers,

Julius

[DanH1]

Thanks Julius.... I have a question as well there in BI-Business Explorer forum, see what comes from that.

Thanks for the input.. Dan

[Former Member]

Duplicate or Cross-posting is against the forum rules because wide scale use of it made a mess of the forums in the past.

So I will lock this thread. Please use the other thread to post further and cross-reference to this one if relevant.

=>

Cheers,

Julius