I'm playing around with SharePoint Server 2013 and configuring Service applications, trying out different installs and, well everything I can think of.

Few days ago I tried configuring synchronization of profile pictures from AD, which of course was working without any issues. But when I tried to run a command:

Update-SPProfilePhotoStore -CreateThumbnailsForImportedPhotos 1 -MySiteHostLocation http://myportal/

I got the following error:

Update-SPProfilePhotoStore : UserProfileApplicationNotAvailableException_Logging :: UserProfileApplicationProxy.ApplicationProperties ProfilePropertyCache does not have a1097ef1-f31e-4145-88c1-ca2fd5c8c836 At line:1 char:1

I was trying to find a solution on the web but could not find one that would have the exact same issue. But then one article pointed me in the right direction.

Background

When I was configuring SharePoint 2013 in my DEV environment, I was preparing install scripts and I wanted to make a least priileged install of my farm. So I also changed Distributed cache account to a dedicated AD account with this script:

$farm = Get-SPFarm

#get windows service account

$windowsServiceAccount=read-host "Enter Windows Service account"

$accnt = Get-SPManagedAccount -Identity $windowsServiceAccount

#change distributed cache service account

$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}

$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"

$cacheService.ProcessIdentity.ManagedAccount = $accnt

$cacheService.ProcessIdentity.Update()

$cacheService.ProcessIdentity.Deploy()

#start service

$distrCacheService=Get-SPServiceInstance |where {$_.TypeName -eq "Distributed Cache "}

if($distrCacheService.status -eq "Disabled")

{

$distrCacheService | Start-SPServiceInstance

}

while(-not($distrCacheService.status -eq "Online"))

{

write-host -ForegroundColor Yellow $distrCacheService.status;sleep 5;

$distrCacheService=Get-SPServiceInstance |where {$_.TypeName -eq "Distributed Cache "}

}

Solution

So because distributed cache is now caching user profile data, it was then obvious, that distributed cache account does not have enough permissions on the User Profile Service Application to perform the PowerShell Command.

After I granted Full Control permission on UPS Service App to my distributed cache account, everything started working without any further issues.

One thing to remember though is, that PowerShell command to create thumbnail photo, should be run after every user profile import. You can use Windows Task manager to achieve this task.

Hope it helps J

Robi Vončina

SharePoint Server MVP

6. Datoteka z definicijo storitve

Datoteka z definicijo storitve (končnica CSDEF) je datoteka v formatu XML z opisi različnih vlog, ki sestavljajo vašo aplikacijo. Celotno shemo za datoteko XML lahko poiščete na naslovu http://msdn.microsoft.com/en-us/library/windowsazure/ee758711.aspx. Datoteka CSDEF za vsako vlogo, ki jo želite v svoji aplikaciji, vključuje elementa WebRole in WorkerRole. Če določeno vlogo nastavite kot spletno vlogo (z uporabo elementa WebRole), to pomeni, da se bo koda izvajala na virtualnem strežniku, ki vključuje operacijski sistem Windows Server 2008 in strežnik Internet Information Server (IIS). Če določeno vlogo vpeljete kot delovno vlogo (z uporabo elementa WorkerRole), to pomeni, da se bo koda izvajala na virtualnem strežniku, ki vključuje le operacijski sistem Windows Server 2008 (strežnik IIS ne bo nameščen).

Seveda lahko še vedno ustvarite in namestite delovno vlogo, ki za pričakovanje in obdelavo spletnih zahtev uporablja drug mehanizem (na primer, v aplikaciji lahko uporabite razred .NET HttpListener). Ker vsi virtualni strežniki vključujejo operacijski sistem Windows Server 2008, lahko vaša programska koda izvaja vse operacije, ki so običajno na voljo aplikaciji, nameščeni v tem operacijskem sistemu.

Za vsako vlogo določite želeno velikost virtualnega strežnika. Spodnja tabela prikazuje različne velikosti in lastnosti virtualnih strežnikov, ki so vam na voljo:

Tabela 2: Različne velikosti in lastnosti virtualnih strežnikov

Storitev se obračunava na uro za vsak uporabljeni virtualni strežnik v določeni vlogi. Prav tako vam obračunamo vse podatke, ki so poslani izven podatkovnega centra. Podatkov, ki so poslani v podatkovni center, ne obračunavamo. Več informacij poiščite na spletni strani Cene storitev Windows Azure. Na splošno strankam priporočamo, da namesto manj večjih strežnikov uporabijo večje število manjših virtualnih strežnikov, saj so tako vaše aplikacije bolj odporne na morebitne okvare. Manj virtualnih strežnikov uporabljate, hujše so posledice izpada enega izmed njih. Poleg tega morate za vsako vlogo uporabiti vsaj dva virtualna strežnika, če želite uveljavljati dogovor o ravni storitev, ki zagotavlja 99,95-odstotno zanesljivost.

V datoteki z definicijo storitve (CSDEF) določite tudi številne lastnosti vsake posamezne vloge v vaši aplikaciji. Sledi nekaj bolj koristnih možnosti, ki so vam na voljo:

• Certifikati. S certifikati šifrirate podatke, če vaša spletna storitev podpira povezave SSL. Vse certifikate morate naložiti na platformo Windows Azure. Več informacij poiščite na spletni strani Upravljanje certifikatov na platformi Windows Azure. Ta nastavitev XML naložene certifikate namesti v knjižnico certifikatov določenega virtualnega strežnika, kar vaši aplikaciji omogoča, da jih uporablja.
• Imena konfiguracijskih nastavitev. Tu nastavite vrednosti, za katere želite, da jih vaše aplikacije preberejo, ko se izvajajo na določenem virtualnem strežniku. Dejanska vrednost konfiguracijske nastavitve se določi v datoteki za konfiguracijo storitve (CSCFG), ki jo lahko kadarkoli spremenite, ne da bi morali ponovno namestiti kodo vaše aplikacije. Svoje aplikacije lahko razvijete tako, da nove konfiguracijske vrednosti zaznajo brez prekinitve v delovanju sistema.
• Vhodne končne točke. Tu določite končne točke HTTP, HTTPS ali TCP (z oznakami vrat), ki jih želite prikazati zunanjemu svetu prek naslova predpona.cloudapp.net. Ko platforma Windows Azure zažene vašo vlogo, bo samodejno nastavila požarno pregrado na virtualnem strežniku.
• Interne končne točke. Tu določite končne točke HTTP ali TCP, ki jih želite izpostaviti drugim virtualnim strežnikov, ki so bili vpeljani kot del vaše aplikacije. Interne končne točke vsem virtualnim strežnikom z različnimi vlogami v vaši aplikacij dovoljujejo, da komunicirajo med seboj, ob tem pa niso dostopni drugim virtualnim strežnikom, ki se ne nahajajo v vaši aplikaciji.
• Uvoz modulov. Te možnosti lahko vašim virtualnim strežnikom dodajo koristne gradnike. Na voljo so gradniki za spremljanje delovanja, oddaljeno namizje in Windows Azure Connect, ki vašemu virtualnemu strežniku omogoča, da prek varne komunikacijske povezave dostopa do virov, nameščenih na lokaciji.
• Lokalno shranjevanje podatkov. Tu virtualnemu strežniku določite podmapo, ki jo bo uporabljala vaša aplikacija. Možnost je podrobno opisana v članku Možnosti shranjevanja podatkov v okolju Windows Azure.
• Opravila ob zagonu. S temi opravili lahko ob zagonu virtualnega strežnika namestite zahtevane gradnike. Če je potrebno, se lahko opravila izvajajo v vlogi administratorja

7. Datoteka za konfiguracijo storitve

Datoteka za konfiguracijo storitev (CSCFG) je datoteka XML z opisi nastavitev, ki jih lahko spremenite, ne da bi morali ponovno namestiti svojo aplikacijo. Celotno shemo za datoteko XML lahko poiščete na naslovu http://msdn.microsoft.com/en-us/library/windowsazure/ee758710.aspx. Datoteka CSCFG vsebuje element Role za vsako vlogo v vaši aplikaciji. Sledi opis nekaterih elementov, ki jih lahko določite v datoteki CSCFG:

• Različica operacijskega sistema. S tem atributom lahko izberete različico operacijskega sistema, ki jo želite uporabiti za vse virtualne strežnike, na katerih se izvaja vaša aplikacija. Ta operacijski sistem se imenuje gostujoči operacijski sistem, vsaka nova različica pa vključuje najnovejše varnostne posodobitve, ki so bile na voljo ob predstavitvi gostujočega sistema. Če atribut osVersion nastavite na »*«, bo Windows Azure samodejno posodobil gostujoči operacijski sistem na vseh virtualnih strežnikih, ko bo na voljo nova različica gostujočega sistema. Lahko pa izberete določeno različico gostujočega operacijskega sistema in se tako odpoveste nadgradnjam. Na primer, če atribut osVersion nastavite na vrednost »WA-GUEST-OS-2.8_201109-01«, bo na vseh virtualnih strežnikih nameščena različica, opisana na tej spletni strani: http://msdn.microsoft.com/en-us/library/hh560567.aspx. Več informacij o različicah gostujočega operacijskega sistema poiščite na spletni strani Upravljanje nadgradenj gostujočih operacijskih sistemov na platformi Windows Azure.
• Virtualni strežniki. Z vrednostjo tega elementa nastavite število virtualnih strežnikov, za katere želite da izvajajo določeno vlogo. Ker lahko v okolje Windows Azure naložite novo datoteko CSCFG (ne da bi morali ponovno namestiti aplikacijo), je zelo preprosto spremeniti vrednost tega elementa in tako dinamično povečati ali zmanjšati število virtualnih strežnikov z določeno vlogo, na katerih deluje vaša aplikacija. Tako lahko preprosto povečate ali zmanjšate zmogljivost aplikacije glede na dejanske delovne obremenitve, obenem pa lahko nadzorujete tudi stroške.
• Vrednosti konfiguracijskih nastavitev. Ta element označuje vrednosti nastavitev (določenih v datoteki CSDEF). Vaša vloga lahko te vrednosti bere med delovanjem. Te vrednosti konfiguracijskih nastavitev se običajno uporabljajo za povezave s sistemi SQL Azure ali Windows Azure Storage, vendar jih lahko uporabite v katerikoli namen..

8. Ustvarjanje in vpeljava gostovane storitve

Ko ustvarjate gostovano storitev, morate najprej obiskati upravljavski portal Windows Azure Management Portal in omogočiti gostovano storitev tako, da nastavite predpono DNS in podatkovni center, v katerega želite vpeljati svojo aplikacijo. Nato v razvojnem okolju ustvarite datoteko z definicijo storitve (CSDEF), napišete kodo svoje aplikacije in vse datoteke stisnete (z orodjem zip) v storitveni paket (CSPKG). Prav tako morate pripraviti datoteko za konfiguracijo storitve. Za namestitev vloge z uporabo aplikacijskega vmesnika Windows Azure Service Management naložite datoteke CSPKG in CSCFG. Po namestitvi bo Windows Azure omogočil virtualne strežnike v podatkovnem centru (na podlagi konfiguracijskih podatkov), razširil kodo aplikacije iz paketa in jo kopiral na virtualne strežnike ter jih zagnal. Sedaj je vaša koda nameščena in deluje.

