Как подружить ASP.NET Controls и DI-контейнер

Интро

В последнее время решил немного освежить свои знания в ASP.NET, в связи с чем углубился в процессы генерации кода контролов по разметке (*.ascx, *.aspx) и обнаружил что можно делать очень интересные решения, о которых  о хочу поведать. Итак сегодня мы узнаем, как подружить наш Dependency Injection контейнер с генерируемым контролами кодом.

Поехали

DependencyInjection_Solution[1]

В качестве DI-контейнера будет выступать Microsoft Unity, но это не принципиально, всё что будет касаться DI не зависит от используемого контейнера.

Проблема состоит в следующем – есть некоторый ASP.NET Control, в который мы хотим внедрит зависимости, а так же воспользоваться услугами Service Locator’а для управления интересующими нас зависимостями.

В Microsoft Unity есть некоторые средства для того, чтобы сделать это не прилагая особенных усилий: мы можем произвести инъекцию в свойство элемента управления, нас интересующее примерно следующим образом:

  1. Отметить атрибутом Dependency необходимое свойство
    public class MyControl : UserControl
    {
            [Dependency]
            public MyPresenter Presenter
            {
                get { return _presenter; }
                set
                {
                    _presenter = value;
                    _presenter.View = this;
                }
            }
    }
  2. Проинициализировать элемент управления можно следующим образом

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        _сontainer.BuildUp(GetType(), this);
    } 
  3. Позаботиться о местоположении контейнера в вашем приложении, я предлагаю использовать для этого HttpApplication, унаследовавшись от которого и произведя небольшие модификации файла global.asax мы получаем необходимое нам хранилище для контейнера, обращаться с ним необходимо примерно следующим образом

    ((Sapphire.Application)HttpContext.Current.ApplicationInstance).Container

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

Т.е. наш интерес состоит в том, чтобы класс MyUserControl выглядел примерно так (думаю сборщику страницы это не совсем понравится)

public class MyControl : UserControl
{
    public MyControl(MyPresenter presenter)
    {
         _presenter = presenter;
         _presenter.View = this;
    }
}

Предлагаю этим и заняться. Начнём с того, что у элементов управления, описанных в разметке страницы, при генерации страницы указываются их конструкторы без параметров, интересно, как можно управлять данным процессом, первоначально, покопавшись в web.config я предполагал сделать это через:

<buildProviders>
    <add extension=«.aspx» type=«System.Web.Compilation.PageBuildProvider»/>
    <add extension=«.ascx» type=«System.Web.Compilation.UserControlBuildProvider»/>
    …
</buildProviders>

Однако реализация своего PageBuildProvider’а – довольно серьезное занятие, думаю отложить это для серьезной на то необходимости. Однако благодаря BuildProvider’ам можно генерить к примеру слой доступа к данным, для этого надо:

Написать и зарегестрировать обработчик для какого-нибудь своего расширения, к примеру *.dal и сделать что-нибудь наподобее http://www.codeproject.com/KB/aspnet/DALComp.aspx

кстати подобная логика реализована в SubSonic http://dotnetslackers.com/articles/aspnet/IntroductionToSubSonic.aspx

так же интересная реализация наследования страницы от generic типов http://stackoverflow.com/questions/1480373/generic-inhertied-viewpage-and-new-property

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

Вообщем, данный вариант нам не подходит, необходимо сделать что-нибудь проще, и есть отличное решение, с помощью атрибута ControlBuilder мы можем указать свою логику сборки элемента управления из разметки, это будет выглядеть примерно так

[ControlBuilder(typeof(MyControlBuilder))]
public class UserControl : System.Web.UI.UserControl
{
}

