New-RsSubscription does not accept -Parameters argument (and sets it to null) about reportingservicestools HOT 14 CLOSED

I'm coding a solution to this now. I will use [hashtable] $Parameters as the new argument to New-RsSubscription

I suggest this be a breaking change to the current New-RsSubscription interface, and that once I submit my patch, the overall module get a bump to 0.0.3.x (I'm really unclear on what it means for a project to have 0 for major and minor versions... please consider using semver - semantic versioning scheme popular among Web developers.)

from reportingservicestools.

So, the drawback to [hashtable] $Parameters is that, technically, $Parameters should support Label as well as Name-Value pair elements. I'm not aware of anyone ever actually using that feature, so I'll continue down the [hashtable] path and consider the Label feature over-engineering.

from reportingservicestools.

Actually, the easiest thing to do is create a new function, New-RsSubscriptionParametersXml, similar to New-RsScheduleXml, which will allow us not to expose the full namespace of the SSRS WSDL types and yet keep the overall integrity of the API together. Plus, most people will probably want to use something like XML to manage these externally, anyway.

from reportingservicestools.

I've got this mostly working, but can't find documentation on MSDN for how to say "This report uses default parameters" or "This report uses null valued parameters". I spied the SSRS Reports portal's Rest calls, and they pass an empty list via [] json in both cases. It seems like the SOAP API does things differently, though.

from reportingservicestools.

This is the error message that I'm receiving when trying to add a report subscription for a report that needs some parameters set:

Exception occurred while creating subscription! Exception calling "CreateSubscription" with "6" argument(s):
"System.Web.Services.Protocols.SoapException: This report requires a default or user-defined value for the report
parameter 'DeviceID'. To run or subscribe to this report, you must provide a parameter value. --->
Microsoft.ReportingServices.Diagnostics.Utilities.ReportParameterValueNotSetException: This report requires a default
or user-defined value for the report parameter 'DeviceID'. To run or subscribe to this report, you must provide a
parameter value.
at Microsoft.ReportingServices.Library.ReportingService2005Impl.CreateSubscription(String Report, ExtensionSettings
ExtensionSettings, Boolean isDataDriven, DataRetrievalPlan DataRetrievalPlan, String Description, String EventType,
String MatchData, ParameterValueOrFieldReference[] Parameters, Guid batchId, String& SubscriptionID)
at Microsoft.ReportingServices.Library.ReportingService2005Impl.CreateSubscription(String Report, ExtensionSettings
ExtensionSettings, Boolean isDataDriven, DataRetrievalPlan DataRetrievalPlan, String Description, String EventType,
String MatchData, ParameterValueOrFieldReference[] Parameters, String& SubscriptionID)
at Microsoft.ReportingServices.WebServer.ReportingService2010.CreateSubscription(String ItemPath, ExtensionSettings
ExtensionSettings, String Description, String EventType, String MatchData, ParameterValue[] Parameters, String&
SubscriptionID)"

from reportingservicestools.

I have this working in my local fork of the project and need to commit back upstream to avoid losing my changes. The big gotcha is if you export reports with parameters and try to import them back, things get crazy because of how the SSRS team handles default parameters where the default is a null. If someone at Microsoft were to explain this to me, I could probably write a robust integration.

from reportingservicestools.

I have to update my repository to 0.0.4.6 to integrate my change to make sure it works in the latest release of ReportingServicesTools. Here is a snippet of the changes - this should replace $ReportParameters = $Null at line 300:

            if ($Parameters -ne $null)
            {
                $parametersCopy = @{};
                # First, remove null-valued keys
                foreach ($key in $Parameters.Keys)
                {
                    if ($Parameters[$key] -ne $null)
                    {
                        $parametersCopy.Add($key, $Parameters[$key]);
                    }
                }

                $Parameters = $parametersCopy;

                if ($Parameters.Count -ne 0)
                {
                    $ParameterValues = New-Object "$Namespace.ParameterValue[]" $Parameters.Count

                    $i = 0;
                    foreach ($key in $Parameters.Keys)
                    {
                        Write-Output "Indexing into $i" | Out-Host
                        $tmpParameter = New-Object "$Namespace.ParameterValue"
                        $tmpParameter.Name = $key;
                        $tmpValue = $Parameters[$key]
                        if ([string]::IsNullOrWhiteSpace($tmpValue))
                        {
                            continue;
                            <#
                            $tmpName = $tmpParameter.Name;
                            Write-Output "$tmpName 's value is null" | Out-Host
                            $tmpParameter.Value = $null;
                            #>
                        
                        }
                        else
                        {
                            $tmpParameter.Value = $tmpValue # Default value or value provided for the report parameter 'date' is not a valid value.
                        }
                        Write-Output $tmpParameter | Out-Host; 
                        $ParameterValues[$i] = $tmpParameter
                        $i++;
                    }

                }
                else
                {
                    $ParameterValues = $null;
                }
            }
            else
            {
                $ParameterValues = $null
            }

Also, the signature should now say:

        .PARAMETER Parameters
            A hash that contains a set of parameters for the subscribed item.

        [Parameter(Mandatory=$True)]
        [AllowNull()]
        [hashtable]
        $Parameters

from reportingservicestools.

@jtarquino Is there a better way to code this? This is how I have it working in my production environment, which is a fork of ReportingServicesTools 0.0.2.9. The reason it's so verbose is because of the apparent stupid way SSRS API treats nulls/empty values. It looks like the behavior broke at some point from 2005 to 2016 releases, most likely between 2008 R2 and 2012 releases.

from reportingservicestools.

@jtarquino - Looking for some direction and then I can submit the patch.

from reportingservicestools.

I think your approach is feasible, I would just change the Write-Output by Write-Verbose and avoid the continue in the loop, also probably would extract that logic into a function and add testing

from reportingservicestools.

I am upgrading from 0.0.2.9 this week and plan to finally submit a patch for this to the 0.0.4.7 code.

from reportingservicestools.

@jtarquino MERGED... Tried to keep it as simple as possible but SQL Server 2012+ is very finicky . It works on my side upgrading from 2008 to 2016.

from reportingservicestools.

@wgshef FYI

from reportingservicestools.

I have had to use this last week, one problem I found is that the Hash approach does not allow to use multivalue parameters

from reportingservicestools.