Spodnja slika prikazuje datoteki CSPKG in CSCFG, ki ju ustvarite na lokalnem računalniku za razvoj. Datoteka CSPKG vključuje datoteko CSDEF in programsko kodo za dve vlogi. Po tem, ko z aplikacijskim vmesnikom Windows Azure Service Management naložite datoteki CSPKG in CSCFG, bo Windows Azure v podatkovnem centru ustvaril virtualne strežnike z različnimi vlogami. V tem primeru datoteka CSCFG zahteva, da Windows Azure ustvari tri virtualne strežnike v vlogi št. 1 in dva virtualna strežnika v vlogi št. 2.

Slika 5: Datoteki CSPKG in CSCFG, ki ju ustvarite na lokalnem računalniku za razvoj

9. LITERATURA

[1] Msdn.microsoft.com, MSDN Portal, obiskano 20.5.2012.

[2] www.windowsazure.com, Azure Portal, obiskano 20.5.2012.

3. Kaj morate upoštevati pri načrtovanju gostovane storitve

Pri razvoju aplikacije, ki bo delovala v oblaku, morate upoštevati več dejavnikov, kot so zakasnitve, visoka razpoložljivost in razširljivost.

Pri vpeljavi gostovane storitve v okolje Windows Azure je pomembno vprašanje, katero lokacijo boste izbrali za namestitev svoje aplikacije. Običajno aplikacije namestite v podatkovne centre, ki so najbližje vašim strankam, s čimer zmanjšate zakasnitve in zagotovite najvišjo možno zmogljivost. Lahko se odločite tudi za podatkovni center, ki je bližje vašemu podjetju ali vašim podatkom, če vas skrbijo vprašanja pristojnosti in pravne zahteve glede shranjevanja podatkov. Po vsem svetu imate na voljo šest podatkovnih centrov, v katerih lahko gostujejo vaše aplikacije. V spodnji tabeli so prikazane lokacije, ki so vam na voljo:

Tabela 1: Lokacija strežnikov Windows Azure

Ko nameščate gostovano storitev, izberite podregijo, ki ustreza lokaciji, na kateri želite izvajati svojo kodo.

Za zagotavljanje visoke razpoložljivosti in razširljivosti je ključnega pomena, da so podatki vaše aplikacije shranjeni na osrednji lokaciji, ki je dostopna virtualnim strežnikom z različnimi vlogami. V ta namen Windows Azure zagotavlja več možnosti za shranjevanje podatkov, kot so binarni objekti, tabele in SQL Azure. Za več informacij o teh tehnologijah za shranjevanje podatkov preberite članek Možnosti shranjevanja podatkov na platformi Windows Azure. Na spodnji sliki je prikazano, kako sistem za upravljanje delovnih obremenitev v podatkovnem centru Windows Azure posreduje zahteve odjemalcev na virtualne strežnike z različnimi vlogami, pri čemer vsi strežniki uporabljajo podatke z iste lokacije za shranjevanje.

Slika 4: Primer posredovanja zahtev odjemalcev na različne strežnike z različnimi vlogami pri čemer vsi strežniki uporabljajo podatke z iste lokacije za shranjevanje

Običajno aplikacijo in podatke vpeljete v isti podatkovni center, saj tako zagotovite manjše zakasnitve (hitrejše delovanje), ko aplikacija dostopa do podatkov. Poleg tega vam pri prenosu podatkov znotraj istega podatkovnega centra ni treba plačevati za porabljeno pasovno širino.

4. Kako razviti razširljive aplikacije

Včasih morda želite razviti eno samo aplikacijo (na primer, preprosto spletno stran) in z njo gostovati na platformi Windows Azure. Toda pogosto vašo aplikacijo sestavlja več vlog, ki se med seboj povezujejo. Na spodnji sliki je prikazan primer aplikacije, ki jo sestavljata dva virtualna strežnika v vlogi spletne strani, trije virtualni strežniki za obdelavo naročil in en virtualni strežnik v vlogi za pripravo poročil. Te vloge so med seboj povezane in programsko kodo za vse vloge je mogoče združiti in na platformo Windows Azure vpeljati kot eno samo enoto.

Slika 4: Primer aplikacije, ki jo sestavljata dva virtualna strežnika v vlogi spletne strani, trije virtualni strežniki za obdelavo naročil in en virtualni strežnik v vlogi za pripravo poročil

Glavni razlog za razdelitev aplikacije v različne vloge, ki se izvajajo na različnih virtualnih strežnikih, je možnost medsebojno neodvisne razširljivosti vlog. Na primer, med novoletnimi prazniki številne stranke pri vašem podjetju kupujejo darila, zaradi česar morda želite povečati število virtualnih strežnikov, na katerih gostujeta vlogi Spletna stran in Obdelava naročil. Ko se prazniki končajo, se poveča število vrnjenih izdelkov, zaradi česar potrebujete več virtualnih strežnikov s spletno stranjo in manj virtualnih strežnikov za obdelavo naročil. Med letom morda potrebujete le nekaj virtualnih strežnikov za spletno stran in obdelavo naročil. Obenem ves ta čas potrebujete le en virtualni strežnik v vlogi za pripravo poročil. Windows Azure nudi prilagodljivo vpeljavo aplikacij na podlagi vlog, kar vam omogoča, da aplikacijo preprosto prilagajate svojim poslovnim potrebam.