Теперь разберемся с реализацией  MyControlBuilder, этот тип должен наследовать от ControlBuilder и с помощью перегрузки ProcessGeneratedCode мы с вами сможем указать сборщику на необходимость использования нашего кода вместо вызова конструктора без атрибутов элемента управления:

    public override void ProcessGeneratedCode(CodeCompileUnit codeCompileUnit,
                                              CodeTypeDeclaration baseType,
                                              CodeTypeDeclaration derivedType,
                                              CodeMemberMethod buildMethod,
                                              CodeMemberMethod dataBindingMethod)
    {
      codeCompileUnit.Namespaces[0].Imports.Add(new CodeNamespaceImport(«Sapphire.Web.UI»));
      ReplaceConstructorWithContainerResolveMethod(buildMethod);
      base.ProcessGeneratedCode(codeCompileUnit, baseType, derivedType, buildMethod, dataBindingMethod);
    }

самое интересно скрывает метод ReplaceConstructorWithContainerResolveMethod

    private void ReplaceConstructorWithContainerResolveMethod(CodeMemberMethod buildMethod)
    {
      foreach (CodeStatement statement in buildMethod.Statements)
      {
        var assign = statement as CodeAssignStatement;

        if (null != assign)
        {
          var constructor = assign.Right as CodeObjectCreateExpression;

          if (null != constructor)
          {
            assign.Right =
              new CodeSnippetExpression(
                string.Format(«SapphireControlBuilder.Build<{0}>()»,
                              ControlType.FullName));
            break;
          }
        }
      }
    }

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

Однако это ещё не решении задания, т.к. есть метод динамической загрузки элемента управления Page.LoadControl(), для него придётся написать свой вариант

  public static class PageExtensions
  {
    public static UserControl LoadAndBuildUpControl(this Page page, string virtualPath)
    {
      var control = page.LoadControl(virtualPath);
      return SapphireControlBuilder.Build<UserControl>(control.GetType());
    }
  }

Вот мы и справились с поставленной задачей, однако это ещё не всё. А почему теперь не воспользоваться всеми преимуществами Unity, и не внедрить в наш элемент управления AOP времени исполнения с помощью Unity Interception.

К примеру мы можем сделать следующее

public class MyControl : UserControl
{
    [HandleException]
    public override void DataBind()
    {
      base.DataBind();
    }
}

Это будет означать, что обработка исключений должна добавляться на лету, к тому ж предоставляя нам возможность её изменения во время исполнения, для начала пусть её реализация будет примерно следующая

  [AttributeUsage(AttributeTargets.Method | AttributeTargets.Property, AllowMultiple = false, Inherited = true)]
  public class HandleExceptionAttribute : HandlerAttribute
  {
    public override ICallHandler CreateHandler(IUnityContainer container)
    {
      return new ExceptionHandler();
    }
  }

  public class ExceptionHandler : ICallHandler
  {
    /// <exception cref=»SapphireUserFriendlyException»><c>SapphireUserFriendlyException</c>.</exception>
    public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
    {
      var result = getNext()(input, getNext);
      if (result.Exception == null)
        return result;
      throw new SapphireUserFriendlyException();
    }

    public int Order { getset}
  }

Ну и конечно же надо сконфигурировать контейнер для создания наших прокси-обработчиков

    public static T Build<T>()
    {
      return (T)((Application)HttpContext.Current.ApplicationInstance)
        .Container
          . AddNewExtension<Interception>()
          .Configure<Interception>()
            .SetInterceptorFor<T>(new VirtualMethodInterceptor())
        .Container
          .Resolve<T>();
    }

Ресурсы

Sapphire.Application – для чего всё это реализовывалось http://github.com/butaji/Sapphire/tree/master/trunk/Sapphire.Application/

Дэвид предлагает реализации связывания с данными следующего поколения “Databinding 3.0” на основе аналогичного подхода http://weblogs.asp.net/davidfowler/archive/2009/11/13/databinding-3-0.aspx

Ноябрь 16, 2009. Метки: , , , , , , . .net, IoC, Sapphire, sharepoint. Оставить комментарий.

REPL WebPart для SharePoint

Intro

logoСегодня я расскажу о прототипе первого компонента под ярлычком Sapphire. Это REPL WebPart. Эта веб-часть предназначенная для производства оперативных изменений на серверной стороне SharePoint, так же для удаленного исполнения скриптов и тестирования некоторых кусков кода.

PreBody

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

