Каталоги бизнес-данных – интеграция легким движением руки

Нелли Садретдинова

Каталоги бизнес-данных – интеграция легким движением руки

В любой организации существует множество бизнес-приложений и баз данных. Удобные средства работы с информацией из разнообразных источников предлагает мощный инструмент в составе MOSS 2007 – BDC или каталоги бизнес-данных.

Гибкое использование на корпоративном портале данных из бизнес-систем открывает перед разработчиком весьма привлекательные перспективы, например:

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

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

Sharepoint 2007 предоставляет несколько возможностей отображения данных из Line-Of-Business (LOB)-систем:

• веб-часть Data Form Web Part (наследник Data View Web Part из SPS 2003);
• написание собственных веб-частей;
• каталоги бизнес-данных, business data catalogs (BDC).

BDC – это, пожалуй, одна из самых интересных служб новой версии портала. По сравнению с другими способами, перечисленными выше, каталоги бизнес-данных обладают следующими преимуществами:

• BDC позволяют строить приложения легко и быстро, максимально используя весь готовый инструментарий Sharepoint, практически без написания кода;
• предоставляется более глубокий уровень интеграции: встраивание в списки и библиотеки Sharepoint, поддержка действий пользователей, подключение к общей системе поиска и др.;
• BDC имеют встроенные средства разграничения доступа и их проще персонализировать, особенно с помощью службы единого входа;
• каталоги бизнес-данных более надежны и безопасны, т.к. параметры подключения не хранятся в открытом виде на странице, а определены в настройках приложения на сервере, кроме того, через BDC можно получить доступ строго к определенным таблицам и данным. Напомню, что каталоги бизнес-данных доступны только при приобретении корпоративной лицензии MOSS 2007.

Файлы определений приложений. Подключение к источникам

BDC позволяют отображать на страницах портала данные из широкого набора источников – любой базы данных, к которой можно подключиться с помощью ADO.NET, ODBC или OleDB. Также можно подключиться к любому веб-сервису.

Для подключения необходимо описать бизнес-данные в XML-файле определения приложения (Application Definition File, ADF). Примеры ADF-файлов можно найти в SDK [1].

Остановлюсь на некоторых нюансах подключения к базам данных. Информация о подключении хранится в объекте метаданных LobSystemInstance. Подробно все свойства объекта LobSystemInstance описаны также в SDK, поэтому здесь рассмотрю только наиболее важные из них.

Прежде всего это свойство Database Access Provider, которое может иметь всего 4 значения:

• SqlServer (естественно, для подключения к Microsoft SQL Server);
• OleDb;
• Oracle;
• Odbc.

Внимание! Регистр букв в ADF-файле имеет значение!

Еще один важный параметр – это способ аутентификации – AuthenticationMode. Предусмотрены варианты:

• PassThrough – в этом случае для аутентификации передаются в открытом виде логин и пароль, напрямую указанные в свойствах подключения, это наиболее простой и наименее безопасный способ аутентификации;
• RevertToSelf – режим по умолчанию, в этом случае доступ к данным осуществляется под учетной записью пула IIS, под которым запущено приложение Sharepoint;
• WindowsCredentials – для аутентификации используется учетная запись Windows-пользователя, этот способ рекомендуется использовать, если на сервере баз данных или в LOB-приложении используется аутентификация Windows;
• RdbCredentials (только для баз данных) – для аутентификации используются учетные данные из базы данных службы единого входа; этот способ рекомендуется, когда на сервере баз данных используется собственная аутентификация;
• Credentials (только для веб-сервисов) – принцип аутентификации аналогичен RdbCredentials, но используется только для веб-сервисов, для basic или digest аутентификации на веб-сервере.

Отличие аутентификации PassThrough от Credentials (RdbCredentials) состоит в том, что при PassThrough серверу баз данных передается один и тот же логин, общий для всех пользователей. При указании же Сredentials передается личная учетная запись пользователя в LOB-приложении, соответствующая его учетной записи на портале. Эти соответствия должны быть прописаны в базе данных службы единого входа, сделать это можно в центре администрирования Sharepoint.