Običajno virtualni strežniki v različnih vlogah, ki sestavljajo vašo gostovano storitev, komunicirajo med seboj. Na primer, vloga spletne strani sprejme kupčevo naročilo, vendar obdelavo naročila prepusti virtualnim strežnikom za obdelavo naročil. Najboljši način za prenos delovnih obremenitev z enega nabora virtualnih strežnikov v eni vlogi na virtualne strežnike v drugi vlogi je uporaba tehnologije čakalne vrste, ki jo zagotavlja Windows Azure. Uporabite lahko storitev čakalne vrste Queue Service ali čakalne vrste storitvenega vodila Service Bus Queue. Uporaba čakalne vrste je ključen del naše zgodbe saj gostovani storitvi omogoča neodvisno povečevanje ali zmanjševanje zmogljivosti virtualnih strežnikov za posamezne vloge, kar pomeni, da lahko stroškovno učinkovito uskladite delovne obremenitve. Če se število sporočil v čakalni vrsti povečuje, lahko povečate število virtualnih strežnikov, ki izvajajo vlogo obdelave naročil. Če se število sporočil v čakalni vrsti zmanjša, lahko zmanjšate število virtualnih strežnikov, ki izvajajo vlogo obdelave naročil. Tako boste plačevali le za tiste virtualne strežnike, ki jih potrebujete za dejanske delovne obremenitve.

Čakalna vrsta prav tako zagotavlja zanesljivost storitve. Ko zmanjšate število virtualnih strežnikov za obdelavo naročil, platforma Windows Azure sama odloči, kateri virtualni strežniki bodo odstranjeni. Pri tem se lahko odloči, da odstrani strežnik, ki ravno obdeluje sporočilo v čakalni vrsti. Toda ker obdelava sporočila ni bila uspešno zaključena, sporočilo ponovno postane vidno drugemu virtualnemu strežniku za obdelavo naročil, ki ga prevzame in obdela. Zaradi vidnosti sporočil v čakalni vrsti ste lahko prepričani, da bodo sporočila sčasoma obdelana. Čakalna vrsta prav tako deluje kot sistem za razporejanje delovnih obremenitev, saj sporočila pošilja vsem virtualnim strežnikom, ki jih zahtevajo.

Tudi za virtualne strežnike v vlogi spletne strani lahko spremljate dohodni promet in se odločite, ali boste število virtualnih strežnikov povečali ali zmanjšali. Čakalna vrsta vam omogoča, da število virtualnih strežnikov, ki izvajajo vlogo spletne strani, povečate neodvisno od števila strežnikov za obdelavo naročil. S tem pri upravljanju storitve pridobite izjemno prilagodljivost. Če vašo aplikacijo sestavlja še več vlog, lahko vključite dodatne čakalne vrste za komunikacijo med njimi, pri čemer lahko prav tako izkoristite prednosti na področjih razširljivosti in stroškov.

5. Definicija in nastavitve gostovane storitve

Ob vpeljavi gostovane storitve v okolje Windows Azure morate pripraviti datoteki z definicijo in konfiguracijo storitve. Obe datoteki sta v formatu XML in vam omogočata, da z deklarativnimi ukazi določite možnosti za vpeljavo vaše gostovane storitve. Datoteka z definicijo storitve opisuje vse vloge, ki sestavljajo vašo gostovano storitev, in načine, kako komunicirajo med seboj. Datoteka za konfiguracijo storitve opisuje število virtualnih strežnikov za vsako vlogo posebej in nastavitve posameznih virtualnih strežnikov.

1. Prednosti aplikacijskega modela platforme Windows Azure

Ko aplikacijo namestite kot gostovano storitev, platforma Windows Azure ustvari enega ali več virtualnih strežnikov (VM), na katerih je nameščena koda vaše aplikacije. Nato platforma virtualne strežnike zažene na fizičnih strežnikih, ki se nahajajo v podatkovnih centrih Windows Azure. Ko zahteve odjemalcev, ki dostopajo do vaše gostovane aplikacije, dosežejo podatkovni center, sistem za upravljanje delovnih obremenitev enakomerno porazdeli zahteve na posamezne virtualne strežnike. Aplikacije, ki gostuje na platformi Windows Azure, vam zagotavljajo tri glavne prednosti:

• Visoka razpoložljivost. Visoka razpoložljivost pomeni, da platforma Windows Azure zagotavlja, da vaša aplikacija čim dlje deluje neprekinjeno in se lahko odziva na zahteve odjemalcev. Če pride do izpada aplikacije (na primer, zaradi neobravnavane izjeme), bo platforma Windows Azure to zaznala in samodejno ponovno zagnala vašo aplikacijo. Če pride na napravi, na kateri deluje vaša aplikacija, do okvare strojne opreme, platforma Windows Azure to zazna in samodejno ustvari nov virtualni strežnik na delujoči fizični napravi. Programska koda se nato izvaja na novem fizičnem strežniku. OPOMBA: če želite izkoristiti 99,5-odstotno raven razpoložljivosti, določeno v Microsoftovem dogovoru o ravni storitev, se morajo aplikacije izvajati na vsaj dveh virtualnih strežnikih. Tako lahko en virtualni strežnik obdeluje zahteve odjemalcev, medtem ko platforma Windows Azure vašo kodo z nedelujočega virtualnega strežnika premakne na delujočega.

