Sharepoint как информационная система большого объема

Question

Я смотрю на проектирование некоторых основных информационных систем в новой компании, в которой я работаю (одна из моих идей описана здесь Система рабочих процессов )

Я подумал немного больше, и я настоятельно рекомендую использовать sharepoint для многих видов тяжелой работы, поскольку он поставляется с таким большим количеством возможностей.

Тем не менее, я не уверен, как он будет обрабатывать большой объем данных, которые мы будем к нему прибегать. Я прочитал официальный документ MS (http://go.microsoft.com/fwlink/?LinkId=95450&clcid=0x409),), в котором говорится, что около 2000 элементов в списке - это предел использования традиционных методов проектирования.

Но сначала немного информации о моем плане и структурах данных:

У нас есть несколько клиентов. У каждого клиента есть несколько приложений. Каждое приложение будет иметь несколько текущих заданий (или процессов).

Каждое приложение будет хранить значительную переписку и документацию. Каждое задание представляет собой обработку файла данных за один прогон и сохраняет информацию о задании, такую ​​как файл postscript, почтовые манифесты и т. Д.

Объем работы составит около 50 - 100 в день. Каждое задание будет иметь рабочий процесс, запускаемый внешними программами. Затем, скажем, на странице «Планировщик заданий», производственный персонал может планировать задания и выполнять настраиваемые действия над заданием (записанные в виде плагинов).

Я думал, что задания будут располагаться снаружи и доступны через BDC, но я все же хотел бы, чтобы они были представлены в списках sharepoint, чтобы добавить функциональность sharepoint и отчеты, и они были бы доступны в нескольких местах

например.

• Портал приложения - см. Вакансии для приложения
• Планировщик производства - просмотр списков предстоящих заданий, назначение ресурсов, запуск других функций (например, копирование файла печати на принтер, создание файла почтовой машины)
• Просмотр счетов - просмотр выполненных, но неоплаченных заданий, экспорт в пакет учета
• Просмотр клиента - клиентский портал отображает задания, счета, уровни запасов (из внешней системы склада), документацию, реестр изменений / служба поддержки

Таким образом, базовая информация о работе будет находиться в BDC, а затем sharepoint будет собирать дополнительные метаданные о каждой работе. Кроме того, мы могли бы добавить более продвинутые рабочие процессы, используя WF или что-то вроде K2 blackpoint / blackpearl.

Это возможно? Какие ресурсы вы бы порекомендовали прочитать, чтобы освоиться?

Answer 1

Чтобы использовать SharePoint, вы должны сосредоточиться на том, в чем хорош SharePoint и для чего он предназначен.

SharePoint - отличный портал для совместной работы, он не так хорош, как простая база данных большого объема. Итак ...

Вы можете настроить небольшой сайт для каждого клиента и дочерние сайты для каждой работы. Целью «сайта вакансий» является отображение (возможно, с помощью веб-части) соответствующих предстоящих работ, списка ошибок / исключений работ и соответствующей документации команды для каждого задания.

Можно создать отдельные сайты, чтобы дать конкретный «вид» работ. Например, можно создать сайт «Выставление счетов», чтобы снова просматривать с веб-частей BDC то, что требует выставления счетов.

https://iwsolve.partners.extranet.microsoft.com/SDPS/ может оказать некоторую помощь.

Не пытайтесь хранить огромные объемы информации в списке SharePoint только потому, что может быть возможно «пометить» ее метаданными. Таблица базы данных прекрасно может включать столбцы, предоставляющие дополнительную информацию, если требуется.

Думайте об этом так. Если вы создаете 50-100 заданий в день, то добавление этих данных в список предполагает, что пользователи ваших сайтов захотят вводить метаданные этих заданий вручную. Я думал, что нет, поэтому создайте системы, которые вам нужны, чтобы правильно хранить метаданные в источнике, или храните метаданные о «типах» заданий в списке SharePoint и разрешите SharePoint сопоставлять тип задания с заданиями в BDC. *

SharePoint поможет вам объединить всю информацию о вашей системе вместе, но, к сожалению, похоже, у вас много работы, чтобы просто спланировать, какая информация должна идти, куда и как каждый тип использования будет ее просматривать.

Answer 2

Пожалуйста, взгляните на это сообщение в блоге Я писал об управлении большими списками SharePoint для повышения производительности - оно может предложить небольшое объяснение проблемы 2000 элементов, которая на самом деле не является жестким ограничением количество элементов в списке, так как SharePoint будет поддерживать до 5 миллионов элементов в списке. Одним из способов решения этой проблемы может быть создание и поддержка различных представлений, которые фильтруются по индексируемому полю, чтобы показать вам разные элементы, до 2000 одновременно. Надеюсь, это поможет.

Дина Аюб Менеджер программы Windows SharePoint Services

Answer 3

SharePoint, вероятно, вполне подходит для пользовательского интерфейса, хотя вам необходимо тщательно продумать, какие части хранятся и изменяются в списках SharePoint, а какие хранятся в других местах. Это не столько проблема SharePoint, сколько проблема, с которой вам всегда приходится иметь дело, когда у вас несколько источников данных.

Вероятно, я бы использовал список SharePoint в качестве основного хранилища для заданий, чтобы избежать проблем с синхронизацией и упростить редактирование. Объем данных не должен быть проблемой - просто убедитесь, что вы не пытаетесь отобразить 2000 элементов одновременно - это представление, а не сам список, который сталкивается с проблемами производительности для большого количества элементов.

Answer 4

Сложный вопрос, Дейн ... Я хотел бы узнать немного больше о вашем дизайне / видении, прежде чем высказать свое мнение.

Исходя из того, что я прочитал в вашем вопросе, я бы не использовал SharePoint 2007 в качестве платформы разработки для этого приложения.

1) Опыт разработки в SharePoint 2007 может быть болезненным и непродуктивным время от времени.

• Трудно отладить
• Крутая кривая обучения

2) Легко попасть в проблему с производительностью

• Уровень данных является сложным и может потребовать экспертных навыков администратора SQL / SharePoint для масштабирования платформы.
• Содержимое базы данных не должно превышать 100 ГБ.

3) Развертывание может быть чрезвычайно сложным в зависимости от того, что вы делаете.

4) Новая версия выйдет в ближайшие 12 месяцев.

Только мой .02.