Ik ben op een project waar we moeten verzamelen statistieken rond een functie met de naam 'deel via een verhaal." Het idee is heel eenvoudig — Als u op zoek bent op een interessant artikel op het intranet en wilt delen met iemand, Klik op een link 'deel dit verhaal" e-mail naar uw contactpersoon.

We speelden rond met een aangepast formulier voor dit doel, maar in het einde, gezond verstand won de dag en we gewoon gebruik maken van de bekende <een href = mailto:…> techniek. (<een href mailto:…> is een verrassend robuust beetje voor HTML; Als een bonus, die link brengt me terug naar mijn oude UNIX man pagina's dagen; dat waren de dagen!).

Deze techniek biedt een geweldige interface voor eindgebruikers aangezien zij krijgen hun bekende MS Outlook-client gebruiken (of welke e-mailclient die ze hebben geïnstalleerd).

Het maakt het wat moeilijker op ons arme ontwikkelaar types sinds ze client * ook * wil lopen in de toekomst een verslag waarin wordt weergegeven hoe vaak gebruikers delen verhalen en zelfs welke verhalen zijn meestal gedeeld.

We whiteboarded een paar mogelijke oplossingen. Mijn favoriet is om carbon copy; kopie (CC) een SharePoint-lijst. Op die manier, de eindgebruiker krijgt nog steeds de outlook-client, terwijl we krijgen de gebeurtenis vastleggen omdat we een kopie van de e-mail zelf krijgen. Er zijn enkele voor de hand liggende nadelen. Het belangrijkste probleem is dat de gebruiker kan gewoon leeg uit of anderszins Mangel de CC adres. En, We moeten dat gebeurtenisbibliotheek van e-mails beheren. We hebben een geplande taak op het witte bord verantwoordelijk voor dat opruimen.

Hebt u sommige slimme aanpak voor het oplossen van dit probleem, Gelieve te vertellen.

</einde>

Abonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

Als gevraagde en beloofde, Ik heb mijn presentatie op het verkrijgen van "grote geupload" eisen van eind-gebruikers voor SharePoint projecten en implementaties. Het is hier: http://Cid-1cc1edb3daa9b8aa.SkyDrive.live.com/Self.aspx/SharePoint/Paul Galvin Great Requirements.zip

Ik presenteerde dit op de Best Practices SharePoint-conferentie in februari 2009 (www.sharepointbestpractices.com). Als u de conferentie bijgewoond, u krijgt dit ook op de conferentie DVD.

De presentatie bevat een heleboel notities met de meeste dia 's. Het is niet gewoon bullet punten.

(Zie hier voor mijn andere presentatie op een bestuur case study: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</einde>

Abonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

Zoals vele SharePoint consultant types, Ik heb blootgesteld aan een heleboel SharePoint-functionaliteit. Sommige tijden, Ik duik vrij diep. Andere tijden die ik merk het net zoals ik door naar een andere set van menu-opties vliegen ben. Een daarvan is "zelf sites maken." Ik heb niet had een noodzaak van het tot deze week.

Deze week, Ik nodig om op te lossen een bedrijfsprobleem waarvan ik denk gaat steeds vaker dat als bedrijven opwaarts losraken en meer directe controle van eindgebruiker over SharePoint omarmen. In dit geval, Ik heb een sitesjabloon ter ondersteuning van een specifieke eindgebruiker Gemeenschap ontworpen. Mensen in deze Gemeenschap moeten zitten kundig voor hun eigen sites op wil met deze sjabloon wanneer de drang hen slaat maken.

Ik herinnerde het zien van "zelf sites maken" vóór en ik heb altijd weggestopt die in de achterkant van mijn hoofd denken dat "self service sites maken" is de SharePoint lingo betekenis, duidelijk genoeg, iets als "turn me on als u wilt dat gebruikers kunnen sites maken wanneer ze willen."

Dus, Ik zet hem op, Probeer het uit en voor mij, het niet het creëren van websites. Het het creëren van site Collecties. Vrij groot verschil. Dat is niet wat ik willen, Helemaal niet.

Het is mogelijk om te laten van eind-de gebruikers nieuwe sub-sites via een aangepaste machtigingsniveau maken. Dit is precies waar ik zou zijn gegaan in de eerste plaats dien verstande dat het label "zelf sites maken" Label bedrogen me. Via twitter, I learn that it’s deceived others as well 🙂

Ik ben nog steeds bezig uit hoe een klein beetje van een meer gestroomlijnd proces tijdens uw verblijf puur uit de doos, maar er is een duidelijk pad te volgen. Gewoon niet krijgen afgeleid door dat label.

</einde>

Abonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

Ik was een van 20 of 30 (of misschien 100?) panelleden gisteravond op de New York SharePoint gebruikers groep vergadering. In plaats van de gebruikelijke presentation-indeling, Dit was alles over Q&A tussen het publiek en de panelleden. Tijdig, Michael Lotter geïntroduceerde wil een nieuw idee en ik wilde om te delen.

Een publiekslid beschreven hoe zijn bedrijf een adviseur van een toepassing schrijven voor zijn bedrijf had betaald. De consultant schreef het als een consoletoepassing die de SharePoint-objectmodel gebruiken. Als een resultaat, Dit betekende dat het programma moest worden uitgevoerd op een server in de farm. Dit betekende dat iedereen die wilde de app gebruiken voor aanmelding bij de server zou hebben, het werk doen en afmelden. Op het eerste, Dit was geen probleem, maar al snel, meer en meer (niet-technische) gebruikers nodig om het nut te gebruiken. Zijn vraag was (parafrase):

"Wat zijn mijn opties? Ik wil niet te houden verhuur gebruikers log direct op de server, maar ze moeten die functionaliteit."

Michael Lotter suggereerde dat hij een nieuwe virtuele machine configureren, toevoegen aan de farm als een WFE en laat gebruikers de toepassing uitvoeren vanaf daar.

Dit is een vrij prachtig idee voor mij. Deze oplossing generaliseren doet denken aan de notie van in wezen tijdelijke, bijna wegwerp WFE. Ik denk dat het is een mooie nette concept. Deze tijdelijke WFE kunt uitvoeren een consoletoepassing die de SharePoint-objectmodel gebruikt. U kon het ook gebruiken voor het uitvoeren opdrachten stsadm. Het hoeft niet als onderdeel van regelmatige lokale balancing. Als het daalt of krijgt vergaan, u kunt alleen een nieuwe draaien. Ik herhaal mezelf, maar ik moet zeggen dat ik denk dat het is een werkelijk mooi idee.

</einde>

Abonneren op mijn blog.

Volg mij op Twitter op http://www.twitter.com/pagalvin

Deze afgelopen week, iemand een vraag gesteld over het maken van een SharePoint-omgeving die zou omgaan met een vrij hoog volume van nieuwe documenten (10,000 +/- in dit geval). Ik weet niet veel over dit, maar Dankzij dit Witboek, Ik voel me veel beter op de hoogte.

Voor mij, Dit Witboek is vrij veel net een boek mark op dit moment, maar ik ben begonnen met lezen door middel van het en dacht dat ik noem mijn belangrijkste RestaurantgidsTake-away. SharePoint kan worden aangepast om, op een minimum, deze belasting:

• 50k nieuwe documenten per dag.
• 10 miljoen documenten totale.

Ik schrijf de 50k / 10MM cijfers omdat ze gemakkelijk genoeg om te onthouden. Zo lang als je weet dat ze zijn minima, u zult niet in de problemen. De maxima zijn ten minste 10 procent hoger dan dat en met extreme tuning, eventueel een stuk hoger.

Bedankt, Mike Walsh, nogmaals voor zijn wekelijkse WSS FAQ updates en correcties post. Als u niet bent geabonneerd op het, u moet serieus denkt over het doen van het.

</einde>

Abonneren op mijn blog.

Tijdens de afgelopen week, mijn collega en ik waren gedoe sommige werkzaamheden voor een cliënt in NYC. We waren het testen van een verschillende aspecten van een MOS-implementatie met behulp van hun "standaard" werkstation bouwen (in tegenstelling tot onze laptops). Terwijl het doen van die, We liepen in een paar fouten door de volgende stappen:

• Open te stellen een MS word-document via windows verkenner (die maakt gebruik van WebDAV).
• Breng een wijziging.
• Opslaan.

We kwamen om te beseffen dat sommige tijden (gewoonlijk de eerste keer) het document is opgeslagen, het opslaan stok niet"." Opslaan is niet opgeslagen. Wij zou trekken dat document back-up en onze wijzigingen gewoon er niet waren.

We begrijpen niet de wortel probleem op dit moment, maar we dachten dat wij ervoor moeten zorgen dat de meest recente MS Office servicepack had geïnstalleerd op dat werkstation. De IT-mensen ging en deed dat. We gingen door de test opnieuw en ontdekten we een nieuw probleem. Wanneer we het gered, We hebben nu deze fout:

Deze keer, het leek alsof elke wijziging was, Eigenlijk, opgeslagen, of we antwoordde ja of Nee op de vraag van scripts.

Hadden we eindelijk een blik op de actuele versie van Office en het blijkt dat het werkstation liep MS Office 2000 met servicepack 3 welke verschijnt onder Help-> Over als "Office 2002".

De moraal van het verhaal: Ik zal altijd gebruik maken van Office 2003 Als mijn minimumnorm office-versie bij het gebruik van WebDAV en MOSS.

</einde>

Abonneren op mijn blog.

(Voor zoektocht motor doeleinden, Dit is de fout tekst):

Lijn: 11807

Char: 2

Fout: Object ondersteunt niet deze eigenschap of methode

Code; 0

URL: http://sharepoint01/DocumentReview/_vti_bin/owssvr.dll?location=Documents/1210/testworddocument.doc&dialogview=SaveForm

Wilt u doorgaan met het uitvoeren van scripts op deze pagina?

In één of mijn zeer eerste blogberichten, Beschreef ik het algehele proces dat we gevolgd om te migreren van een klant van SPS 2003 aan MOSS. Een lezer verliet een commentaar vragend voor meer detail en hier is het.

Voor dat migratieproject, moesten we vinden een goede manier om te bewegen een heleboel SPS 2003 documenten over MOSS. Het initiële laden was eenvoudig genoeg. Een nieuwe doelgroep-documentbibliotheek maken in MOSS en gebruik windows verkenner om de documenten verplaatsen.

Dit is de nieuwe documentbibliotheek:

Open te stellen twee vensters ontdekkingsreizigers. Het eerste punt op SPS 2003 en de tweede op de nieuwe documentbibliotheek in MOSS. Het volgende screenshot geeft dit. Merk op dat de top browser is eigenlijk wijzend op mijn c:\TEMP-station, maar je kunt je voorstellen het verwijst naar een SPS 2003 documentbibliotheek:

Na die slepen en neerzetten van bewerking, mijn doel ziet er als volgt:

Nu is het tijd om te gaan met de metagegevens. Neem aan dat we slechts één kolom van metadata voor deze documenten met de naam "locatie." We kunnen zien van de bovenstaande "alle documenten" mening dat de locatie leeg is. Het is gemakkelijk genoeg om een bladweergave gegevens kunt opgeven van de locatie, of gaan zelfs in de eigenschappen van elk document één voor één toe te voegen van een locatie. Laten we aannemen dat er is geen praktische manier de kolom locatie een waarde automatisch toewijzen en dat eindgebruikers met de hand moet doen. Bovendien, laten we aannemen dat er zijn honderden van documenten (misschien duizenden) en dat het duurt vele vele dagen te werken de metagegevens. Zoals we weten allemaal, niemand gaat zitten en werken voor vier van de vijf dagen rechte bijwerken van metagegevens voor documenten. In plaats daarvan, zij zal breken dat uit over een periode van weken of misschien langer. Om dit proces te vergemakkelijken, We kunnen een "niet-gecodeerde gegevens maken" weergave zoals:

Nu, Wanneer iemand te zit besteden hun toegewezen dagelijkse uur of twee om tag gemigreerde documenten, zij kunnen gebruik maken van de "niet-gecodeerde documenten" u zich wilt concentreren hun inspanningen:

Als gebruikers tag documenten, ze vallen uit deze lijst.

Deze notie van een niet-gecodeerde gegevensweergave kan ook helpen met een klasse van gegevensvalidatie probleem mensen over op de forums informeren. Out of the box, Er is geen manier om te voorkomen dat een gebruiker een document uploaden naar MOSS en meta-gegevens vervolgens niet invoeren. We kunnen opgeven dat een bepaalde sitekolom verplicht is en de gebruiker zal niet worden toegestaan om te duwen de Opslaan knop. Echter, Als de gebruiker uploadt en vervolgens de browser sluit (of gebruik windows verkenner om te uploaden van het document), We kunnen niet dwingen de gebruiker meta-gegevens in te voeren (weer, out of the box).

Deze benadering kan worden gebruikt om te helpen met die situatie. We kunnen een "slecht gecodeerde gegevens gebruiken" weergeven om gemakkelijk deze documenten identificeren en corrigeren. Koppel dit met een KPI en je hebt goed zicht op de gegevens met DrillDown voor het beheer van deze uitzonderlijke omstandigheden.

</einde>

Abonneren op mijn blog.

Deze week, Ik heb een beetje moeite met mijn team te krijgen MOSS geïnstalleerd in een eenvoudige twee-server-farm. Zijn gegaand door het, Ik heb een grotere waardering voor de soorten problemen mensen rapport over de MSDN forums en elders.

De definitieve farmconfiguratie:

• SQL/Index/Intranet WFE binnen de firewall.
• WFE in de DMZ.
• Een soort van firewall tussen de DMZ en de interne server.

Voordat we begonnen met het project, We laten de client weten welke poorten die nodig zijn om open. Tijdens het geven en nemen, heen en weer over die, we nooit uitdrukkelijk gezegd twee belangrijke dingen:

1. SSL betekent dat u een certificaat nodig.
2. De DMZ-server moet deel uitmaken van een domein.

Dag één, we opdagen om te installeren MOSS en geleerd dat de domeinaccounts voor database en MOSS niet had gemaakt. Om dingen te bewegen langs, wij doorgingen en alles geïnstalleerd met een lokale account op de intranetserver.

Op dit punt, We ontdekten de verwarring over het SSL-certificaat en, Helaas, besloten om onze infrastructuur-vent later die week terugkomen op doorgaan met de installatie van de DMZ-server. In de tussentijd, We oplossing architecten verplaatst vooruit met de zakelijke dingen.

Een weekend gaat door en de client het certificaat verkrijgt.

Onze infrastructuur vent uiterlijk vertoon opwaarts en ontdekt dat de DMZ-server niet is opgenomen in een domein (een omtrek-domein met beperkte vertrouwen of het intranet domein). We verloren bijna een 1/2 dag op dat. Als we niet had laten de ontbrekende SSL certificaat ons moeras, We zouden hebben ontdekt dit eerder. Ach….

Dag loopt en de diverse parlementaire commissies van de veiligheid, belanghebbende partijen en (niet zo) onschuldige omstanders alle ermee eens dat het OK om toe te treden de DMZ-server met het intranet-domein (Dit is een POC, Eindelijk, niet een productie-oplossing).

Infrastructuur man komt in dingen om omhoog te verpakken. Deze keer we met succes doorheen de de modern-dag handschoen liefkozend de "Wizard SharePoint configureren." We hebben een kijkje in Centraal beheer en … Yee haw! … DMZ server wordt in de farm weergegeven. We een beetje dichterbij kijken en beseffen dat we brak open de Champaign een beetje mijt vroeg. WSS diensten zit vast in een "starten" status.

Lang verhaal kort, het blijkt dat we vergeten te wijzigen van de identiteit van de service-account via Centraal beheer van de oorspronkelijke lokale account naar het nieuwe domeinaccount. We hebben dat gedaan, opnieuw liep de configuratiewizard en voila! We waren in het bedrijfsleven.

</einde>

Abonneren op mijn blog.

Hoewel het niet letterlijk waar is, Als een praktische kwestie, een internet-gerichte Webfront-end in een DMZ moet zich in een domein bevinden (dwz. niet een zelfstandige server in zijn eigen kleine werkgroep). Het behoeft niet te worden in hetzelfde domein als de interne WFE(s) en andere servers (en waarschijnlijk niet), maar het moet worden van een domein.

Mijn collega's en ik bracht een buitensporige hoeveelheid tijd over een voorstel dat vereisten van SharePoint opgenomen. Dit omvatte een uitvoerige lijst van firewall-configuraties waardoor de DMZ-server aan de farm enzovoort. Helaas, We verzuimde te scoren een zin ergens gezegd, om het effect, "de hele bloedige punt van deze configuratie is dat uw server DMZ WFE, in een domein, voor deelname aan de interne farm."

Een perfecte storm van gebeurtenissen, waar we in feite keek links wanneer we misschien hebben gekeken naar rechts, samengespannen om te verbergen dit probleem van ons pas vrij laat in het proces, waardoor me beroep te doen op mijn "slecht nieuws vertellen vroeg" regel.

Zucht.

Abonneren op mijn blog.

Forumgebruikers vaak als vragen als deze:

> Hallo,
>
> Vertel me als er zijn mogelijkheden om te bouwen van een aangepaste lijst met
> hoofd- en detailpagina type (Als facturen) zonder het gebruik van InfoPath.
>

SharePoint biedt een aantal uit het vak functies die soorten zakelijke vereisten als dat ondersteunen.

In het algemeen, een verbindt twee lijsten samen met behulp van een opzoekkolom. Lijst A bevat de factuur header-informatie en lijst B Factuurdetails.

Aanvullende lijsten te handhaven klantnummers gebruiken, productnummers, etc.

Een webonderdeel Inhoudsquery gebruiken (in MOSS alleen) en/of een gegevensweergave webonderdeel om samengevoegde weergaven van de lijsten te maken. SQL Server Reporting Services (SRS) is ook beschikbaar voor de rapportage kant van het.

Echter, Er zijn enkele belangrijke beperkingen die het gebruik van pure out-of-the-box functies voor iets dat is zelfs matig complexe moeilijk zal maken. Deze omvatten:

• Grootte van verwante lookup lijsten vs. "intelligentie" van het type van de kolom opzoeken. Een type van de kolom opzoeken presenteert zich op de UI anders afhankelijk van of u meerdere selecteren hebt ingeschakeld of niet. In beide gevallen, de out-of-the-box controle toont alle beschikbare items vanuit de bronlijst. Als de bronlijst 1,000 items, dat gaat een probleem. De lookup-besturingselement doet niet pagina door deze items. In plaats daarvan, het trekt ze allemaal in het besturingselement. Dat maakt voor een zeer lastige user interface zowel in termen van gegevensinvoer en prestaties.
• Zoekacties "pull terug" een kolom met gegevens. U kunt nooit meer dan één kolom met gegevens uit de bronlijst terugtrekken. Bijvoorbeeld, u kunt een klant "12345 niet selecteren" en het aantal, alsmede de naam en adres van de klant weer te geven op hetzelfde moment. De zoekopdracht alleen blijkt de klant nummer en niets anders. Dit zorgt voor een lastig en moeilijk user interface.
• Geen communicatie intra-formulier. Ik heb geschreven over dit hier. U kan niet implementeren cascading drop-downs, voorwaardelijk inschakelen/uitschakelen velden, etc.
• Geen trapsgewijze verwijderingen of ingebouwde referentiële integriteit. SharePoint behandelt aangepaste lijsten als onafhankelijke entiteiten en staat niet toe dat u hen aan elkaar te koppelen in een traditionele ERD zin. Bijvoorbeeld, SharePoint kunt u twee aangepaste lijsten maken, "klant" en "factuurkop". U kunt een factuurkop die links terug naar een klant in het Klantenoverzicht. Vervolgens, u kunt de klant uit de lijst verwijderen. Out of the box, Er is geen manier om dit te voorkomen. Om op te lossen van dit soort problemen, normaal zou u gebeurtenis-handlers gebruiken.

Het lijkt misschien somber, maar ik zou nog steeds SharePoint gebruiken als een beginpunt voor het bouwen van dit soort functionaliteit. Hoewel er verschillen zijn tussen wat je nodig hebt in een oplossing, SharePoint laat ons die met behulp van tools zoals leemten aan te vullen:

• Gebeurtenis-handlers. Ze gebruiken om referentiële integriteit afdwingen.
• Aangepaste kolommen: Aangepaste kolomtypen maken en ze te gebruiken in plaats van de standaard opzoekkolom. Toevoegen van wisselbestand, bufferen en AJAX functies waarmee ze responsieve.
• BDC. Deze functie alleen-MOSS stelt ons in staat om query die andere SharePoint-met een superieure gebruikersinterface aan de gebruikelijke opzoekkolom lijsten. BDC kan ook bereiken om een back-end server-toepassing. Gebruik de BDC om te voorkomen dat replicatie. In plaats van klantgegevens repliceren vanaf een back-end ERP-systeem, BDC gebruiken. BDC-functies bieden een aardig gebruikersinterface te trekken die informatie rechtstreeks vanuit het ERP systeem waar het behoort en vermijdt het gedoe van de handhaving van een replicatieoplossing.

  BDC is een functie van MOSS (niet beschikbaar in WSS) en het is uitdagend om te configureren.

• ASP.NET webformulier: Een full-featured AJAX-enabled formulier maken dat de SharePoint object model en/of web services wordt gebruikt om de invloed van SharePoint-lijsten en biedt een zeer responsieve gebruikersinterface.

De laatste optie kan het gevoel dat je van kras begint, maar rekening met het feit dat het SharePoint-platform u met de volgende kenmerken begint:

• Beveiligingsmodel met onderhoud.
• Menusysteem met onderhoud.
• "Master tabel" (dwz. aangepaste lijsten) met beveiliging, ingebouwde onderhoud en controle van jaarrekeningen.
• Zoek.
• Back-end integratie tools (BDC).

Als u in visual studio met een nieuw, leeg project starten, je hebt een heleboel infrastructuur en sanitair te bouwen voordat u krijgen dicht bij wat SharePoint biedt.

Ik geloof dat Microsoft van plan is om uit te breiden van SharePoint in deze richting van applicatie-ontwikkeling. Het schijnt als een natuurlijke uitbreiding van de bestaande SharePoint base. De Microsoft CRM-toepassing biedt een grote hoeveelheid uitbreidbaarheid van de typen ter ondersteuning van kop-/ detailsectie toepassingsontwikkeling. Hoewel deze functies in CRM zijn, de technologie is uiteraard beschikbaar voor de SharePoint-ontwikkelteam en ik verwacht dat het zijn weg naar het SharePoint-product eind maken zal 2008. Als iemand een kennis of inzicht in dit heeft, laat alstublieft een reactie.

</einde>