Выбор архитектуры для хранения больших видеофайлов встреч в SharePoint 2010

День добрый, уважаемый читатель!

У меня появилась задача хранения видеоматериалов встреч в SharePoint . Что взять за основу хранения файлов? На этот вопрос я отвечу в процессе написания этого сообщения.

Вкратце о задаче. - Инициатор создает встречу. Приглашает участников через рабочие процессы. Им высылается время, место и планы встречи. Во время встречи пишется видео материал который будет загружен в систему.

Выбор архитектуры усложнён необходимостью выполнять различные рабочие процессы по изменению атрибутов файла, а так же добавлением к этому файлу еще других меньших файлов. К примеру видео запись совещания будет весить около 500 метров,к ней нужно добавить протокол встречи, и приказ к выполнению действий и т.д..

Для начала решим задачу хранения больших файлов.

 

Мои мысли:

Изначально шарик не загружает файлы более 50 метров.

 

Снимаем это ограничение. Заходим в центр администрирования – управление приложениями-выбираем наше приложение –идем общие параметры-общие параметры- снизу меняем Максимальный объем отправляемых данных с 50 до 600. У меня все получилось без iisreset.

В библиотеки файлы грузятся. Но по условию к файлу нужно добавлять еще файлы с общими атрибутами. Т.е. нужна сущность типа список. Попытка загрузки большого файла в список привела к ошибке.

Что я только не делал, но избавиться от нее я не смог.

 

Далее стал решать задачу хранения нескольких файлов с одинаковыми атрибутами в библиотеке .

 

Способ первый - создания папок. Не подойдет. У папок нет будет атрибутов и придётся каждому файлу прописывать их отдельно. Да и слишком сложно будет для пользователей.

Второй вариант - загружать один файл в библиотеку, а в его свойствах прописывать ссылки на дополнительные файлы. Можно просто в текстовое поле загружать файл. Они все будут храниться в другой библиотеке. Второй вариант не очень хорош, потому что все будут иметь доступ к вторичной библиотеке, где будет простая большая свалка файлов. Права там разграничить проблематично. Да и поле типа расширенный форматируемый текст в библиотек добавить можно , только через дизайнер. И далее , не в коем случае не менять название столбца. Почему так? Хотя вариант интересен и можно было бы подумать над усовершенствованием.

 

Третий вариант-  можно связать список с библиотекой, либо лукапом указывать другие файлы. Но это программирование или не самые легкие действия в дизайнере.

 Поэтому остается четвертый вариант- набор документов. Инструкций как его создавать в инете множество, к примеру . Набор эта та сущность которая позволяет хранить все файлы с общими атрибутами в одной “папке” , которая и будет иметь общие свойтсва. Каждый файл сможет их наследовать, и дополнительно иметь свои.

 Архитектуру выбрал. Мне осталось настроить рабочие процессы и "разукрасить" решение под продажу.

В следующих блоках я расскажу о своём опыте подключения RBS (правильное хранение больших файлов в Sharepoint)  и разных хитростях работы с наборами документов пригодившимися в решении этой задачи, которые я ранее успешно применял.

 

Буду рад ответить на вопросы, а так же добовлению в сообщение новых Ваших идей.

 

С уважением, Адрей