• Razširljivost. Windows Azure vam omogoča preprosto in dinamično prilagajanje števila virtualnih strežnikov, na katerih se izvaja vaša aplikacija. Na ta način zagotavlja, da lahko vaša aplikacija uspešno obdela dejanske delovne obremenitve. Aplikacijo lahko tako prilagodite delovnim obremenitvam, obenem pa plačujete le za virtualne strežnike, ki jih potrebujete in ko jih potrebujete. Ko želite spremeniti število virtualnih strežnikov, se Windows Azure odzove v le nekaj minutah, s čimer vam omogoča dinamično prilagajanje števila virtualnih strežnikov tako pogosto kot želite.

• Preprosto upravljanje. Windows Azure je platforma, zagotovljena kot storitev. To pomeni, da upravlja infrastrukturo (strojno opremo, električno napajanje in omrežne povezave), potrebno za delovanje naprav. Windows Azure upravlja tudi platformo, kar pomeni, da vedno uporabljate popolnoma posodobljen operacijski sistem s pravimi popravki in varnostnimi posodobitvami ter nameščenimi posodobitvami posameznih gradnikov, kot sta ogrodje .NET Framework in strežnik Internet Information Server. Ker vsi virtualni strežniki zagotavljajo okolje Windows Server 2008, Windows Azure omogoča tudi dodatne možnosti, kot so spremljanje delovanja, podporo za oddaljena namizja, požarne pregrade in nastavitve shranjevanja certifikatov. Vse te dodatne možnosti so na voljo brezplačno. Ko aplikacije namestite na platformi Windows Azure, je v ceno vključena tudi licenca za operacijski sistem Windows Server 2008. Vsi virtualni strežniki zagotavljajo sistem Windows Server 2008, kar pomeni, da vsa koda, razvita za operacijski sistem Windows Server 2008, brez težav deluje tudi na platformi Windows Azure.

2. Ključni koncepti gostovanih storitev

Ko svojo aplikacijo kot gostovano storitev namestite na platformi Windows Azure, deluje v eni ali več vlogah. Vloga se nanaša na aplikacijske datoteke in konfiguracijo. Za svojo aplikacijo lahko določite eno ali več vlog, pri čemer ima vsaka vloga svoj nabor aplikacijskih datotek in konfiguracij. Za vsako vlogo v vaši aplikaciji lahko določite število virtualnih strežnikov v določeni vlogi (role instance), na katerih bo aplikacija delovala. Spodnja slika prikazuje dva preprosta primera aplikacije, ki je zasnovana kot gostovana storitev in uporablja vloge in virtualne strežnike za posamezne vloge.

Slika 1: Ena vloga s tremi virtualnimi strežniki, ki deluje v podatkovnem centru Windows Azure

Slika 2: Dve vlogi, od katerih vsaka deluje na dveh virtualnih strežniki v podatkovnem centru Windows Azure

Virtualni strežniki običajno obdelujejo zahtevke odjemalcev, ki prek interneta v podatkovni center vstopijo preko t.i. vhodne končne točke (input endpoint). Ena vloga ima lahko 0 ali več vhodnih končnih točk. Vsaka končna točka označuje protokol (HTTP, HTTPS ali TCP) in vrata. Običajno se vloga nastavi tako, da uporablja dve vhodni končni točki: pričakovanje prometa HTTP na vratih 80 in pričakovanje prometa HTTPS na vratih 443. Spodnja slika prikazuje primer dveh različnih vlog z dvema različnima vhodnima končnima točkama, ki preusmerjajo zahtevke odjemalcev na ustrezne vloge.

Slika 3: Primer dveh različnih vlog z dvema različnima vhodnima končnima točkama, ki preusmerjajo zahtevke odjemalcev na ustrezne vloge.

Ko v okolju Windows Azure ustvarite gostovano storitev, je storitvi dodeljen javen naslov IP, prek katerega lahko odjemalci dostopajo do storitve. Ko ustvarite gostovano storitev, morate izbrati tudi predpono naslova URL, ki bo povezan s tem naslovom IP. Predpona mora biti enolična, saj z njo pravzaprav rezervirate naslov URL predpona.cloudapp.net, ki ga ne more uporabljati nihče drug. Odjemalci z vašimi virtualnimi namreč komunicirajo prek naslova URL. Običajno ne boste pošiljali ali objavili naslova URL predpona.cloudapp.net. Namesto tega pri svojem ponudniku registracije domen kupite ime DNS, ki ga nato nastavite tako, da zahteve odjemalcev preusmerja na naslov URL storitve Windows Azure.

Microsoft je skupaj s partnerjem Hortonworks naredil velik korak k izboljšanju Big Data funkcionalnosti na Windows strežnikih ter v svojem oblaku Windows Azure.

V predogledu je testna različica HDInsight strežnika. Lokalna različica je na voljo za prenos in namestitev na lastni infrastrukturi, oblačna pa zahteva on-line registracijo s katero dobite povabilo, ki vam omogoča zastonjsko pet dnevno preizkušanje. Obe pa sta na voljo na Microsoftovem Big Data portalu.

V ozadju HDInsight strežnika se nahaja Hadoop, ki je s strani Apache Software Foundationa sponzorirana odprtokodna implementacija Googlovega pristopa k hranjenju in obdelovanju masovne količine podatkov. Pristop MapReduce omogoča ‘scale-out’ procesiranja kupov strukturiranih in nestrukturiranih podatkov čez številčne gruče strežnikov.