Здесь есть небольшая презетнация, в которой я постарался отобразить принципы работы Repl WebPart:

В добавок к слайдам расскажу о том, что веб-часть представляет собой классический хостинг Dynamic Languages Runtime языков, пока из которых доступен только Python.

Body

Далее хотелось поговорить о том, как же всё это у меня получилось, итак проект включает в себе несколько основных модулей:

  • Веб-часть и контролы представления
  • Хостинг языков

Далее о них поподробнее

Language Hosting

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

  public interface ILanguagesFactory
  {
    ILanguage Create(string name);
  }

  public interface ILanguage
  {
    string Name { get}

    object Execute(string input);

    void SetVar(string name, object value);
    
    object GetVar(string name);
  }

Отлично, далее к нашему проекту присоединяются сборки, необходимые для имплементации скриптовых языков:

Всё готово для того, чтобы реализовать Python, как среду для исполнения кода, отлично, приступим:

  public class PythonLanguage : ILanguage
  {
    private readonly ScriptScope _scope;
    
    public string Name
    {
      get { return «Python»}
    }

    public PythonLanguage()
    {
      _scope = Python.CreateEngine().CreateScope();
    }

    public object Execute(string input)
    {
      ScriptSource source = _scope.Engine.CreateScriptSourceFromString(input);
      return source.Execute(_scope);
    }
  }

Далее немного усложним задачу, в связи с тем, что нам будет необходимо реализовать контекст для работы с SharePoint, выглядеть это должно примерно так:

    [Test]
    private void python_should_assume_sharepoint_variables()
    {
      SPWeb fakeWeb = Isolate.Fake.Instance<SPWeb>();
      Isolate.WhenCalled(() => fakeWeb.Title).WillReturn(«I’m fake web»);
      var python = _factory.Create(«Python»);
      python.SetVar(«__x__»«123″);
      python.SetVar(«__web__», fakeWeb);
      python.Execute(«__x__ = __web__.Title»);
      var x = (string)python.GetVar(«__x__»);
      Assert.AreEqual(x, «I’m fake web»);
    }

Для работы с объектами SharePoint в из IronPython, нам необходимо добавить несколько библиотек:

      _scope.Engine.Runtime.LoadAssembly(typeof(string).Assembly);
      _scope.Engine.Runtime.LoadAssembly(typeof(Uri).Assembly);
      _scope.Engine.Runtime.LoadAssembly(typeof(SPList).Assembly); 

Это будет основой нашей работы с динамическими языками

WebPart + WebControls

Создадим проект с помощью SPVisualDev, добавим в него feature, внутри которой создадим веб-часть Repl WebPart, всё остальные действия стандартные, однако есть небольшой нюанс, нам нужен будет объект, с помощью которого можно будет выводить строковые значения после исполнения. Я решил создать для этих целей объект с классическим названием Console, его реализация предельна проста:

  public class Console
  {
    private readonly StringBuilder _messageBuilder = new StringBuilder();

    public void Write(object message)
    {
      _messageBuilder.Append(message);
    }

    public void WriteLine(object message)
    {
      _messageBuilder.AppendLine(message.ToString());
    }

    public string Message
    {
      get
      {
        return _messageBuilder.ToString();
      }
    }
  }

Мы будем передавать его в среду исполнения языков, а после исполнения кода опрашивать его свойство Message и выводить его содержимое в нашу веб-часть.

EndBody

Все исходники проекта доступны на github: http://github.com/butaji/Sapphire

Так же предварительную версию Sapphire.Environment (решение поставляется в WSP) можно слить на CodePlex: http://sapphire.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=34895

Октябрь 24, 2009. Метки: , , , , . .net, C#, DLR, Python, sharepoint, tdd. 1 комментарий.

Кратко о Patterns & Practices: SharePoint Guidance

Интро

clip_image001

В данной статье я хочу произвести обзор руководства под названием “SharePoint Guidance” от подразделения Microsoft patterns & practices. Данное руководство предназначено разработчикам/архитекторам SharePoint, в нём описаны основные принципы построения систем на данной платформе. Над руководством трудились выдающиеся представители разработки под SharePoint, а так же он упорно держится в списке самых активных проектов на CodePlex. Далее чуть подробнее.

