Добрый день, коллеги!
Есть необходимость в интеграции SAP и Microsoft TFS (Team Foundation Server). Интеграция состоит в передаче информации о проектах, задачах и пр. связанной информации в TFS. Т.е. к примеру я реализую Enhancement или пишу новую программу, мне для этого нужно чтобы кто-то (или я сам) предварительно создал транспорт, который я смогу использовать, я указываю название проекта, потом в рамках проекта можно создавать различные таски (Request/Task). Вопрос в том, как передать (или вытащить) эту информацию для использования в TFS. Хотелось бы также получать всю связанную информацию т.е. Target system, Source client, Owner, Status, Documentation[], и пр. Пока на ум приходит использование сервисов и BAPI, нарыл к примеру BAPI_CTREQUEST_CREATE - для создания запроса с тасками... в принципе BAPI можно оформить в виде сервиса и запостить на Gateway. В принципе эта BAPI пригодится если мне нужно будет создать запрос из TFS, а где к примеру можн посмотреть полный список BAPI (для извлечения информации по проектам, проект по Id, получить таску по Id проета и пр.)? Какие есть еще варианты реализации подобной интеграции?
И еще один вопрос - данный вариант с BAPI относится в SAP Business Suite, но будет ли тоже-самое (такой-же подход) работать и для SAP Business One, SAP Business by Design??? Где можно посмотреть централизованно сравнительные технические особенности этих систем или они все равноценно поддерживают сервисную архитектуру и набор BAPI?

Проекты в SAP это очень навороченная сущность. Не видел пока чтобы их правильно и главное с профитом для себя где то реализовали...

А вы что пытаетесь добиться, чтобы транспорты можно было только во внешней системе создать? Или просто хотите свой ZSOLMAN?

Я понимаю, таких наворотов в SAP полно, еще не видел чтобы что-то было легко реализовать. Конечный продукт должен быть своего рода трекинг/мониторинг системой (как солман), но с возможностью создавать проекты и таски извне. И наоборот, если я создаю проект в SAP с набором тасок, чтобы он был виден в TFS. Раньше для связки мы использовади поле "описание" и вкладку "документация" для вставки ID проект и пр. служебной информации, но потом возникает проблема с матчингом этих Id с тем что в TFS. В общем - нормальным решением является интеграция, вопрос только в том, если ли уже задел в виде BAPI или сервисов которые можно использовать и придется пилить свое.

Если у вас TFS это корпоративное, то ищите бюджет и интегратора (есть адаптеры и прочая фигня). Если вы просто с нуля его выбрали, то почему не взять SOLMAN...

А так это просто поиграться.

Хороший ответ, можно сразу приступать к интеграции, ведь про возможные варианты уже все известно

Сделайте на стороне SAP web-сервис для работы с проектами и вызывайте его из TFS.
По поводу методов - трассировку с помощью ST05 никто не отменял - посмотрите, какие таблицы читаются при визуальном вызове транзакций в SAP, поставьте точку останова в коде при чтении из таблицы и посмотрите по стеку вызовов, какие ФМ/методы вызываются.
Зачем еще и Gateway - непонятно...

Это потому что вы SAP плохо знаете

Спасибо за полезный совет, сервисы пожалуй это один из (если не единственный) нормальный вариант интеграции. FM нарыл уже без ST05.

Ну, у многих компаний своего рода пунктик по этому поводу - так получается более секьюрно (вроде как). С другой стороны позволяет использовать REST.

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

По большому счету возможности интеграции SAP с чем бы то ни было ограничиваются всего лишь тремя возможностями: файл, RFC или web service. В последние годы при возможности пользуются последним (по понятным причинам).

Но в вашем случае, честно говоря, не совсем понятно для чего такая интеграция нужна. Следить за тем кто что в SAP делает - для этого внутри SAP есть средства. Информация об SAP транспорте IMHO мало что скажет какому-то пользователю MS продукта, не знакомому с SAP. В чем конечная цель этого геморроя, простите, интеграции?

Речь о продуктах на платформе Netweaver. Большая часть из этих продуктов имеет более-менее нормальные программные API, кроме самых старых. Все остальное - не SAP

Для безопасности используют web-диспетчер, ограничение ролей пользователя сервиса и последние патчи по безопасности.
И чем вам POST не угодил?

Контроль разработок в гетерогенной среде. Есть Solution Manager, но он громоздок и имеет не самый удобный интерфейс.
У нас сейчас подобная задача в планах, но контроль разработок будет со стороны SAP

Да, так и есть, я уже накопал все что нужно было, осталось "всего лишь" оформить в виде сервисов )

Сам я работаю с SAP PI в основном и знание этого компонента хорошо проясняет как все работает. Мы с вами видимо в разных школах учились, но NetWeaver это технологическая платформа - основание для создания (как у нас принято говорить "решений") ака "продуктов" (SD, FI, SCM, SRM etc.). Информационная (CIM) модель заложенная в основе четко разделяет что такое продукт, что такое программный компонент и как они версионируются.
Даже если принимать во внимание только NetWeaver, обычно специализирутся на чем-то одном, BI/BO, PI, Webdynpro, и пр., поэтому, как говорил Станиславский - "Не верю", как говорится "все всего не знают"


TFS хавает REST, сервисы общаются через SOAP. Логично было бы сразу оформить их как REST что они общались на "одном языке".
[/quote]

Мой совет - вот как только сможете установить "продукт" SD в систему SAP BI, работающую на платформе NetWeaver, так сразу же и приступайте к лекциям по решениям SAP для населения. А пока, с таким пониманием, прямая дорога в советники президента по интернету. Ну или в Госудуму.

В SAP не дураки сидят. Там в маркетинге больше людей чем у многих интеграторов в разработке. Это у начинающих часто первое впечатление - если код открыт, то я ща быстро тут все допилю под себя. Если б все было бы так просто, ни кто бы не покупал SOLMAN и прочие побочные продукты.