In-place upgrade Dynamics CRM 2013 na 2015: Could not find file ‚C:\Program Files\Microsoft Dynamics CRM\LangPacks\1029\sql\7\StoredProcedures\MSCRM\fn_RollupByAccount.sql‘.

Při upgrade Dynamics CRM organizace z verze 2013 na 2015 s českým nebo jiným language packem (alespoň jedním nad základním jazykem), dojde při upgrade k chybě:

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.IO.FileNotFoundException: Could not find file ‚C:\Program Files\Microsoft Dynamics CRM\LangPacks\1029\sql\7\StoredProcedures\MSCRM\fn_RollupByAccount.sql‘.

Language pack obsahuje chybu, odkazuje se na soubory, které se jmenují jinak, stačí je přejmenovat a spustit znovu upgrade databáze:

  • p_RollupByAccount.sql => fn_RollupByAccount.sql
  • p_RollupByContact.sql => fn_RollupByContact.sql
  • p_RollupByOpportunity.sql => fn_RollupByOpportunity.sql

Na opravě se údajně pracuje.

Dynamics CRM 2013: chybějící záložka Konfigurace E-mailu

Po upgrade z CRM verze 2011 se některé nové volby nezobrazují, jedna z těch klíčových je náhrada za Email Router, tedy Server-Side Synchronization, která se v nově vytvořených organizacích jmenuje Konfigurace e-mailu (Email Configuration)

image

Tuto volbu je nutné doplnit zpět bohužel manuálně, postup je však jednoduchý:

[more]

  1. Stáhněte si XrmToolbox: https://xrmtoolbox.codeplex.com/
  2. Připojte se k CRM
  3. Spusťte modul SiteMap Editor
    image
  4. Načtěte mapu webu
    image
  5. Přidejte novou sub-areu pod audit a vyplňte dle obrázku:
    image
  6. Následně už jen aktualizujte CRM Update SiteMap
  7. Hotovo! (na screenshotu je akorát anglická verze)
    image

 

Druhá metoda je export do XML a přidaní jednoho node:

<SubArea Id=“nav_social“ ResourceId=“Social_SubArea_Title“ DescriptionResourceId=“Social_SubArea_Description“ Icon=“/_imgs/area/16_social.png“ Url=“/tools/social/social_area.aspx“ AvailableOffline=“false“ />

image

a následně import zpět do CRM, vše pomocí XrmToolboxu.

Vývoj vlastního CmdLetu v C# – příprava projektu Visual Studia

Vývoj vlastního PowerShell příkazu (CmdLet) je velice snadné a rychlé – ideální pro často opakované akce, případně akce u zákazníka, kde nemusí být vždy vzdálený přístup do jeho infrastruktury. Za posledních pár let už jsem jich napsal desítky a jsem jsem z toho stále nadšen, hlavně tou jednoduchostí, v podstatě jsem tím zcela nahradil jednoúčelové konzolové aplikace, kde již navíc není nutné řešit parsování argumentů, přehledná výpis na konzolovou obrazovku, všechno je již tak nějak vyřešeno. Jako příklad jednoho z CmdLetů bych uvedl snadné nasazení jedné naší aplikace hostované v Azure, kde s každým zákazníkem bylo vždy nutné přihlásit se na portál Azure, vytvořit hosting pro aplikaci, nastavit domény, standard mód, vytvořit a nastavit DB, connection string do aplikace, vytvořit storage provider, přihlašovací údaje zapsat do aplikace, nastavit zálohování, a tak bych mohl pokračovat….. až po finální nahrání zkompilované verze – prostě práce na minimálně 2-4h a to ještě s rizikem chyby. Nyní k tomu slouží dva CmdLety, jeden pro přihlášení k Azure, druhý už pro založení tenantu a provedení všech potřebných akcí zcela automaticky.

V tomto prvním díle ukážu pouze základ, založení Visual Studio projektu a jeho nastavení.

Základem vlastního PowerShell CmdLetu je založený projekt typu Class Library

image 

image

Volba verze .NET Frameworku je závislá na požadované verzi PowerShellu, pokud například skriptujete akce pro SharePoint 2010, musíte nastavit .NET Framework verze maximálně 3.5.

  • PowerShell 2.0 – .NET Framework 3.5
  • PowerShell 3.0 – .NET Framework 4
  • PowerShell 4.0 – .NET Framework 4.5
[more]

Po založení projektu je nutné ručně přidat potřebné reference, hlavní referencí je System.Management.Automation.dll, kterou naleznete (případně dle vaší verze PowerShellu):
C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0

image

Následně se již můžeme vrhnout na prvním CmdLet, pro první sample klasicky Hello World, založíme novou třídu a pojmenujeme jí GetHelloWorldMessage:

image