Описание руководства

Руководство фактически состоит из нескольких аспектов:

  1. SharePoint Guidance Library – библиотека наиболее используемых и полезных функций, таких как управление конфигурацией, абстрагирование слоя данных, логирование событий и сервисная инфраструктура
  2. Документация, в которой подробно описаны все принципы построения приведенных примеров, а так же руководства по основным вопросам, возникающим в разработке на SharePoint.
  3. Contoso Partner Portal Reference Implementation – показательное приложение на MOSS некоей компании Contoso, являющее собой экстранет-портал, в приложении используются практики наиболее приближенные к промышленным решениям.
  4. Contoso Training Management Reference Implementation – простое приложение HR-отдела, демонстрирующее базовые принципы построения решений на WSS.
  5. QuickStarts – два небольших примера самых простых приложений на SharePoint, а так же доступа к данным

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

image

Обзор руководства

1ая версия вышла в прошлом году (Dec2008), в настоящее время доступна 2ая версия данного руководства (Aug2009), о ней и будет идти речь.

  • Introduction – небольшое введение, а так же рекомендации к инструментам разработки: VSeWSS, U2U CAML Query Builder, CAML.NET, Typemock Isolator
  • Developing SharePoint Applications – основные сценарии разработки под платформу, а так же её ключевые возможности
  • Design and Development Guidelines – отображены ключевые моменты архитектуры SharePoint, а так же описаны подходы решения тех или иных задач разработки под платформу; описаны рекомендации к управлению жизненным циклом проектов
  • Application and Design Patterns – одна из наиболее интересных глав, в ней описаны как классические паттерны построения корпоративных приложений ложатся на решения под SharePoint
  • The SharePoint Guidance Library – описание библиотеки со всеми ключевыми возможностями и компонентами для разработки
  • Integrating Line-of-Business Systems – описание интеграции с существующими корпоративными системами
  • Considerations for Content-Driven Applications – здесь можно узнать о том, как правильно строить приложения, для хранения контента
  • Considerations for Enterprise-Scale Applications – рекомендации по созданию приложений масштаба предприятия
  • Considerations for Extranet Development – рекомендации по разработке и планированию экстранет-порталов
  • Partner Portal Reference Implementation – описание построения приложения-примера для MOSS
  • Training Management Reference Implementation– описание построения приложения-примера для WSS
  • QuickStarts – описание приложения для легкого старта работы с SharePoint

Критика

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

Ресурсы по SharePoint Guidance

Скачать полную версию за август 2009 года можно здесь:

SharePoint Guidance так же представлен на CodePlex: http://www.codeplex.com/spg/ здесь можно задать интересующие вопросы и скачать все последние изменения.

Так же некоторые главы из SharePoint Guidance представлены в видеоряде на channel 9:

Ресурсы по SharePoint

TechNet располагает огромным количеством статей и книг по SharePoint, конечно в них не так много внимания уделено именно разработке, однако для формирования вижна платформы весьма полезно: http://technet.microsoft.com/en-us/library/cc262788.aspx

SharePoint Developer Center здесь можно найти практически всё, что нужно для разработки на SharePoint

Октябрь 19, 2009. Метки: , , . .net, Sapphire, patterns & practices, sharepoint. Оставить комментарий.

Ещё раз о SharePoint Guidance

Небольшая заметка, в которой я в очередной раз хотел бы обратить внимание на следующий документ:

sharepoint_guidance[1]

patterns & practices SharePoint Guidance

исключительно рекомендую всем разработчикам SharePoint

А так же вчера на http://channel9.msdn.com/ вышло несколько роликов, о работе с эти проектом:

How to use the logging components? – p & p Developing SharePoint Applications guidance

How to use the configuration component? – p & p Developing SharePoint Applications guidance

How to use the SharePoint Service Locator? – p & p Developing SharePoint Applications guidance