Velika podjetja, kot na primer Yahoo, so že dolgo uporabljala Hadoop za obdelavo podatkov o uporabniških klikih in s tem pridobila svojevrsten marketinški vpogled v svoje storitve. Microsoftov partner, Hortonworks, prodaja odprtokodne Hadoop rešitve in je bil ustanovljen s strani računalniških inženirjev iz Yahoojeve Hadoop ekipe. Tako Microsoft, kot Hortonworks, prispevata vso kodo razvito za potrebe HDInsight strežnika nazaj v odprtokodno skupnost.

HDInsight strežnik je zastavljen tako, da omogoča organizacijam, ki uporabljajo Microsoftova BI (business intelligence) orodja, enostaven vplogled v masovne Hadoop podatke. Ta orodja vključujejo PowerPivot za Excell in PowerView za Sharepoint storitve, ki lahko prikažejo rezultate Hadoop poizvedb.

Prav tako je na voljo obojestranski konektor, ki za potrebe analize strukturiranih podatkov omogoča uporabnikom premike podatkov med Hadoopovim datotečnim sistemom in Microsoft SQL Server 2012 strežnikom ter SQL Server 2012 Parallel Data Warehouse podatkovnim skladiščem. Tudi tehnologija StremInsight se lahko uporabi za obdelovanje pretočnih (streaming) podatkov, kot na primer procesiranje kompleksnih dogodkov.

Microsoft je sodeloval pri integraciji upravljanja s svojim System Center produktom. Tako je mogoča uporaba Apache Ambari [i]v kombinaciji z System Centrom za upravljanje Hadoop gruč skupaj z ostalimi viri računalniškega okolja. Varnost je na Windows strežnikih nadgrajena z integracijo z Active Direktorijem.

HDInsight trenutno vsebujen tako ‘stabilno’ različico Hadoop datotečnega sistema (HDFS) in MapReduce sistema za distribuirano procesiranje, kot ostale dele Hadoop ekosistema (Hive, Pig in Sqoop).

Razvijalci pa smo dobili .NET SDK, ki nam omogoča pisanje MapReduce opravil s pomočjo Visual Studia. Na voljo je tudi možnost uporabe JavaScripta, tako za pisanje MapReduce opravil, kot Pig in Hive poizvedb. Uporaba JavaScripta v primerjavi z Javo zmanjša število vrstic kode za 10 krat.

[i] Ambari je spletno orodje za namestitev upravljanje in nadzorovanje Apache Hadoop gruč

Following E. Struyf 's Blog for making a picture gallery from the assets library:

• Making an Image Gallery Inside the Asset Library: Part 1 - E. Struyf 's Blog
• http://www.estruyf.be/blog/making-an-image-gallery-inside-the-asset-library-part-1

I thought that it has to be a way to get pictures from picture gallery with the Content Query Web Part and modify the results so that it can work for the galleria.

So, the first step of course would be to download all the necessary files. To download files go to the galleria we page and extract the zip file. You can copy all files to the Style library, where I made the JS folder to save the jQuery library file, downloaded from the www.jQuery.com web site.

Galleria files

Download Galleria

http://galleria.io/download/

Screen shot of the Style library\JS folder.

For the galleria to work, you will need:

• Jquery library
• Galleria.classic.css
• Galleria.classic.min.js
• Galleria-1.2.7.min.js
• Classic-loader.gif
• Classic-map.png.

XSL files

Next thing to do is to modify the ContentQueryMain.xsl and ItemStyle.xsl. In ContentQueryMain you need to modify the div in which pictures will be displayed. In order to do that just add the class gallery to the div id=''{concat('cbqwp',$ClientId)}''. You will specify the branding later on for the .gallery class.

ContentQueryMain.xsl

In ItemStyle.xsl you need to add a new xsl:template, which will be used for rendering pictures in CQWP. Important part here is to change the variable SafeLinkUrl. So to get the full picture not just the picture thumbnail you need to select the LinkUrl column for the UrlColumnName.

ItemStyle.xsl

<xsl:template name="ImageGallery" match="Row[@Style='ImageGallery']" mode="itemstyle">

    <xsl:variable name="SafeLinkUrl">

        <xsl:call-template name="OuterTemplate.GetSafeLink">

         <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>

        </xsl:call-template>

    </xsl:variable>

    <img src="{@LinkUrl}"/>

</xsl:template>

Gallery page

Next thing to do is to create and modify the web part page where the gallery will be shown. Edit the file in advanced mode in SharePoint Designer 2010 and just after the PlaceHolderMain opening tag add the following code (modify reference to your script files if needed):

<link type="text/css" rel="stylesheet" href="../../Style Library/js/galleria.classic.css"/>

<script type="text/javascript" src="../../Style Library/js/jquery-1.7.2.min.js"></script>

<script type="text/javascript" src="../../Style Library/js/galleria.classic.min.js"></script>

<script type="text/javascript" src="../../Style Library/js/galleria-1.2.7.min.js"></script>

<script type="text/javascript">

$(document).ready(function(){

    $(".gallery img").unwrap().unwrap();

    $('.gallery').galleria({

    width: 700,

    height: 467 });

    Galleria.loadTheme('../../Style Library/js/galleria.classic.min.js');

    Galleria.run('.gallery');

});

</script>

This code will add reference to the files in Style library, JavaScript, CSS,… $(".gallery img").unwrap().unwrap(); unwraps the pictures form the <li> tag and <ul> tag which CQWP adds when it displays the pictures and needs to be done so that galleria can step in action and create the actual gallery.

Galleria.loadTheme and Galleria.run just runs the galleria to create the picture gallery.

At the end of the page, just after the </asp:content> add the style tag, which will apply background, height and width to the gallery div of the Content Query Web Part. This was set in ContentQueryMain.xsl

