Wednesday, April 17, 2013

System.Web.Services.Protocols.SoapException: Default value or value provided for the report parameter '<paramName>' is not a valid value

SharePoint has an odd limitation, with reporting services, user's don’t have access to properly subscribe to their own reports.  If you provide users with the ability to subscribe, they must also have access to edit subscriptions, and that means ALL subscriptions, which doesn't bode well, because users will just hate that.

So I took to creating a custom web form that allows users to edit and maintain their own subscriptions.  The form uses the SQL Reporting Services exposed web services via the ReportService2010 class (http://msdn.microsoft.com/en-us/library/reportservice2010.aspx), and uses these methods to read all report subscriptions in for a user, available parameter's for a report, etc.  I plan on doing a separate blog post on this because, frankly, I think it's cool.

Anyway, I was about to launch my afforementioned masterpiece when I receive an error in attempting to subscribe to a report: Default value or value provided for the report parameter '<paramName>' is not a valid value

This was all very confusing, because all along I have been creating subscriptions for myself and others.  The parameter values I am pumping into the report subscription are all supplied by the reportservice method GetItemParameters, which has a ValidValues property that lists what the valid values are.  And sure enough, for my parameter, I was supplying a Valid Value!

After quite a bit of debugging, tweaking some code to test some scenario's and cursing Microsoft, I found out that.. as usual.. it was an end user (me) error.  It's kind of an oddball scenario, but I imagine it could happen to others, which is why I am writing this blog post, which presumably is why you are reading it...

The report parameter that was failing for me was a user drop down list, which is generated based on who is attemping to create the report subscription.  So User A will see different values than User B.  When generating the parameter values for the report subscription, I was using the following code:

'Note, for this web form, Impersonate is set to TRUE
Dim rs As New ReportingService2010
rs.Credentials = System.Net.CredentialCache.DefaultCredentials
……
parameters = rs.GetItemParameters(“A Plethora of Parameters”)

The important line of code is the 2nd one shown above, setting the Credentials to DefaultCredentials.  When this is used to authenticate with the reporting web service, the user's credentials are passed, meaning User A or User B are sent to the server.  The appropriate values are then returned for the report parameters, so they vary properly depending on if the user is User A or User B... all as expected.

With me so far?  OK, Good...

My issue was when I was creating the report, not generating the parameter items.  To give every user the ability to create a report, without granting them access to view\edit subscriptions within SharePoint, I was executing the CreateSubscription method underneath the context of a service account, NOT as User A or User B.  So in the end, my code looked similar to:

Dim rs As New ReportingService2010
rs.Credentials = New System.Net.NetworkCredential _ ("serviceAcctName", "password", "Domain")
……
subscriptionID = rs.CreateSubscription("A plethora of parameters")

What was the issue? 

When the CreateSubscription method was executing, it was executing under the context of my "serviceAcctName" user, not as User A or User B.  This means that, even though I was passing valid values for my parameter for the user, these weren't a valid value for the "serviceAcctName" user, meaing that the exception was accurate.

In the end, I was able to tweak my back end logic that was generating the custom drop down list values to include every value possible for the "serviceAcctName" user, so no matter what user would be using my subscription manager, it would be a valid value for my service account.

I don't know how many other's will run into this particular scenario, but if you're one of them, I hope this helps!

No comments:

Post a Comment