Walkthrough of the Contoso Reference Implementation- p & p Developing SharePoint Applications guidance

Приятного просмотра.

Сентябрь 3, 2009. Метки: , , , . sharepoint. Оставить комментарий.

Сценарии поддержки рабочих процессов для Microsoft SharePoint

Бизнес с готовностью внедряет в своей ИТ-инфраструктуре Microsoft SharePoint по самым разным причинам, однако, большинство клиентов отмечает, что координация бизнес-процессов в этом продукте требует гораздо большей технической квалификации, чем они рассчитывали (чем было обещано рекламой).

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

Microsoft Office SharePoint Server (MOSS) 2007 и Windows SharePoint (WSS) Services 3.0 – лишь два представителя целого ряда продуктов Microsoft, которые поддерживают идеологию «готовых к использованию» бизнес-процессов. С этой концепцией так же работают BizTalk Server, Visio и InfoPath. Многие клиенты, использующие тот или иной вариант SharePoint, отмечают, что использование этих вроде бы «готовых» бизнес-процессов на самом деле требует гораздо больших усилий, чем обещает реклама. Иногда требуется внедрение дополнительных технологий.

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

Модификация без внедрения самостоятельных решений

Существует множество инструментов, позволяющих поддержать автоматизацию рабочих процессов даже в рамках SharePoint. Однако, предприятия не торопятся внедрять их в свои ИТ-инфраструктуры, стремясь ограничить стоимость разработки. Они стараются облегчить себе жизнь при помощи простых в использовании дополнений – шаблонов или заранее сконфигурированных решений. По мнению аналитиков Gartner, модификация ИТ-инфраструктуры при помощи дополнений и расширений гораздо проще, нежели полноценный «культурный сдвиг» в сторону более совершенных инструментов сотрудничества и управления процессами. Дополнив решение от Microsoft, бизнес сможет достигнуть многого, и потенциальная прибыль очень скоро начнет увеличиваться.

Основные преимущества, которые обычно бизнес-аналитики, разработчики и другой нетехнический персонал компаний, ожидает от внедрения проектов в области управления бизнес-процессами (business process management, BPM) на самом деле заключаются в создании культуры бизнес-процессов как таковых. И это ожидание в основном управляет инвестициями в технологию. Оптимизация расходов, упрощение бизнес-процессов, исключение «бумажных технологи» может стать следствием стратегических инвестиций в эти дополнения.

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

Аналитики компании Gartner выделяют несколько сценариев работы с бизнес-процессами для упрощения взаимодействий между людьми, процессами и информационной составляющей. В каждом из них необходимо выбрать тот вариант, который будет наиболее полно отвечать первоначальным требованиям. Рассматривая потенциал SharePoint, бизнес обычно выбирает один или несколько из следующих сценариев:

  • Интеграция или миграция с Lotus на Microsoft;
  • Общая поддержка административных процессов при помощи SharePoint для среднего бизнеса;
  • Фокус на интеграции с системами управления контентом;
  • Предоставление возможности управления процессами нетехническому персоналу.

Эти сценарии и послужили полем для исследований специалистов Gartner. В каждом из случаев была рассмотрена наиболее типичная практика и предложены инструменты для расширения функциональности. Учитывая те ресурсы, которые необходимы для дополнения стандартной версии Microsoft SharePoint функционалом платформы управления процессами, потребуется целый диапазон технологий. При этом некоторые из них будут использоваться мало, и представлять собой скорее тактический ход, а другие же будут применяться наиболее активно, являясь стратегическими.

Сценарий 1. «Простой» переход от IBM Lotus Notes/Domino к SharePoint

Обычно в таком сценарии требуются:

  • Шаблоны
  • Дизайн форм
  • Анализ кода и процессов
  • Моделирование процессов или скрипты
  • Отчеты
  • Расширенный запуск и интеграция

