Общ преглед

Този запис описва един казус, който описва действителната MRO (Поддръжка, Ремонт и операции) работния поток одобрение процес в MOSS.

Това не е откровено техническа дискусия, но вместо това служи да осигури действителен свят пример, който показва как платформата на Мос срещна реални трябва.

(Този запис е кръстосано публикувани между http://paulgalvin.spaces.live.com и http://blogs.conchango.com)

Фон

На клиента MRO процес са се характеризират със следното

• Ръчно одобрение процес.
• Някои поддръжка using Превъзхождам spreadsheets.
• Нередовни одобрение процес. Процесът на одобрение на същото MRO закупуване ще варират ден за ден, лице от лице.
• Много хартия и саморъчните подписи — закупуване на заявки изисква до 3 писмени подписи преди окончателното одобрение.

Целите на проекта бяха осъществени:

• Напълно автоматизира процеса на.
• Прилагат корпоративни стандарти за одобрение.
• Предоставя обобщен изглед на MRO закупуване на различни мениджъри.
• Подробна одитна пътека.

Като страничен ефект на разтвора, писмени подписи вече не са необходими.

Процес на одобрение

Процесът на одобрение се състои от четири "плува платна": Предприятията за оригинални, Пряк ръководител, Функционални мениджър и разделението мениджър.

Предприятията за оригинални:

Климушка определителен член нужда за покупка и започва процеса. Обърнете внимание, че наредителят може или не може действително да влезе заявка за покупка, но вместо това пряко друг служител да го направят. Някои пъти, Авторът не разполага с техническа експертиза за попълване на PO заявки. За пример, Потребителят може да искате да заявка нов преносим компютър, но не знае най-добър доставчик, IT стандарти, н. В този случай, Авторът работи с нея и тя действително се попълва заявка.

Пряк ръководител:

Това е пряк ръководител на автора (които могат да бъдат различни от лицето, което действително са били пуснати на PO заявки в Мос). Преките ръководители трябва да одобри на PO заявки, преди системата да потърси одобрение допълнително установяване на ред.

Функционални мениджър:

Диспечерът на функционални е лицето, отговорно за гарантиране, че предложената покупка отговаря предприятието стандарти в обхвата на определена корпоративна функция. За пример, ИТ покупки са одобрени от ИТ функционални мениджър.

Разделението мениджър:

Мениждърите одобри покупка искания строго с долар сума. Дивизия мениджър одобри покупка искания повече конфигурируеми долар сума.

Решението

Ние използвахме следните инструменти и компоненти за изпълнение на решението:

МОС: Служи като платформа, от която всичко останало "увисва". Мос предоставя здрава основа услуги за сигурност, главни данни, одит и други функции.

Услуги за формулярите на InfoPath: Мос компонент, Това дава възможност на потребителите да попълват покупка искания чрез уеб браузър.

SharePoint Designer (SPD): Ние използвахме SPD да приложат процеса на автоматизиран работен процес.

Уеб услуга: C# уеб услуга подобрява работата на потребителите като даде възможност на каскадни селекции списъци в InfoPath форма и осигурява по-добра производителност спрямо филтриране на данни. Вижте Тук за технически дълбоко гмуркане по този въпрос и причини за използването му.

Потребителски списъци: Мос потребителски профили предоставя пряк ръководител на даден потребител, но не предостави повечето от данните, които контролират работния поток решения (e.g. дали дивизионен мениджър се изисква да одобри на PO заявки). Използвахме потребителски списъци в "корпоративни данни" сайт за поддържане на данните като "Дивизионен мениджър одобрение сума за долар", "Функционална област мениджър" и така нататък. Списъци интегрирани много добре с InfoPath и също така предоставя създаване/актуализиране/изтриване (CRUD) функционалност за одит и сигурност на кутията.

Случай употреба

Този употреба случай илюстрира как решението се вписва заедно:

1. Paul иска нов лаптоп. Той описва нуждите му да Vivek, човек запознат с корпоративен лаптоп стандарти, Предпочитани доставчици, н.
2. Вивек трупи в Мос, достъп до формуляра PO заявки и навлиза заявки от името на Paul. Формата подканва Вивек за покупка категория, които след това използва уеб услуги да се пренесат капка-голо възвишение списък на фирмата одобрени доставчици. Вивек също задава корпоративни функционалните областта на тази покупка (e.g. "IT" или "Финанси").
3. ЕДП базирани поток започва, определя на Paul в пряк ръководител и изпраща заявка към неговия мениджър, Стейси.
4. Стейси одобрява заявка за покупка.
5. ЕДП поток инспектира заявки и определя това е ИТ покупка. Той разпраща работния поток до функционални диспечера на ИТ, Wonson.
6. Wonson одобрява заявки.
7. ЕДП поток отново инспектира заявки и определя че сумата на покупката, надвишава maxium долар и го насочва към разделението мениджър за одобрение.
8. Разделението мениджър одобри заявка за покупка.

Бележки

• Използването случай показва "чиста" тичам без откази или скокове.
• Всеки одобряващ има възможност да одобри или отхвърли заявки, както и да представят писмени коментари. Те са влезли в одит.
• Ако един отговорен мениджър отхвърли искане за покупка във всеки един момент, PO заявки е "мъртъв" и процесът трябва да се стартира от началото.
• Работният поток ще уведоми наредителя на всяка стъпка от процеса на.
• Няма писмени подписи — Клиентът определя (след някои силно въздействащи препоръки) че Одитът пътека както чрез хронологията на работния поток, служи на нуждите им одит.
• Усилие — Отне около три мъж седмици, за да приложи това решение.

Заключение

Този разтвор лостове Мос като развитие и Пусни време платформа. Клиентът е в състояние да се наберат основните Мос функции за автоматизиране на рутинни бизнес процес, който засяга почти всеки служител в компанията. С изключение на прости уеб услуга (която от своя страна лостове Мос), почти никакви действителни "програмиране" е необходима.

Решението също така служи като "витрина" за клиента, демонстрира как различните Мос функции могат да бъдат комбинирани за създаване на напълно функционален бизнес приложение и да генерират нови възможности за консултации в бъдеще.

Речник

МАРС РИКОНИСЪНС ОРБИТЪР: Поддръжка, ремонт и операции. Тези покупки обикновено включват елементи като бележник, столове, персонални компютри, принтери, клетъчни телефони и други подобни.

Това може да е очевидно за мнозина, но докато учи за моята Мос програмиране изпит, Аз научих, че това е доста лесно да получите действителната XML от заявката за търсене чрез потребителски интерфейс.

Един бърз метод е както следва:

• Достъп до Разширено търсене.
• Извършване на търсене, който връща някои данни.
• Редактиране на страницата (чрез настройките на сайта).
• Промяна на XSL на следните:

<?XML версия="1.0" кодиране="UTF-8"?>
<XSL:стилове версия="1.0" xmlns:XSL="HTTP://www.w3.org/ 1999/XSL/трансформация">
<XSL:изход метод="XML" версия="1.0" кодиране="UTF-8" тире="Да"/>
<XSL:шаблон мач="/">
<предварително>
<XSL:копие на Изберете="*"/>
</предварително>
</XSL:шаблон>
</XSL:стилове>

• Удар прилагам.
• Преглед на изходния код в браузъра.

Забележете, че <предварително> Етикет не помага много, освен служи като удобен маркер когато разглеждате резултатите.

Тозихитрост могат да бъдат много полезни при работа с контролирани свойства и персонализиране Търсене. Тя ще предостави окончателен списък на XML можете да използвате във вашата xslt, който би бил много полезен последните 25 пъти съм създал някои персонализирано търсене резултати.

Това би трябвало да работят за dataviews както и, Въпреки, че аз не са изследвани това все още.

Виждам, че Ерик Краус е изправена пред изискване обикновено се срещна с уеб компонент на заявка за съдържание. Проблемът? Той е бил в чиста среда WSS без достъп до CQWP. Вместо да кърлинг нагоре в позицията на плода (желание трябва да се бори всеки ден, изглежда), Той излезе с решение, че най-малко дава WSS Магазини борба шанс за успех. Той е описан Тук.

Стефан Goßner е събрал страхотен 4-част серия на SharePoint съдържание и разполагане на API Тук. Той предлага голям обзор и много добри примери в код (C#).

Първи път вдигна тази връзка от Йорис poelmans блог на http://jopx.blogspot.com/.

Дори и ако сте като мен, в които не сте имали да се направи много практическа работа за управление на съдържанието, Това е добре си струва 20 минути от времето си да прочетете.

Използване на API, може да се:

• Експортиране и импортиране на съдържание много лесно.
• Повторна родителска съдържание. Ако искате да експортирате някои съдържание от сайта "А" и да го изпратите на сайта "Б" но в една напълно нова място в йерархията на, Това е възможно.
• Експортиране на съдържание от сайта А и импортирате избрани бита в сайт А.
• Повторно свързване на съдържание (което означава, се справят с всички хипервръзки).

Някой на Internets питаше как да създадете изчисляема колона в списък, който показва една стойност, форматиран като"[Потребител] – [Статус] – [Местоположение]" както и в "Пол Галвин – Пиене [безплатно] Бира – Плаж".

Paul ще ида и да актуализирате си записа в списъка и изчисляемата колона ще актуализира по подходящ начин. На [Потребител] трябва да бъде по подразбиране потребителя въвеждане/актуализиране на списъка.

Изчисляема колона не може да използва "летливи" функции, като например [Мен] или [Днес]. Аз го решават в средата на тестване с тези стъпки:

1. Създаване на текст колона, наречена "Текущ потребител".
2. Задайте стойността й по подразбиране [Мен]
3. Създаване на изчисляема колона, наречена "Calc тест".
4. Задайте си стойност = [Текущ потребител]

Отидох, Добавяне на елемент към списъка и тя работи.

Аз съм поразен от това за 9 месеца и аз виждам, че хората по форумите на MSDN и Usenet са го too.l

Понякога, при достъп до документ на word (или други видове док) от документ библиотека причинява Internet Explorer да просто катастрофа и отивам далеч (като всички раздели с него, ако всички са отворени).

Този MS корекция може да го реши: http://support.microsoft.com/kb/938888

Също, има някои описание за проблема тук:

http://jopx.blogspot.com/2007/07/solving-internet-explorer-crash-when.html

Общ преглед:

Създава потребителски списък, който управлява тип съдържание с дузина колони.

Го добавите към страница а след това чрез SPD, превръща в изглед на данни.

Проблем:

Моят израз на Xpath се връщаше празен за една колона, наречена "Позиция". Аз го посочена thusly:

    <граница на таблица = "1">
      <XSL:за всеки избор = "/ dsQueryResponse/редове/ред" >
        <TR>
          <TD>
            Текущо състояние:
            <XSL:select="@Current_x0020_Status стойност на"></XSL:стойността на>
          </TD>
        </TR>
      </XSL>
    </таблица>

Колоната в КТ е наречена "Текущо състояние". Тя се показва в справката като "Текущо състояние". Навсякъде търсите, виждате "Текущо състояние".

Докато побой лудо около, Търсене на решение, Вместо това посочени "@Recruiter" и Ето! — Това всъщност се върна обратно на текущото състояние. Очаквах го да се върне обратно в работодател, когато направих това.

Разтвор:

Аз мушкам в ЕПД. Отидете на тази страница в ЕПД и показва изгледа на данните. Можете да проверите действителните данни за изгледа и свързаните с тях Xpath. Тук разбрах, че наистина, Xpath посочи "Работодател". Достатъчно странно, "действителна" работодател поле посочи от "Recruiter1".

Изнасям:

ЕПД предвижда авторитетен Xpath изрази за редове & колоните в изглед на данни.

Секунда, Тя показва действителните данни. Така например, е колона от типа показва това:

<NOBR><еталониране><HREF="/sites/Corporate/HumanResources/TalentAcquisition/_layouts/userdisp.aspx?ID = 17">Галвин, Пол</А><IMG границата ="0" височина = 1" ширина = "3" SRC="/_layouts/images/blank.gif"/><a href = "javascript:’ onclick ='IMNImageOnClick();връщане фалшиви;’ клас = "ms-imnlink"><име на IMG ='imnmark’ Заглавие =” границата =’0′ височина ='12’ ширина ='12’ SRC='/_layouts/images/blank.GIF’ ALT = "няма информация за присъствие’ глътка ='PGalvin@xxx.com’ ID = "imn_77 тип = smtp" /></а></еталониране></NOBR>