В последних трех случаях необходимо также указать параметры подключения к службе единого входа (Single Sign On, SSO), которая должна быть запущена и настроена на сервере Sharepoint.

SSO – удобное средство «сквозной» аутентификации, когда пользователю не нужно вводить несколько раз разные логины и пароли даже для приложений, где используется аутентификация, отличная от Windows. Коротко о настройке службы единого входа рассказано в статье [4].

Привожу пример LobSystemInstance для подключения к базе данных Oracle:

<LobSystemInstance Name="ExampleInstance">

      <Properties>

        <Property Name="DatabaseAccessProvider" Type="System.String">Oracle</Property>

        <Property Name="AuthenticationMode" Type="System.String">PassThrough</Property>

        <Property Name="RdbConnection Data Source" Type="System.String">tns name</Property>

        <Property Name="RdbConnection Pooling" Type="System.String">false</Property>

        <Property Name="RdbConnection User Id" Type="System.String">username</Property>

        <Property Name="RdbConnection Password" Type="System.String">password</Property>

        <Property Name="RdbConnection Integrated Security" Type="System.String">false</Property>

       <Property Name="WildcardCharacter" Type="System.String">%</Property>

      </Properties>

</LobSystemInstance>

Обратите внимание, что в свойстве RdbConnection Data Source в данном случае указывается не адрес сервера, а имя tns, прописанное в конфигурационном файле Oracle «tnsnames.ora».

Приведу также примеры строки описания подключения к источникам данных ODBC, в данном случае – Firebird и MySQL:

<Property Name="RdbConnection Data Source" Type="System.String">"Driver={Firebird/InterBase(r) \

    driver};DSN=dsn_name;Uid=username;Pwd=password;Trusted_Connection=True;"</Property>

<Property Name="RdbConnection Data Source" Type="System.String">"Driver={MySQL ODBC 3.51 Driver};Dsn=dsn_name;Trusted_Connection=True;"</Property>

Также обратите внимание, что wildcard-символ для разных баз данных отличается, поэтому его также необходимо указывать в свойствах. К примеру, для Oracle это «%», а в Microsoft SQL Server используется «*».

При использовании SSO необходимо дополнительно указать свойства SSOApplicationID и SSOProviderImplementation:

<Property Name="SsoApplicationId" Type="System.String">myApp</Property>

<Property Name="SsoProviderImplementation" Type="System.String">Microsoft.SharePoint.Portal.SingleSignon.SpsSsoProvider,

            Microsoft.SharePoint.Portal.SingleSignon,

            Version=12.0.0.0, Culture=neutral,

            PublicKeyToken=71e9bce111e9429c

</Property>

Полный пример описания подключения с использованием SSO приведен в SDK [1].

Совет. Перед подключением к бизнес-данным через ODBC или OleDB рекомендуется проверить настроенный DSN или же строку подключения любым подручным способом (средствами клиентского приложения или же, к примеру, Microsoft Access или Excel). Также рекомендуется проверять корректность SQL-запросов перед их использованием в BDC. Связано это с тем, что каталоги бизнес-данных достаточно сложно отлаживать, и в логах не всегда корректно отображается ошибка.

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

Файлы определений приложений. Запросы к данным

Ключевой объект метаданных в ADF-файле – Entity (сущность). Это понятие ближе всего к понятию «объекта» из объектно-ориентированного программирования. Сущность включает в себя идентификаторы, методы, фильтры и действия. Несколько сущностей могут быть связаны между собой с помощью ассоциаций.

Упрощенно описание сущности выглядит следующим образом:

<Entity EstimatedInstanceCount="100" Name="Product">

    <Properties>

    …

    </Properties>

    <Identifiers>

     …

    </Identifiers>

    <Methods>

    …

    </Methods>

    <Actions>

    …

    <Actions>

</Entity>

За отображение данных отвечают методы. Их три:

• Finder – предоставляет набор записей для списков и библиотек Sharepoint;
• SpecificFinder – предоставляет одну запись (экземпляр объекта), согласно указанному идентификатору, для соответствующих веб-частей Sharepoint и страницы профиля;
• IdEnumerator – предоставляет список идентификаторов всех записей для обходчика поисковой системы Sharepoint.

Тип метода указывается в MethodInstances:

<MethodInstances>

      <MethodInstance Name="ProductsSpecificFinderInstance" Type="SpecificFinder" ReturnParameterName="Products" />

</MethodInstances>

В методе могут быть указаны один или несколько входных параметров с целью:

• предоставить пользователю возможность поиска по тому или иному полю;
• для методов типа SpecificFinder (входной параметр – идентификатор);
• для связи веб-частей с бизнес-данными между собой (с использованием ассоциаций).

Для каждого входного параметра в первых двух случаях необходимо описать соответствующий фильтр. В атрибутах фильтра необходимо определить тип – операцию, с помощью которой производится отбор: «равно», «содержит», «больше» и др. Для поиска можно также дополнительно указать свойство, значение которого будет отображаться рядом с поисковым полем:

<FilterDescriptor Type="Comparison" Name="ID" >

    <Properties>

      <Property Name="Comparator" Type="System.String">Равняется</Property>

      </Properties>

</FilterDescriptor>

Внимание! Для разных баз данных входные параметры в запросе обозначаются по-разному (см. таблицу).

Правила обозначения входных параметров для разных баз данных

В методе обязательно указывается параметр типа «Return», который содержит описание возвращаемого набора полей. Пример описания поля:

<TypeDescriptor TypeName="System.String" Name="ProductName">

    <LocalizedDisplayNames>

        <LocalizedDisplayName LCID="1049">Наименование товара</LocalizedDisplayName>

    </LocalizedDisplayNames>

    <Properties>

        <Property Name="DisplayByDefault" Type="System.Boolean">true</Property>

    </Properties>

  </TypeDescriptor>

При описании полей обратите внимание на следующие нюансы:

• Имя дескриптора типа должно обязательно совпадать с названием поля, возвращаемым запросом. Если возвращается результат выполнения функции или операции, в запросе нужно обязательно указать для него имя, например: «SELECT date_format(dt, ‘%d.%m.%Y’) AS formatted_dt FROM …».
• Если вы заглянете в SDK [1], то заметите, что в примерах в атрибуте LCID параметра LocalizedDisplayName указано значение «1033», соответствующее английскому языку. Для русского языка необходимо указывать значение «1049». Можно указать значения для нескольких языков одновременно, для мультиязычных систем.
• Тип возвращаемого поля и тип дескриптора обязательно должны совпадать. К примеру, если значение возвращаемого целого числа больше допустимого для типа System.Int32, то возникнет ошибка, необходимо указать System.Int64.
• Данные типа BLOB для баз данных не поддерживаются.

Также для сущности можно указать набор действий. Под действием в данном случае понимается ссылка с набором параметров. По ссылке можно перейти к другой странице Sharepoint, открыть форму InfoPath, открыть страницу LOB-приложения, отправить почту, наконец, записать данные обратно в LOB-систему, используя веб-сервисы с поддержкой записи. Пример описания действия:

<Action

     Name="Подробная информация о покупателе"

     Position="1"

     IsDisplayed="true"

     IsOpenedInNewWindow="true"

     Url="http://moss2007/sitedirectory/sales/customerinfo.aspx?&amp;CustomerID={0}"

     ImageUrl="">

   <ActionParameters>

      <ActionParameter Name="CustomerID" Index="0" />

   </ActionParameters>

</Action>

Если определен метод Specific Finder, Sharepoint автоматически создает для сущности действие «Просмотреть профиль» и страницу профиля с результатами выполнения этого метода для выбранной записи. По умолчанию страница профиля находится на узле администрирования поставщика общих служб и доступна только администратору, поэтому лучше отключать это действие или создавать аналогичную страницу на общем узле.