Инструменты, позволяющие улучшить функциональность SharePoint применительно к данному сценарию:

  • Собственные шаблоны Microsoft: Windows Sharepoint Services (WSS), Microsoft Office SharePoint Server (MOSS) и InfoPath.
  • Texcel FormBridge для конвертации некоторых шаблонов Word или PDF в формат InfoPath.
  • Casahl ecKnowledge для преобразования форм Domino к формату InfoPath.
  • Vital Path, Tzunami или Quest для миграции контента.
  • Cerenade или Cardiff для дизайна и обработки форм (если до сих пор для решения этой задачи не используется InfoPath/Forms Server).
  • K2 Blackpoint, Nintex или Open Text/Captaris Workflow для разработки простых приложений, основанных на бизнес-процессах для SharePoint.

Сценарий 2. Широкое административное применение в сфере среднего и крупного бизнеса

Аналитики Gartner предложили несколько самых общих требований, которые выдвигаются к системе управления бизнес-процессами в рамках этого сценария:

  • Простой интерфейс, когда далекий от уровня системного администратора человек может построить бизнес-процесс, пользуясь графической формой.
  • Библиотека шаблонов.
  • Отсутствие необходимости написания скриптов.
  • Быстрая разработка (не более 60 дней на создание и тестирование приложения для работы с бизнес-процессами).
  • Масштабируемость.
  • Возможность создания бизнес-процессов, работающих «над» географически-удаленными точками.
  • Совместимость с существующей архитектурой.
  • Интеграция и совместная работа с with WSS, MOSS, Workflow Foundation, Visio, SQL, BizTalk и Exchange.
  • Простое использование и внесение изменений, когда любой пользователь может доработать или обновить бизнес-процесс.
  • Высокий уровень совместимости; совместимость разработанных приложений с продуктами Microsoft и ее партнеров.
  • Графическая индикация бизнес-процесса.

Кандидатами для работы в рамках данного сценария являются:

  • Ascentn – расширенное средство для работы с простыми бизнес-процессами, предназначено для того, чтобы стать частью сервис-ориентированной архитектуры .NET.
  • CorasWorks – платформа, сфокусированная на пользовательском интерфейсе.
  • Integrify – еще одно средство .NET, отличающееся от указанного выше моделью предоставления услуг.
  • K2 Blackpoint – одно из наиболее бюджетных решений, которое в будущем можно обновить до BPMSuite.
  • Nintex – мощное средство для работы с бизнес-процессами.
  • Open Text – приобретение Captaris Workflow поставило этого производителя достаточно близко к Microsoft.
  • ShareVis – средство с акцентом на формах.
  • Skelta – инструмент для разработчиков и независимых производителей программного обеспечения.
  • Workflowgen – простой и быстрый инструмент (хотя, по своим масштабам он несколько больше, чем Workflow Foundation).

Существуют так же и сугубо региональные решения, не представленные в этом списке.

Сценарий 3. Стратегическая интеграция с существующими системами управления контентом

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

Среди решений в данной категории можно указать:

  • EMC/Documentum – интеграция с другими приложениями обеспечивается за счет веб-партов, которые позволяют пользователям SharePoint напрямую просматривать и взаимодействовать с данными.
  • Hyland – обеспечивает 3 уровня интеграции с Microsoft Office SharePoint Server 2007.
  • IBM/FileNet. FileNet Connector для SharePoint Web Parts расширяет систему управления документами FileNet, делая ее совместимой с SharePoint.
  • Open Text – поддерживает шаблоны, страницы ASP .NET, поиск, архив и т.п. посредством Livelink ECM .NET API.

Сценарий 4. Контроль большой .NET архитектуры на основе бизнес-процессов (доступный не администраторам системы)

В рамках этого сценария аналитики Gartner предложили список из нескольких технологий, которые наиболее полно отвечают задаче создания системы управления бизнес-процессами крупного масштаба:

  • Ascentn AgilePoint – поддерживает полный комплекс продуктов Microsoft, включая BizTalk Server, SharePoint Server, Windows Workflow Foundation, Microsoft Office и Visual Studio.
  • Global360 – партнер компании Microsoft, предлагающий решения на основе MOSS.
  • K2 Blackpearl – решение, построенное на Windows Workflow Foundation и поддерживающее интеграцию с MOSS.
  • Metastorm – один из ведущих партнеров Microsoft в рамках Business Process Alliance. Сильная черта данного продукта – адаптация для нетехнического персонала.
  • Singularity – отличается от других производителей своей концентрацией на процессах, связанных с базой знаний.
  • Ultimus BPM Suite 8.1 – предлагает сильную технологию взаимодействия человека и бизнес-процессов.

