Reporting Services


Jag har hos en kund installerat Reporting Services i ”Integration Mode” mot deras MOSS-installation.

Det gick bra att lägga upp rapporter och även skapa en prenumeration på en rapport så jag skulle få den via mail. Dock när tidpunkten för den schemalagde rapporten inträffade kom inget mail. Om jag sedan klickade på ”Hantera Prenumerationer” (Manage Subscriptions), stog servern och funderade ett bra tag. Sedan möttes man av meddelandet ”An existing connection was forcibly closed by the remote host”.

Gick man in på en rapport där man inte har någon prenumeration så fungerar allt som det skall.

Ingen loggar på vare sig MOSS-servern eller RS-servern gav några förnuftiga indikationer. Till slut visade det sig dock att det var Anti-virus-systemet på servern som hade en Anti-spam funktion. När jag la till ReportServicesService.exe som undantag från den regeln, plockade bort rapporten och la till en igen så fungerade allt som det skulle.

Jag har tidigare skrivit om det här felet som uppstår om man skall kommunicera med en server via SSL och det certifikat som servern använder på något sätt inte är gilltigt. Antigen litar maninte på utfärdaren, det kan vara spärrad, ingen spärrlistainformation finns med, något är fel med datumen eller någonting annat.

I mitt förra inlägg skrev jag exempel på hur man i kod kan undvika kontroll av sådana SSL-certifikat. Nu är det ju inte alltid man vill eller kan ändra koden, så hur gör man om man annars då? Jo, först och främst kan man se om man inte kan installera root-certifikatet till den som har utfärdat SSL-certifikatet. Det bör man kunna göra även om man har ett internt certifikat. Har man använt SelfSSL eller liknande kan det uppstå problem, men skapar man det på den dator som skall ta emot responsen borde även det fungera eftersom det då blir den datorn (klienten) som har utfärdat certifikatet (detta har jag dock inte provat!).

Men sen kan man ha flera problem, exempelvis att certifikatet inte innehåller någon revocation-information eller att namnet inte stämmer med de anrop du gör. Detta löser man genom att i machine.config ändra värden i servicePointManager. Om man inte vill göra något namn- eller revokeringskontroll ställer man in den enligt följande:

<servicePointManager checkCertificateName="false" checkCertificateRevocationList="false" />

Enda nackdelen är väl att man sätter delar av säkerheten ur spel, så gör det här endast i utvecklings- och testmiljöer!

Du kan hitta mera info om detta på MSDN

När vi skulle lasttesta en webbapplikation där vi bland annat hämtar en rapport från Reporting Services med hhälp av dens web service, fick vi plötsligt 'Too many requests for user: DOMAIN\user'.

Detta löser man enkelt genom att gå in i RSReportServer.config och ändra värdet MaxActiveReqForOneUser från defaultvärdet 20 till det man önskar. Värdet finns där för att förhindra belastningsattacker.

Ytterligare (och även MaxActiveReqForOneUser) konfigurerbaravärden kan man läsa om här.
Vill du läsa mer om att last-/stresstesting av och hur man skall planera för skalbarhet i Reporting Services har Microsoft en artikel här.

Microsoft har påbörjat ett projekt tillsammans med några av sina partners. Några för sina kunskaper inom BI och en del för att dom kan bidra med lösningar som på annat sätt bidrar till den helhet MS är ute efter att uppnå med projektet.

Det som skall komma ut ur projektet är en rad best-practices för att skapa BI applikationer med hjälp av SQL Server 2005.

REAL är en akronym för Reference implementation, End-to-end, At scale and Lost of users. Men det skall väl även indikera att man använder ‘real-data’ från en riktig kund och skall hållas vid liv i en day-to-day business.

Det finns en hel del att läsa på webbsiten: http://www.microsoft.com/sql/solutions/bi/projectreal.mspx

Eftersom Reporting Services för SQL Server 2000 inte verkar ha stöd för svenskt språk fick jag använda en inbygd funktion för att formatera datum och tid enligt svenskt format (inklusive 24-timmars):

=CDate(Fields!dbFaelt.Value).ToString(”yyyy-MM-dd hh:mm:ss”)

Ingen optimal lösning, men det funkar.

När man bytte lösenord för SA i en SQL Server 2000 som även kör Reporting Services, slutade plötsligt allt att fungera. Jag insåg snabbt när jag hadde pratat med den DBA som hadde bytt lösen att Reporting Services använde SA för att komma åt sin databas. Men hur skulle man ändra det?

Kom fram till att ‘rsconfig’ var den rätta vägen. Dock fick jag det inte att fungera. Efter att ha läst felmeddelandet i eventloggen ett antal gånger kom jag på att någon hadde fipplat med filen RSReportServer.config manuellt, och lagt in användare och lösen på den användare som skall köra ‘Unattended Reports’ manuellt. Det tyckte inte Reporting Services om eftersom den inte kunde dekryptera det som stog i fälten. Efter att ha plockat bort de texter som stog i ‘UserName’, ‘Password’ och ‘Domain’ i sektionen ‘UnattendedExecutionAccount’ fungerade det. Jag kunde sätta om användare och lösenord.

Sen tänkte jag som så att jag måste väl även använda den användaren mot ‘ReportServerTempDB’……..

Det var då nästa fel dök upp:

The version of the report server database is either in a format that is not
valid, or it cannot be read. The found version is ‘T.0.6.xx’. The expected
version is ‘C.0.6.xx’. To continue, update the version of the report server
database and verify access rights. (rsInvalidReportServerDatabase)

Eller i alla fall insåg jag efter ett tag att det var det som orsakade det. Så efter att ha kört rsconfig på nytt, nu mot ‘ReportServer’, fungerade det igen.

Det fungerade med såväl SQL-användare som Windows-användare. Mycket smidigt tycker jag. Har dock inte testat att köra med ‘impersonate’, alltså att den använder den användare som kör processen. Men jag skulle gissa att om man bara ger den process som kör IIS behörighet mot databasen skulle det fungera.

 UPDATE:

Om man skapar eller lägger till en användare i databasen (ReportServer), kom ihåg att lägga till behörighet till rollen ‘RSExecRole’!

När jag deployade en ny version av mina rapporter slutade en av rapporterna plötsligt att fungera. Samtidigt hadde jag bytt ut min DataExtension också.

Jag fick hela tiden felet ‘there is no data for the field at position 1’, men fattade inte varför. Efter mycket om och men hittade jag till slut att det visade sig att rapporten inte alls hadde deployats.

Och i min DataExtension hadde jag bytt namn på några kolumner i datat som skulle returneras, vilket medförde att rapportens förväntade kolumner inte stämde med det som returnerades av datakällan, och felet var ett faktum.

Efter en ny deploy av rapporten försvann felet.

Nästa sida »