<style type="text/css">

    .gallery{

    width:700px;

    height: 472px;

    background: #000;

    margin:auto;

    text-align:center;

    }

</style>

Content Query web part

On the page add the CQWP and Edit Web part. For the picture source select the picture gallery where your pictures are saved.

You can also specify filter for the pictures.

What is important in the CQWP settings is that you apply the ItemStyle you previously created in ItemStyle.xsl called ImageGallery.

Save the CQWP settings, save the page and refresh it.

And the final result is:

Robert Vončina

Kompas Xnet d.o.o.

robi@kompas-xnet.si

Windows Azure je v Sloveniji komercialno na voljo od 7.6. To je precej dobra novice za vse nove uporabnike, predstavlja pa zanimiv problem za vse tiste, ki so te oblačne storitve, preko raznih proksi podjetij iz drugih držav, uporabljali že prej. Smiselno bi bilo vse obstoječe rešitve prestaviti na slovenske uporabniške račune ter tako dobiti popolno kontrolo nad njimi in se pri tem še izogniti dodatnim posredniškim stroškom.

Prenos Windows Azure storitev med naročninami je s pomočjo Microsoftove podpore možen, se pa je pri tem treba držati nekaterih pravil in poskrbeti, da je okolje za prenos pripravljeno.

Za začetek postopka moramo seveda imeti ustvarjen nov uporabniški račun na katerega bi radi prenesli obstoječe storitve. Ta mora biti za uspešen prenos popolnoma prazen, kar posledično pomeni, da ne bo mogoče prenesti vsebine storitev iz več računov na enega.

Prvi korak, ki ga moramo opraviti, je migracija SQL Azure podatkovnih baz. To lahko naredimo, če smo lastniki obeh uporabniških računov ali administratorji oz. co-administratorji na obeh računih. Na staremu upravljalen portalu (silverlight) izberemo virtualni SQL Azure strežnik, pritisnemo na gumb 'Move Server...' ter izberemo ciljni

uporabniški račun.

Nekaj trenutkov za tem se bodo SQL Azure baze pojavile na novem računu, pri vsem tem pa baze s podatki ostanejo dosegljive pod enakimi pogoji kot prej.

Nato preverimo (prav tako najbolje v starem portalu), če se na ciljnem računu res ne nahaja popolnoma nič, razen seveda prenešenih SQL Azure baz. Nobena zadeva ni dovoljena, ker bo že nek neuporabljen 'affiniti group' povzročil prekinitev prenosa.

Preden stopimo v kontakt z Microsoftovo podporo moramo še poskrbeti, da bo administrativen email na obeh računih enak, kar naredimo tako da na spletnem mestu izberemo https://account.windowsazure.com 'account', nato naročnino in 'Edit subscription detail' ter spremenimo e-mail administratorja storitev.

Postopek ponovimo še za drugi račun in smo pripravljeni na stik z Microsoftovo podporo za uporabnike. Na https://www.windowsazure.com/en-us/support/contact/ izberemo 'Windows Azure', temo 'Other' in opcijo pomoči preko spletne forme, kjer navedemo guid identifikatorja obeh računov ter vse ACS/Service bus/Caching imenske prostore, ki jih naše storitve uporabljajo.

V kratkem nato pričakujte telefonski klic, v katerem se boste z Microsoftovim pogovorili o postopku vaše migracije ter razrešili morebitne nejasnosti. Ta pa se bo začel takoj, ko boste po e-mailu potrdili zapisnik tega telefonskega pogovora.

Kot lahko vidimo, prenos storitev brez izpada njihovega delovanja ni nemogoč, zahteva pa nekaj dela in planiranja z naše strani. Če na kratko povzamemo celoten postopek, ki ga moramo opraviti na naši strani: Sql Azure baze selimo preko portala ročno, administratorski e-mail mora biti pri obeh računih enak, ciljni račun mora biti popolnoma prazen (razen SQL Azure) ter izvorni račun je po prenosu avtomatsko izklopljen.

Na voljo je novi 1.8 SDK, ki ga lahko dobite na http://www.windowsazure.com/en-us/downloads/.

Node.js je zadnji izmed dolge vrste programskih jezikov, APIjev, toolkitov, ki se trudijo biti zadosti 'cool', da bi jih uporabljali. V tem smislu nadaljuje tradicijo Railsov, AJAXa, Hadoopa ter do neke mere tudi HTML5 hypea. Praktično je nemogoče najti kakršnokoli spletno orientirano konferenco brez vsaj kakšnega predavanja na to temo, ki bo večkrat kot ne, popolnoma zmedlo poslušalce.

Glede na to, da je tudi mene doletela ta čast, da bom na prihajajoči NT konferenci govoril o prav tej zadevi je smiselno, da se ji malce posvetimo tudi v Piki. Node.js, oziroma včasih zgolj Node, je strežniška rešitev za JavaScript oz. še bolj specifično, za prejemanje in odgovarjanje na HTTP zahtevke. Seveda se takoj pojavi vprašanje: Zakaj naj bi JavaScript poganjal karkoli izven brskalnika? Še posebej pa kar Strežnik ?!?