Сущности можно связать между собой посредством ассоциаций. Например, если на одной странице нужно отобразить список товаров, приобретенных выбранным покупателем, понадобится такая ассоциация:

<Association

      AssociationMethodEntityName="Product"

      AssociationMethodName="GetProductsByCustomer"      

      AssociationMethodReturnParameterName="Products"

      Name="ProductsByCustomer" IsCached="true">

  <SourceEntity Name="Customer" />

  <DestinationEntity Name="Product" />

</Association>

При этом в методе «GetProductsByCustomer» должен быть указан идентификатор сущности «Product» следующим образом:

<TypeDescriptor TypeName="System.Int32" Name="ProductID" IdentifierEntityName="Product" IdentifierName="ProductID">

Персонифицировать результаты запросов можно разными способами.

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

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

<FilterDescriptor Type="UserContext" Name="currentuser" />

Для учетной записи SSO:

<FilterDescriptor Type="Username" Name="currentuser" />

<FilterDescriptor Type="Password" Name="password" />

Автоматизированные средства создания ADF-файлов

Сторонние производители уже давно предлагают небольшие утилиты для визуального создания ADF-файлов. Это, например, MOSS BDC Design Studio, BDC Meta Man и другие. Вместе с последней версией SDK [1] Microsoft предложила собственную бесплатную утилиту: BDC Definition Editor.

Администрирование каталогов бизнес-данных

Администрирование BDC осуществляется со страницы управления поставщиком общих служб. Если на ферме серверов несколько поставщиков общих служб, то настройки необходимо повторить для каждого поставщика, который предоставляет сервисы приложениям, где будут использоваться бизнес-данные.

Импорт файла определения приложения

После того, как ADF-файл готов, его нужно импортировать в каталоги бизнес-данных Sharepoint. Для этого необходимо перейти к центру администрирования поставщика общих служб и выбрать пункт меню «Импорт определения приложения» (см. рис. 1).

Рисунок 1. Импорт определения приложения каталога бизнес-данных

Примечание. Если у вас нет раздела «Каталог бизнес-данных», значит, ваша лицензия Sharepoint не является корпоративной, и вам необходимо приобрести нужную лицензию.

В ходе загрузки производится анализ ADF-файла, в случае ошибки импорт произведен не будет, а будет показано сообщение об ошибке.

Настройка разрешений

Далее необходимо настроить безопасность для каталогов бизнес-данных. Разрешения можно указывать на трех уровнях:

• для всех каталогов бизнес-данных;
• для отдельных приложений;
• для отдельных сущностей.

Если вы добавляете пользователя в список разрешений для всех каталогов, то эта настройка будет действовать только для вновь импортируемых определений приложений. Чтобы автоматически добавить разрешения пользователя ко всем приложениям и сущностям, воспользуйтесь ссылкой «Копировать все разрешения для потомков».

Для бизнес-данных есть четыре вида разрешений:

• изменение;
• выполнение;
• выбор в клиентах;
• настройка разрешений.

Всем пользователям, которые будут просматривать страницы с бизнес-данными, необходимо дать разрешение на выполнение. Тем, кто будет формировать эти страницы (дизайнерам, разработчикам) – разрешение на выбор в клиентах.

Остальные разрешения необходимы главным образом администратору системы.

Права пользователей можно также определять внутри ADF-файла, в объекте AccessControlList.

Дополнительные настройки

Для того чтобы использовать каталоги бизнес-данных на узле, на всех четырех уровнях (ферма серверов, веб-приложение, семейство узлов, параметры узла [4]) должна быть активирована возможность (feature) «Компоненты семейства узлов корпоративного выпуска Office SharePoint Server».

Действия для сущностей можно настроить не только путем их определения в ADF-файле, но и на странице администрирования общего доступа. Можно удалить созданные действия и добавить новые (см. рис. 2).

Рисунок 2. Создание нового действия

Обновление версий

По мере разработки узла с бизнес-данными часто требуется добавление новых сущностей, изменение методов, создание ассоциаций, одним словом, редактирование и повторный импорт ADF-файла.