A začneme přidávat atributy a base třídu:

  • importujte namespace System.Management.Automation
  • třída GetHelloWorldMessage musí být zděděna z objektu PSCmdlet
  • přidejte atribut CmdLet k nově vytvořené třídě, první parametr definuje jednu z povolených akcí, respektive prefixů (na funkci samotného CmdLetu nemá vliv, jenom definuje standard) a druhý parametr určující název samotné Powershell funkce, tentokrát bez prefixu již daného výčtovým typem VerbsCommon, výsledek tedy může být:
    [Cmdlet(VerbsCommon.Get, „HelloWorldMessage“)]
    Samotný příkaz tedy bude dostupný jako Get-HelloWorldMessage

Samotnou funkčnost implementujete přetížením metody ProcessRecord(), která je definována v base PSCmdLetu a navíc přidáme jeden vstupní parametr pro specifikaci jména uživatele – tento parametr je označen jako povinný.

image

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Management.Automation;
using System.Text;
using System.Threading.Tasks;

namespace DevIT.PowerShell.Samples
{
    [Cmdlet(VerbsCommon.Get, "HelloWorldMessage")]
    public class GetHelloWorldMessage : PSCmdlet
    {
        [Parameter(Mandatory = true, HelpMessage = "Zadejte Vaše jméno.")]
        public string YourName { get; set; }
        protected override void ProcessRecord()
        {
            WriteVerbose("Spouštíme hrozně složitou akci...");
            WriteObject(string.Format("Vítejte, {0}!", YourName ?? string.Empty));
        }
    }
}

 

Nyní už jenom zkompilujeme, spustíme konzoli PowerShellu, nalistujeme adresář s výsledným DLL souborem a importujeme ho do sady dostupných PowerShell příkazů:

Import-Module .\DevIT.PowerShell.Samples.dll

Následně již můžeme zavolat příkaz Get-HelloWorldMessage:

image

Případně rovnou s parametrem Get-HelloWorldMessage -YourName “Pavel”

Nebo klasicky parametrem –? zobrazit dostupné volby, při prvním volání nápovědy však budete vyzván k přegenerování nápovědy, která se generuje na základě atributů uvedených u CmdLetu i samotných parametrů:

image

Dynamics CRM 2013: vytvoření PDF z reportu a přiložení jako přílohy

Na MSDN webu se objevil postup formou javascriptu, jak automatizovaně vygenerovat přílohu PDF z reportu a uložit jí jako přílohu k nějaké entitě, to se samozřejmě může hodit například při generování objednávky nebo faktury z CRM a automatizovanému uložení výsledného PDF soboru k nově vytvořenému odchozímu mailu, tedy bez nutnosti krkolomného postupu: otevřít report, vygenerovat, uložit na plochu PDF, založit email, připojit přílohu….

[more]

Postup:

http://blogs.msdn.com/b/emeadcrmsupport/archive/2014/06/19/dynamics-crm-2013-custom-code-creating-a-report-as-a-pdf-attachment.aspx

 

Řešení však není všeho spásné, tím, že se jedná o javascript, nelze to automatizovat formou workflow, ale akci musí vyvolat uživatel z formuláře.

 

Já mám připravenou trošku lepší verzi Veselý obličej a to formou workflow aktivity, kterou je možné jednoduše přidat do jakéhokoliv workflow nad jakoukoliv entity, vybrat jaký report se má vygenerovat a kam ho připojit – je tedy možné akce automatizovat kompletně, například generovat automatické opakované faktury a zasílat je zákazníkům mailem ve formě PDF, brzo napíšu na blog příspěvek s ukázkou. Pokud by jste měli zájem, ozvěte se mi na email.

SharePoint: Unable to display this Web Part / System.StackOverflowException: Operation caused a stack overflow

Pokud SharePoint na nějakém webu zobrazuje místo obsahu webparty následující hlášku:

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator

 [more]

a v ULS logu je výjimka:

Error while executing web part: System.StackOverflowException: Operation caused a stack overflow.
at Microsoft.Xslt.NativeMethod.CheckForSufficientStack()
at SyncToNavigator(XPathNavigator , XPathNavigator )
at (XmlQueryRuntime , IList`1 , Double , XPathNavigator )
at (XmlQueryRuntime , XPathNavigator )
at Root(XmlQueryRuntime )
at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer, Boolean closeWriter)
at System.Xml.Xsl.XmlILCommand.Execute(IXPathNavigable contextDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter results)
at System.Xml.Xsl.XslCompiledTransform.Transform(IXPathNavigable input, XsltArgumentList arguments, XmlWriter results)
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.ExecuteTransform(XslCompiledTransform xslCompiledTransform, XsltArgumentList xmlArguments, Boolean bDeferExecuteTransform)
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)

 

Zpracování XSLT trvalo déle než nakonfigurovaná maximální doba, defaultně je pouze 1 sekunda, což na SharePoint s velkým množstvím dat není mnoho Obličej s očima v sloup

PowerShellem je potřebu upravit timeout (počet sekund) maximální délky zpracování XSLT transformací:

$farm = Get-SPFarm
$farm.XsltTransformTimeOut = 5
$farm.Update()

 

a restartovat IIS příkazem IISRESET.EXE

SharePoint–řešení problémů s alerty (emailovou notifikací)

SharePoint má standardně zapnutý limit počtu alertů na jednoho uživatele, tedy kolik si jich maximálně může sám aktivovat – defaultně je toto číslo nastaveno na 500. Počet se sice zdá na jednu stranu rozumný a skoro uživatelsky nemožné, aby si někdo tolik upozornění aktivoval, ale v praxi je u některých agend málo. Příkladem mohou být například interní objednávky, kdy každá interní objednávka má definovaného řešitele pomocí kategorie (kategorii “IT” řeší IT oddělení, správu vozů administrativa, opravy strojů oddělení správy majetku, atd.), to ale znamená, že nechceme notifikovat všechny lidi, kteří mohou objednávky spravovat, tedy řešitele, ale jenom ty, kterých se daná kategorie objednávky týká – k tomu svádí vytvořit programově event receivery po vytvoření objednávky a pro dané uživatele vytvářet programově alerty na změnu položky… Ale tedy u je kámen úrazu, kdy i poměrně malá společnost je schopna vygenerovat více než 500 objednávek na jednoho uživatele, nehledě na to, že limit 500 alertů na uživatele je přes celou webovou aplikaci, kde může být více podobných agend. Vytváření alertů na jednotlivé položky tedy není z dlouhodobého pohledu dobrá cesta, ale pokud už takový nástroj/doplněk máte, nejjednodušší cestou je zvýšení limitu.

 [more]

Zvýšení limitu počtu alertů na uživatele nelze provést v UI, lze pouze příkazovou řádkou:

STSADM.EXE -o setproperty -url http://intranet.devit.cz -pn alerts-maximum -pv 10000

Pokud naopak chcete zjistit aktuálně nastavenou hodnotu, použijte:

STSADM.EXE -o getproperty -url http://intranet.devit.cz -pn alerts-maximum

 

Aktivované alerty jsou uložení v obsahové databázi, pro vypsání všech aktivních “okamžitých” notifikací lze použít SQL dotaz:

select * from [dbo].[ImmedSubscriptions] (nolock)

Případně přímo filtrovat na uživatele dle emailové adresy:

select * from [dbo].[ImmedSubscriptions] (nolock) where UserEmail = ‚novotny@devit.cz‘

SNAGHTMLf208ff

 

Analogicky lze dohledat i aktivní plánované alerty, tedy tzv. souhrnné denní nebo týdenní:

select * from [dbo].[SchedSubscriptions] (nolock)

Dynamics CRM–nová aktualizace přinese podporu SLA v servisním modulu

Pár novinek z připravované aktualizace Dynamics CRM – servisní modul:

  • Podpora SLA (Service Level Agreement) v servisním modulu a definice pravidel a priorit:
    image

[more]

image

  • Pole pro odpočítávání/počítání doby skutečně stráveného času servisního zásahu:
    image
  • Kontrola úrovně supportní smlouvy (zbývajícího počtu servisních hodin)
    image
  • Slučování duplicitních servisních případů:
    image
  • Samozřejmostí jsou statistiky pro sledování stavu ticketů, ale i doby řešení jednotlivých ticketů, doby od založení ticketu do jeho vyřešení, zdroje ticketů (Email, Web, Telefon, Twitter, Facebook)
    image

    image

  • Automatická eskalace pokud se například doba řešení blíží maximální době pro danou prioritu ticketu
    image

 

Video:

Více:

http://blogs.msdn.com/b/crm/archive/2014/06/04/3-ways-to-learn-what-s-new-with-customer-service-in-microsoft-dynamics-crm-spring-14.aspx

SPFastDeploy–rozšíření do Visual Studia pro vývoj SP Online

Do nadpisu jsem původně chtěl vložit ještě trefný suffix “pro prodloužení psychického zdraví vývojáře”, protože tento doplněk ve spoustě případů skutečně šetří nervy při deploy změn a testování – kdo nikdy nevyvíjel nic pro SharePoint, nemůže pochopit Obličej s očima v sloup Zatím ale nemám pořádně vyzkoušeno, zdá se to ale slibné.

Dostupné přímo z VS:

image

 

Lze aktivovat i mód automatického deploye po uložení:

SNAGHTML15366872

 

VS doplněk je dostupný buď přímo ze správy Extensions  Visual Studia nebo ke stažení zde:

http://visualstudiogallery.msdn.microsoft.com/9e03d0f5-f931-4125-a5d1-7c1529554fbd