Prva zadeva, ki jo moramo vedeti je, da Node sicer poganja JavaScript, ni pa tudi sam JavaScript. Sestavlja ga Googlov V8 JavaScript pogon, libUV ter vrsta vključenih knjižnic in je namenjen pisanju skalabilnih internetnih aplikacij. Hitro lahko pomislimo, da JavaScript ni najbolj primeren za upravljanje z viri na sistemskem nivoju in imeli bomo prav. A glede na to, da sam Node ni JavaScript temveč C program kateremu JavaScript zgolj pošilja navodila za upravljanje s črno magijo APIja vašega operacijskega sistema. Dejstvo je, da je JavaScript današnjim spletnim programerjem precej bližje kot C, kar samo po sebi vpliva na resen pogled na Node, saj jim omogoča napisati strežnik, ne da bi jim bilo potrebo poznati C, oziroma kakšen drug jezik. Kot pri ostalih jezikih, bo tudi tu primeren ogled 'živjo svet' primera:

var http = require('http');

http.createServer(function (req, res) {

res.writeHead(200, {'Content-Type': 'text/plain'});

res.end('Živjo svet\n');

}).listen(1337, "127.0.0.1");

console.log(Strežnik teče na http://127.0.0.1:1337/');

S klicem 'require' naložimo zahtevan modul (ki jih pri node.js ne manjka in skupnost sproti dodaja nove), v našem primeru http modul v spremenljivko, iz katere smo naredili spletni strežnik. Pri tem smo strežniku podali funkcionalnosti, ki na vsak zahtevek zgolj nastavijo HTTP header ter vrnejo statično besedilo in nastavili specifičen port ter IP naslov, na katerem naj strežnik posluša.

Kako bomo poservirali več zahtevkov hkrati? Zelo enostavno, napisati nam ni treba prav nič dodatnega. Lepota Node.js je, da lahko s precej enostavnim in vsakdanjim JavaScriptov pridemo do teh rezultatov.

Klici funkcij v node.js so načeloma vedno asinhroni in določijo še 'callback' fukncijo, ki se bo izvedla ko bo klic končan, tako klicajoči niti ni treba čakati na rezultate temveč lahko vmes obdeluje druge zahtevke.

V klasičnem spletnem scenariju je komunikacija med spletnim strežnikom ter podatkovno bazo časovno najbolj zahteven del operacije. Node bo na vašem sistemu pustil manjši 'footprint' kot klasičen spleti strežnik in zaradi svoje asinhrone narave ne bo uporabljal virov med čakanjem na rezultat neke akcije. Tako na primer med klicem na podatkovno bazo, ki traja recimo 30 ms, ne čaka z alociranimi viri, temveč jih vmes uporabi za obdelovanje drugih zadev.

Poanta Node-a je tako, da je izjemno hiter, enostavno skalira in zaradi uporabe JavaScripta tudi precej enostaven za uporabo.

Ni pa srebrni metek, ki bi bil primeren za uporabo v vsakem scenariju. Med tem, ko se odlično obnese pri:

- dogodkovno orientiranih sletnih aplikacijah ki skalirajo čez več odjemalčevih povezavah

- na JSONu temelječih HTTP APIjih

- podatkovnih aplikacijah, ki uporabljajo isto kodo na strežniku in odjemalcu

se zaradi svoje 'interpreted' narave obnese nekoliko slabše pri zahtevnejših CPU operacijah.

Prav tako bi se dalo zagovarjati, da aplikacija, ki poleg svoje funkcionalnosti v sebi vsebuje tudi spletni strežnik podre 'razdeljevanje odgovornosti' in s tem prispeva k kompleksnosti njenega vzdrževanja. Na račun JavaScripta pa.... se najverjetneje ne najde mnogo ljudi, ki bi spodnjem delu kode pripisali simpatičnost:

if (typeof my_var !== "undefined" && my_var !== null) {

// neki, neki

}

Tako je Node.js zanimiva zadeva, vredna ogleda, a če ste sedaj veliko investirali v Microsoftove tehnologije, najbrž ne ponuja bistvene prednosti pred uporabo Async Controllerjev, MVC4 Web APIja ter SingalRja.

Client of ours wanted to have a new functionality in search results so that users could send documents they find in search as attachments.

So I began digging into xsl which search result core uses to display search result and come up with the following solution.

1. To get to the xsl for search core web part you first need to enter something as a search query.
2. Then on the search result page open Site Actions and then click Edit page

   

3. In the Search Core results web part properties in the Display Properties clear the »Use Location Visualization« check box and then click on XSL Editor

   

4. Click on XSL Editor and copy all of the contents to your favorite text editor like Notepad++ to view the contents more clearly

   

Xsl:Param

First thing you need to do is add additional parameter in the beginning of Search core XSL

Xsl:template

You need to create a new xsl template which has the same name as you xsl:param. I gave it a name »SendAsAttachment«.

In this xsl template, I added a javascript function which creates new ActiveXObject. Link which makes a call to this function is only called for documents. That is why there are xsl:if statements which are checking the »site« string length and the size of the document. If both are greater than 0, a link is added.

Xsl:call-template

The final thing you need to do in Search core result xsl is to call your xsl:template. You need to do that in the "<div class="srch-Metadata2">" in the "<p class="srch-Metadata1">". I put my xsl:call template code just below the ViewInBrowser xsl template.

Now that you modified all the necessary you need to copy all of the text back to the XSL Editor in the search core result web part properties.

Save the web part, save the page and the enter a search query. When you get back the results you should see the newly generated link beside your documents in the search results. If you click on the link, nothing will probably happen. This is because by default unsigned Active X scripts are disabled in the browser. If you want to be able to create new email with document as attachment, open Internet Options in your browser and go to Security Tab. Click Custom and then find "Initialize and script ActiveX controls not marked as safe…"

If you choose prompt than you get a pop-up window:

Just click Yes and new email with attachment and subject set as document title will be created.

Hope this will be helpful to you as well.

modified DefaultSearch Core.xml (25.83 kb)