I am trying to write a script that will send pieces of a report out to different users. I know it can be done, but I can’t recall the code to do it. If someone could help, I’d greatly appreciate it. Thanks in advance.
Seth Cohen
Systems Engineer
Profound Solutions
317.579.5100/1.800.411.2755
fax: 317.579.6279
Listserv Archives (BOB member since 2002-06-25)
Hi All,
I searched the archive to no avail to answer my question. I have a report that has open sales quotes by order taker. I want to use report bursting to send these individuals their open quotes. I realize for bursting you set row level restrictions. The tricky thing is the row numbers are dynamic.
Has any one set up report bursting based on user name? If so, please explain.
Thanks,
Kevin
Listserv Archives (BOB member since 2002-06-25)
Kevin
From: Kevin Brown busobjx@HOTMAIL.COM
Date: Fri, 22 Sep 2000 11:15:17 -0400
I searched the archive to no avail to answer my question. I have a report that has open sales quotes by order taker. I want to use report bursting to send these individuals their open quotes. I realize for bursting you set row level restrictions. The tricky thing is the row numbers are dynamic.
Has any one set up report bursting based on user name? If so, please explain.
Row level restrictions refers to the security facility that restricts the users access to the data retrieved. In your case you may have restrictions that restrict the order taker to only see his/her orders based on taker id. If those restrictions apply to the users then the report bursting facility will create a version of the report that shows only the takers orders. In this case the report bursting facility will make your life very easy.
Hope this helps.
Mike McErlain
_________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at http://profiles.msn.com.
Listserv Archives (BOB member since 2002-06-25)
You can set profile restriction based on SQL that allows you to filter on conditions. So you can filter based on the user name.
Lucia Chan
Kevin
From: Kevin Brown busobjx@HOTMAIL.COM
Date: Fri, 22 Sep 2000 11:15:17 -0400
I searched the archive to no avail to answer my question. I have a report that has open sales quotes by order taker. I want to use report bursting to send these individuals their open quotes. I realize
for
bursting you set row level restrictions. The tricky thing is the row numbers are dynamic.
Has any one set up report bursting based on user name? If so, please explain.
Row level restrictions refers to the security facility that restricts the users access to the data retrieved. In your case you may have restrictions that restrict the order taker to only see his/her orders based on taker id. If those restrictions apply to the users then the report bursting facility will create a version of the report that shows only the takers orders. In this case the report bursting facility will make your life very easy.
Hope this helps.
Mike McErlain
_________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at http://profiles.msn.com.
Pls report bounces in response to postings to BUSOB-L-Request@listserv.aol.com
Web archives: listserv.aol.com/archives/busob-l.html To change service: Mail to listserv@listserv.aol.com with text in body of note
- To Unsubscribe: ‘unsubscribe BUSOB-L’ - Vacation Options: ‘set BUSOB-L nomail’ ‘set BUSOB-L mail’
Listserv Archives (BOB member since 2002-06-25)
In a message dated 00-09-22 13:43:05 EDT, you write:
I searched the archive to no avail to answer my question.
I have a report that has open sales quotes by order taker. I want to use report bursting to send these individuals their open quotes. I realize for bursting you set row level restrictions. The tricky thing is the row numbers are dynamic.
Has any one set up report bursting based on user name? If so, please explain.
Row level restrictions are not based on the row of the report, but on rows in the database. What you do is select a user (or group of users) and enter a “where clause” for a particular table. Any time that user uses that table, the “row level restriction” (where clause) is added to the query.
Report bursting works by logging in as each individual user and running the report. By logging in as that user, the appropriate where clause is used.
It’s an interesting solution. If you run report bursting for 200 different users, BCA actually logs in and runs 200 different versions of the same report.
Regards,
Dave Rathbun
Integra Solutions
www.islink.com
Listserv Archives (BOB member since 2002-06-25)
On Fri, 22 Sep 2000 14:28:56 EDT, DRathbun@AOL.COM wrote:
In a message dated 00-09-22 13:43:05 EDT, you write: Row level restrictions are not based on the row of the report, but on rows
in the database. What you do is select a user (or group of users) and enter a “where clause” for a particular table. Any time that user uses that table, the “row level restriction” (where clause) is added to the query. Report bursting works by logging in as each individual user and running the report. By logging in as that user, the appropriate where clause is used. It’s an interesting solution. If you run report bursting for 200 different users, BCA actually logs in and runs 200 different versions of the same report.
Regards,
Dave Rathbun
Integra Solutions
In an earlier msg, a lister stated “overwrite mode is not available when you schedule a document to run with the recipient’s profile.” Why is this? Is there a way to overwrite documents sent to BCA to Refresh with the Profile of Each Recipent?
TIA
Listserv Archives (BOB member since 2002-06-25)
If you run report bursting for 200 different users, BCA actually logs in and runs 200 different versions of the same report.
Does anyone know what userid/pw is used when the variable BOUSER/BOPASS is used in the database connection and the No Password Checking is set in the user profile of each user?
Regards, Michiel Brunt
Listserv Archives (BOB member since 2002-06-25)
The UserID and password typed into the logon screen.
Barbara Rosen
Business Objects Administrator
Global Database Architecture & Engineering Services Salomon Smith Barney
barbara.rosen@ssmb.com
Listserv Archives (BOB member since 2002-06-25)
does anyone out there have a white paper on report bursting? if so… please email it to me at wetsel_rod@bah.com
THANKS!!
ROD
Listserv Archives (BOB member since 2002-06-25)
Is there any way to burst and distribute a document via BCA based on the value associated with a dimension object? That is, if I section a report based on Sales Rep can I route sections to sales reps based on the value of the sales rep object using a single document through BCA? If yes, can you point me to where this is described in the documentation? This is my first submission to Listserv. Pardon me if my terminology is not entirely correct.
Rick Mason, Directions Group
rmason@directionsgroup.com
315-682-4402 (phone, fax)
315-391-0618 (cell)
Listserv Archives (BOB member since 2002-06-25)
You asked…
Is there any way to burst and distribute a document via BCA based on the value associated with a dimension object? That is, if I section a report based on Sales Rep can I route sections to sales reps based on the value of the sales rep object using a single document through BCA?
Me…
Although our sales presentation specifically stated otherwise despite our vehement protests to the contrary…
No. BO doesn’t do TRUE report bursting…yet 
You can, however, set up restrictions as to what each Sales Rep is physically allowed to view (via row restrictions for example) and then refresh the document and distribute using each individual Salesperson’s profile.
If you want TRUE bursting… i.e. hit the database once and selectively distribute the results, you’ll have to do some pretty fancy stuff on your own.
The archives are a great source of this type of info
Good luck!
Cindy Clayton
Ask WHY until you understand!
Overlooked blessings…
Laughing so hard your sides hurt and you can’t catch your breath… Daydreams…
The feel of a child in your arms…
Listserv Archives (BOB member since 2002-06-25)
The ‘Mistral’ add-on to BCA is supposed to do this for you. I will be going ‘beta’ soon and testing features such as this. If you use the SDK you can probably write VBA script to AppyFilter then populate the report with that selection criteria. Try populating a table with your selections (Acct1, Acct2, …) then looping through the table values ‘n’ times.
From: Cindy Clayton [SMTP:cindy.clayton@SLKP.COM] Sent: Friday, March 16, 2001 10:03 AM
You asked…
Is there any way to burst and distribute a document via BCA based on the value associated with a dimension object? That is, if I section a report based on Sales Rep can I route sections to sales reps based on the value of
the sales rep object using a single document through BCA?
Me…
Although our sales presentation specifically stated otherwise despite our vehement protests to the contrary…
No. BO doesn’t do TRUE report bursting…yet
You can, however, set up
restrictions as to what each Sales Rep is physically allowed to view (via row
restrictions for example) and then refresh the document and distribute using
each individual Salesperson’s profile.
If you want TRUE bursting… i.e. hit the database once and selectively distribute the results, you’ll have to do some pretty fancy stuff on your own.
The archives are a great source of this type of info
Listserv Archives (BOB member since 2002-06-25)
Previously on this list a few days ago Dave and Cindy gave some hints on report bursting. I seem to have gotten it to work but I need to be sure I did it correctly. We want to release some reports to customers where they can only see their information. Here is how I currently have it working:
This then displays the report rows only for the customer who is logged in to WEBI. I tried just using 1 and 2 above and that did not work. I had to add 3 to make it work. I believe that if I have 4 customers set up BCA would produce a report for each customer and send that report to their inbox. If so I cannot explain why #3 had to be added to the report. If I do not have #2 BCA doesn’t see a profile and I just get a blank document that must be refreshed by the user and I’m not sure why this is. Can anyone explain exactly what is actually happening behind the scenes here?
Shannon Lee Wittal
Information System - Pewaukee
Listserv Archives (BOB member since 2002-06-25)
REPLY>
I haven’t implemented this but have done some testing. To get ours to work I did steps 1 and 2 but didn’t need to create the universe filter (step 3).
When you added the row level restriction for the universe did you have the user id selected or the folder that they were in ? The WHERE clause that you enter in the universe properties, in the ROW tab should be added to any query the user runs. Sign-on as this user and review the SQL and see if the WHERE is there or not. If it is, but, bursting is not working then check, in Supervisor, to see if you have Business Object properties for documents
Do not refresh with the profile of each recipient disabled (orange light)
If this is enabled, disable it. This setting works backwards, if you want to use the refresh with profile this option must be disabled Michele
michele.pinti@standardregister.com
QUESTION>
Listserv Archives (BOB member since 2002-06-25)
Hi, Shannon.
#2 will not work on its own if the report does not contain a reference to the CUSTOMER table. It sounds like this is the case if the bursting worked with #3, when with the addition of the condition, you added a reference to the CUSTOMER table.
Hope this helps,
Luis Gonzalez
Listserv Archives (BOB member since 2002-06-25)
Thanks Michele - see my reply in caps below.
Shannon Lee Wittal
Information System - Pewaukee
Listserv Archives (BOB member since 2002-06-25)
Michele,
Did you sign off and on to the reporter after making the change in supervisor? If not, then the row restriction wouldn’t be known (unless you have enabled real time security updates, which most people don’t). This has caught me in the past.
The other possibility would be that the customer table wasn’t in your query unless you did step #3. It is important for this scheme to work that the CUSTOMER table be included in ALL queries that your outside users could generate from this universe.
Another thought, what I have done successfully with this type of security is to create an object in Designer that is defined as BusObj User = @Variable(‘BOUSER’). I then create a group (in your case CUSTOMERS) in supervisor, and put the restriction at the group level CUSTOMER.CUST_ID = @Select(BusObj User). Then, I place all users needing this restriction in this group. That way, I don’t have to remember to add the row level restriction to each user.
Hope this gets you on the right path.
Mike
From: Wittal, Shannon [SMTP:Shannon.Wittal@QG.COM] Sent: Thursday, May 17, 2001 4:13 PM
Thanks Michele - see my reply in caps below.
Shannon Lee Wittal
Information System - Pewaukee
- (414) 566-6775
- shannon.wittal@qg.com
REPLY>
I haven’t implemented this but have done some testing. To get ours to work I did steps 1 and 2 but didn’t need to create the universe filter
(step 3).
When you added the row level restriction for the universe did you have the user id selected or the folder that they were in ? SHANNON: USER ID
The WHERE clause that you enter in the universe properties, in the ROW tab
should be
added to any query the user runs. Sign-on as this user and review the SQL
and see if the WHERE is there or not.
SHANNON: THE WHERE CLAUSE ONLY APPEARS WHEN 3 IS IMPLEMENTED
If it is, but, bursting is not
working then check, in Supervisor, to see if you have Business Object properties for documents Do not refresh with the profile of
each recipient disabled (orange
light) If this is enabled, disable it. This setting works backwards, if you
want
to use the refresh with profile this option must be disabled
SHANNON: I DID HAVE THE OPTION DISABLED.
Michele
michele.pinti@standardregister.com
QUESTION>
Previously on this list a few days ago Dave and Cindy gave some hints on
report bursting. I seem to have gotten it to work but I need to be sure I
did it correctly. We want to release some reports to customers where they
can only see their information. Here is how I currently have it working:
- I have a user set up in supervisor called CU000 (this is the customer’s
cust_id in our customer table).- I then went to the universe and set a row level restriction on the CUSTOMER table that reads CUSTOMER.CUST_ID = ‘CU000’ 3. I added created a filter in the universe - @Select(Customer\Customer
Code) = @Variable(‘BOUSER’)) and I applied this to the report. 4. I sent the report to BCA checking the “Refresh with the profile of each
recipient” and sent it to the users.
This then displays the report rows only for the customer who is logged in to
WEBI. I tried just using 1 and 2 above and that did not work. I had to add
3 to make it work. I believe that if I have 4 customers set up BCA would
produce a report for each customer and send that report to their inbox. If
so I cannot explain why #3 had to be added to the report. If I do not have
#2 BCA doesn’t see a profile and I just get a blank document that must be
refreshed by the user and I’m not sure why this is. Can anyone explain
exactly what is actually happening behind the scenes here?
Shannon Lee Wittal
Information System - Pewaukee
- (414) 566-6775
- shannon.wittal@qg.com
Listserv Archives (BOB member since 2002-06-25)
What kind of problems have you encountered with Real Time Row updates turned on?
Snezana Ogrizovic
Decision Support Specialist
Quad/Graphics - Information Systems Department (414) 566-6163
Listserv Archives (BOB member since 2002-06-25)
QUESTION>
Have you added any object from the table that is to be filtered ? For example:
SELECT
PRODVW.Plant_Hierarchy_C.Plant_Type_Nm
FROM
PRODVW.Plant_Hierarchy_C
WHERE
PRODVW.Plant_Hierarchy_C.Plant_Cd = ‘PHX’ <<<< this gets added because of row level restrictions
but will not get added if I do not select an object from the Plant_Hierarchy
Michele
REPLY>
Thanks Michele - see my reply in caps below.
Shannon Lee Wittal
Information System - Pewaukee
REPLY>
I haven’t implemented this but have done some testing. To get ours to work I did steps 1 and 2 but didn’t need to create the universe filter (step 3).
When you added the row level restriction for the universe did you have the user id selected or the folder that they were in ? SHANNON: USER ID
The WHERE clause that you enter in the universe properties, in the ROW tab should be
added to any query the user runs. Sign-on as this user and review the SQL and see if the WHERE is there or not.
SHANNON: THE WHERE CLAUSE ONLY APPEARS WHEN 3 IS IMPLEMENTED
If it is, but, bursting is not
working then check, in Supervisor, to see if you have Business Object properties for documents Do not refresh with the profile of each recipient disabled (orange
light) If this is enabled, disable it. This setting works backwards, if you want
to use the refresh with profile this option must be disabled
SHANNON: I DID HAVE THE OPTION DISABLED.
Michele
michele.pinti@standardregister.com
QUESTION>
Listserv Archives (BOB member since 2002-06-25)
Just performance issues. Every time you do something in BusObj, it rechecks security, which is done by running queries against the repository. With it turned off, the only time the user is hitting the repository is when they sign on. Give it a shot and see if you have any difference in number of hits to your repository, or in overall performance. If you don’t, then I would leave it on.
Mike
From: Ogrizovic, Snezana [SMTP:Snezana.Ogrizovic@QG.COM] Sent: Thursday, May 17, 2001 4:36 PM
What kind of problems have you encountered with Real Time Row updates turned
on?
Snezana Ogrizovic
Decision Support Specialist
Quad/Graphics - Information Systems Department (414) 566-6163
Michele,
Did you sign off and on to the reporter after making the change in supervisor? If not, then the row restriction wouldn’t be known (unless
you have enabled real time security updates, which most people don’t). This has caught me in the past.
The other possibility would be that the customer table wasn’t in your query unless you did step #3. It is important for this scheme to work that the CUSTOMER table be included in ALL queries that your outside users could generate from this universe.
Another thought, what I have done successfully with this type of security is to create an object in Designer that is defined as BusObj User = @Variable(‘BOUSER’). I then create a group (in your case CUSTOMERS) in supervisor, and put the restriction at the group level CUSTOMER.CUST_ID = @Select(BusObj User). Then, I place all users needing this restriction in this group. That way, I don’t have to remember to add the row level restriction to each user.
Hope this gets you on the right path.
Mike
Listserv Archives (BOB member since 2002-06-25)