Оригинал поста можно найти здесь: http://www.itcontent.ru/archives/blog/sharepoint_add_ons

Подробнее об исследовании Gartner вы можете прочитать на сайте аналитической компании.

Май 19, 2009. Метки: , , , , , , . .net, moss, sharepoint. Оставить комментарий.

Как создать ассоциацию workflow и списка программно

Цель поста

Данный пост призван продемонстрировать как выполнять ассоциацию workflow и списка программно. Workflow может быть стандартной, либо созданным в Visual Studio. Что касается workflow, он будет использовать стандартные списки задач и список истории workflow.

Примеры

Договоримся, что переменная web – это объект SPWeb, содержащий список, который нам необходим для ассоциации с workflow.

1. Объявим переменные, которые будем использовать

  1. SPList myList = null;                              // Лист для ассоциации с workflow
  2. string myListName = null;                          // название нашего спика
  3. SPList historyList = null;                         // список истории workflow
  4. SPList taskList = null;                             // список задач workflow
  5. string workflowTemplateGuid = null;                 // Guid шаблона worklfow
  6. SPWorkflowTemplate workflowTemplate = null;         // шаблон Workflow
  7. SPWorkflowAssociation workflowAssociation = null// ассоциация с workflow
  8. string workflowAssocName = null;                    // имя ассоциации с workflow

* This source code was highlighted with Source Code Highlighter.

2. Инициализация

Убедитесь, что используете internal name списка. И установите имя ассоциации с workflow, он может соответствовать наименованию соответствующего workflow.

  1. myListName = "My list name";
  2. workflowAssocName = "My Workflow";

* This source code was highlighted with Source Code Highlighter.

3. Получить шаблон workflow

Если вы хотите использовать кастомизированный workflow и знаете GUID его шаблона, используйте его.

  1. workflowTemplateGuid = "BAD855B1-32CE-4bf1-A29E-463678304E1A";
  2. workflowTemplate = web.WorkflowTemplates[new Guid(workflowTemplateGuid)];

* This source code was highlighted with Source Code Highlighter.

Так же вы можете получить GUID шаблона, используя метод GetTemplateByName.

  1. // Пытаемся получить список истории workflow
  2. try
  3. {
  4.      historyList = web.Lists["Workflow History"];
  5. }
  6. catch (ArgumentException exc)
  7. {
  8.      // Создаем список истории workflow
  9.      Guid listGuid = web.Lists.Add("Workflow History", "", SPListTemplateType.WorkflowHistory);
  10.      historyList = web.Lists[listGuid];
  11.      historyList.Hidden = true;
  12.      historyList.Update();
  13. }

* This source code was highlighted with Source Code Highlighter.

4. Получить, либо создать списки истории и задач workflow.

Список истории, используемый workflow, должен быть унаследован от шаблона списка WorkflowHistory. В большинстве случаев вам не понадобиться его создавать.

  1. workflowTemplate = web.WorkflowTemplates.GetTemplateByName(        "Template name",        System.Globalization.CultureInfo.CurrentCulture);

* This source code was highlighted with Source Code Highlighter.

Список задач – это обычный список, унаследованный от шаблона списка задач. Если вы хотите создать специфичный список задач для workflow, не стоит называть его “Задачи” (“Tasks”). R примеру мы можем назвать его “Задачи рабочего процесса” (“Workflow tasks”).

  1. // Пытаемся получить список задач для workflow
  2. try
  3. {
  4.      taskList = web.Lists["Workflow Tasks"];
  5. }
  6. catch (ArgumentException exc)
  7. {
  8.      // Создаём список задач для workflow
  9.      Guid listGuid = web.Lists.Add("Workflow Tasks", "", SPListTemplateType.Tasks);
  10.      taskList = web.Lists[listGuid];
  11.      taskList.Hidden = true;
  12.      taskList.Update();
  13. }