Sharepoint не разрешает повторный импорт одной и той же версии ADF-файла для одной и той же LOB-системы. Если дать LobSystemInstance другое имя, то будет создано параллельно новое приложение с новыми сущностями. Если сначала удалить импортированное определение приложения, а затем добавить заново, то в веб-частях, отображающих бизнес-данные, возникнет ошибка, т.к. у приложения сменятся внутренние идентификаторы.

Правильный способ – указание новой версии определения приложения в ADF-файле при повторном импорте.

Параметр Version указывается в объекте LobSystem в начале файла определения:

<LobSystem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" \

    xsi:schemaLocation="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog BDCMetadata.xsd" \

    Type="Database" Version="1.0.0.1" Name="Sales" xmlns="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog">

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

Со страницы администрирования поставщика общих служб можно произвести обратную процедуру – экспорт xml-файла с определением приложения.

Отображение бизнес-данных

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

Веб-части для отображения бизнес-данных

Sharepoint предоставляет 6 веб-частей для работы с бизнес-данными.

Список бизнес-данных

Основной компонент для отображения набора бизнес-данных, предоставленных методом Finder. Представление бизнес-данных можно настроить с помощью веб-интерфейса, указав нужные столбцы, ограничения на количество записей, отображений действий, порядок сортировки и др.

Элемент бизнес-данных

Этот компонент отображает одну запись, предоставленную методом SpecificFinder. Он используется, в частности, на странице профиля.

Построитель элементов бизнес-данных

Очень простой невидимый компонент, который передает в веб-часть «Элемент бизнес-данных» идентификатор записи из строки запроса URL. Между построителем и элементом бизнес-данных необходимо установить соединение стандартным для веб-частей способом.

Дополнительный список бизнес-данных

Этот список служит для отображения данных, связанных с основным списком бизнес-данных при помощи ассоциаций. Между дополнительным и основным списком также должно быть установлено соединение стандартным для веб-частей способом.

Действия с бизнес-данными

Отображает список действий для конкретного элемента бизнес-данных.

Фильтр каталога бизнес-данных

Эта веб-часть позволяет передавать выбранные значения из списка бизнес-данных в другие веб-части.

Встраивание в стандартные библиотеки и списки

В настраиваемых списках и библиотеках Sharepoint можно создавать столбцы типа «Бизнес-данные». Это очень удобно, когда атрибутом документа или элемента списка должно выступать одно из значений справочника LOB-системы.

Создать столбец с бизнес-данными очень просто (см. рис. 3).

Рисунок 3. Создание столбца типа «Бизнес-данные»

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

Поиск

Для того чтобы Sharepoint мог производить поиск по бизнес-данным, необходимо, чтобы в определении приложения были описаны методы IdEnumerator и SpecificFinder. IdEnumerator должен возвращать множество идентификаторов всех записей, а SpecificFinder получать запись по данному идентификатору. Если будет использоваться инкрементный поиск, то SpecificFinder должен возвращать параметр LastModifiedDate с датой последнего изменения записи.

После этого на странице администрирования поставщика общих служб необходимо настроить параметры поиска. Создайте новый источник содержимого типа «Бизнес-данные» и выберите нужную LOB-систему. После этого необходимо настроить свойства для обхода.

Выберите пункт меню «Сопоставления свойств метаданных» и нажмите кнопку «Создать управляемое свойство» (см. рис. 4).

Рисунок 4. Сопоставления свойств метаданных

Откроется страница создания свойства (см. рис. 5).

Рисунок 5. Создание управляемого свойства

Введите название свойства, после чего нажмите кнопку «Добавить сопоставление», затем выберите категорию «Бизнес-данные» и укажите свойство для обхода. Таким образом необходимо добавить все свойства, по которым будет осуществляться поиск.

Наконец, создайте область поиска для бизнес-данных и добавьте правило включения только что созданного источника данных, например, «Поиск по товарам».

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

При поиске возвращаемый набор данных может быть отфильтрован в соответствии с правами пользователя. Для этого можно определить специальный тип метода AccessChecker. Подробную информацию можно найти в SDK [1].