* This source code was highlighted with Source Code Highlighter.

5. Создаем ассоциацию с workflow, конфигурируем её и привязываем к списку.

  1. // Включаем небезопасные обновления для узла (web)
  2. web.AllowUnsafeUpdates = true;
  3. try
  4. {
  5.         // Создаем ассоциацию workflow
  6.         workflowAssociation = SPWorkflowAssociation.CreateListAssociation(                workflowTemplate,                workflowAssocName, taskList, historyList);
  7.  
  8.         // Устанавливаем параметры workflow
  9.         workflowAssociation.AllowManual = false;
  10.         workflowAssociation.AutoStartCreate = true;
  11.         workflowAssociation.AutoStartChange = false;
  12.  
  13.         // Связываем workflow со списком
  14.         myList.AddWorkflowAssociation(workflowAssociation);
  15.  
  16.         // Активируем ассоциацию
  17.         workflowAssociation.Enabled = true;
  18. }
  19. finally
  20. {
  21.         web.AllowUnsafeUpdates = false;
  22. }

* This source code was highlighted with Source Code Highlighter.

Источник

Данная статья является переводом данного поста:

http://blogs.prexens.com/Lists/Posts/Post.aspx?List=7a299699-f8da-4559-920c-bda481608691&ID=9

Май 15, 2009. Метки: , , , , . .net, C#, Workflow, sharepoint. Оставить комментарий.

SharePoint (WSS 3.0 & MOSS 2007) SDK Updated April 2009 (v1.5)

Вышло апрельское (April 2009 refresh v1.5) обновление SDK of the Windows SharePoint Services 3.0 & Office SharePoint Server 2007.

Апрель 26, 2009. Метки: , , , . sharepoint. Оставить комментарий.

Рассуждения о производительности объектной модели SharePoint

Введение

img13[1] Основными сущностями, с которыми приходится работать в рамках объектной модели SharePoint являются списки (SPList). Поэтому, считаю, что необходимо, в очередной раз, сделать акцент на способах работы с ними. Поэтому, если вас беспокоят такие вопросы, как:

  • Получение количества строк в списке
  • Получение значений записей в списках
  • Использование запросов (SPQuery) и представлений (SPView)
  • Пейджинг (постраничное разбиение) (довольно-таки не тривиальная реализация, поверьте)
  • Обновление большого числа записей
  • Обнаружение “медленных” списков

прошу прочесть, внимательно, данный текст:

http://www.infoq.com/articles/SharePoint-Andreas-Grabner

img5[1]

Март 12, 2009. Метки: , , , , , , , , , , , , , . .net, sharepoint, visual studio, web. 1 комментарий.

SPBuiltInFieldId – сделает жизнь проще

Наверное многие из вас (Sharepoint разработчиков) нередко путались в дебрях имён полей (SPField) и путали internal, display и прочие их типы.

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

Пользуйтесь на здоровье!

P.S. Так же есть класс SPBuiltInContentTypeId – перечисление встроенных guid контент-типов, что так же полезно.

Февраль 18, 2009. Метки: , , , , , . sharepoint. Оставить комментарий.

Релиз SharePoint Dispose Check 1.3.1 состоялся сегодня!

Введение

Наверное все помнят нашумевший dispose best practices article in the SDK, после которого подход к работе с объектами sharepoint немного изменился. Сегодня увидел свет инструмент, позволяющий проверить насколько правильно вы работаете с практиками утилизации объектов.

Описание

Использовать утилиту очень просто:

SPDisposeCheck <путь к сборкам> -debug –xml <файл отчёта>

Материалы

Скачать утилиту можно по адресу http://code.msdn.microsoft.com/SPDisposeCheck

Январь 30, 2009. Метки: , , , , . .net, sharepoint. Оставить комментарий.

Следующая страница »