Профили пользователей

BDC, в отличие от ActiveDirectory, не могут быть главным источником импорта профилей пользователей. Однако с их помощью можно заполнять дополнительные свойства, значения которых будут получены из LOB-систем, например, из кадровых приложений.

Есть два пути определить правило синхронизации профилей:

• в LOB-системе создать поле, в котором будут храниться учетные записи пользователей (если такого в ней еще нет); обратите внимание, что учетные записи Windows должны быть заполнены с указанием домена: «domain\username»;
• в профилях пользователей создать свойство, где будут храниться идентификаторы пользователей из LOB-системы, например LobSystemUserID, и заполнить это поле вручную.

В ADF-файле необходимо создать метод SpecificFinder, который будет по учетной записи или идентификатору пользователя соответственно находить необходимые поля с информацией о пользователе.

Далее нужно создать подключение импорта профилей к источнику бизнес-данных. Для этого на странице управления поставщиком общих служб необходимо выбрать пункт «Свойства и профили пользователей», перейти к странице «Просмотреть подключения импорта» и нажать кнопку «Создать подключение». В качестве типа подключения выберите «Каталог бизнес-данных». Далее выберите нужную сущность, а в возвращаемых свойствах укажите AccountName, если синхронизация будет происходить по учетной записи, или идентификатор пользователя из Lob-системы, если эти идентификаторы предварительно уже заполнены, например, LobSystemUserID (см. рис. 6).

Рисунок 6. Создание подключения к BDC для импорта пользователей

Затем нужно перейти к странице «Просмотреть свойства профиля» и создать новые свойства для синхронизации, указав в качестве источника исходных данных созданное подключение к BDC и сопоставив с новым свойством профиля поле из BDC.

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

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

После импорта профилей пользователей новые свойства заполнятся сведениями из LOB-системы.

Отладка и поиск ошибок

Содержание ошибок при отображении бизнес-данных можно найти в двух источниках. Во-первых, это журнал «Application» в «Event Viewer» на сервере Sharepoint. Ошибки имеют категорию «Бизнес-данные», а источник – «Office Sharepoint Server».

Однако в журнале отображаются далеко не все возникающие ошибки. Более подробную информацию можно получить в журналах трассировки, которые нужно предварительно настроить со страницы центрального администрирования Sharepoint (см. рис. 7).

Рисунок 7. Настройка журнала трассировки для получения ошибок, связанных с бизнес-данными

API

Если вам недостаточно предоставленных в MOSS 2007 способов использования бизнес-данных, то можно обратиться к API и разработать собственные веб-части или страницы. Microsoft предоставляет специальные интерфейсы для работы с BDC, примеры работы с ним приведены в SDK [1]. Средствами API можно работать с бизнес-данными, создавать новые определения приложений, разрабатывать собственные компоненты поиска.

Заключение

Однажды научившись работать с бизнес-данными, интегрировать информацию из LOB-систем в портал Sharepoint можно легким движением руки. А с использованием визуальных средств разработки ADF-файлов даже не придется написать ни единой строчки XML-кода. Поэтому BDC – не только одно из самых полезных нововведений в MOSS 2007, но и отчасти воплощение мечты ленивого разработчика.

1. Microsoft Office Sharepoint Server 2007 SDK – http://www.microsoft.com/downloads/details.aspx?FamilyID=6d94e307-67d9-41ac-b2d6-0074d6286fa9&DisplayLang=en (на момент выхода статьи последняя версия SDK вышла 22.08.2007).
2. Билл Инглиш. «Справочник администратора. Microsoft Office SharePoint Server 2007», Эком Паблишерз, 2007 г.
3. Все о Sharepoint на сайте Microsoft – http://office.microsoft.com/ru-ru/sharepointserver/default.aspx.
4. Садретдинова Н. MOSS 2007: быстрая настройка и самые интересные возможности. //Системный администратор, №7, 2007 г. – С. 18-30.

Комментарии могут оставлять только зарегистрированные пользователи