iscrafmМежду собой сервисы взаимодействуют при помощи своих интерфейсов. Приложение SAP строится путем обращения в определенной последовательности к тем или иным транзакциям, обеспечивая тем самым реализацию бизнес-логики.
В отсутствии такой единой "шины" в 1С, к примеру, одна из основных причин невозможности объединения различных конфигураций в единое целое
вы так ничего и не поняли. кому нужна мифическая шина в САП, если она не может позволить мне, как полевому агенту, имеющему Nokia N73 или наладонник с windows mobile, создать в базе контрагента, которого я только что посетил. и не надо мне говорить, что агенту это не нужно, что это надо делать в офисе и т.п.

шина/сервисы на базе транзакций в САП -- явление того же порядка, что и АБАП - есть 4ГЛ. в системе аксиом Мармелада (4ГЛ - это то, что выросло из SQL) может его и можно назвать 4ГЛ, в вашей системе аксиом (бизнес процесс надо программировать пакетным вводом через заполнение экранов ввода, как в САП) САП суть SOA... но легче от этого никому не стало: на САП очень долго делать настройку на клиента, САП очень медленно работает, с САПом очень сложно организовать взаимодействие внешних систем. ваши системы аксиом не имеют практической ценности

ЗЫ в 1С 8 шина есть, хошь через сервисы (по-взрослому, с xml, wsdl, и т.п.), хошь через слой бизнес правил и объектов, и до этой шины САПу (даже в реинкарнации XI+IDOC) как до луны пешком

Mr Marmeladинтерпретатор pl\sql и есть 4GL
в реализации оракл до сих пор процедурная часть и реляционая часть -- суть разные части, и передача объекта (в самом общем смысле) из одной части в другую -- пересекает границу контекста. т.е. примерно так же, как в VB производится обращение к базе через ADO. в этом смысле АБАП или tsql куда более 4ГЛ, ибо там это все бесшовно

iscrafmто в чем проблема из двух конфигураций сделать одну?
ни в чем наверное. из каких двух конфигураций надо сделать одну? т.е. написать отдельно склад (ММ), отдельно сбыт (SD), отдельно бухгалтерию (FI) и обмениваться данными между ними? написать на 1С 8 можно без проблем, наверное даже уже написано (не в типовых)

если вы именно это имеете в виду, то в таком подходе есть много больших проблем и нестыковок:

- в САПе подсистемы обмениваются данными и через транзакции (см ниже), и через БД и вызовы фм-ок, специально для этого написанных. бывает, что и через пакетный ввод (особенно в FI любят постить проводки через fb05). причем чем новее разработка/заплатка, тем больше вероятность, что через ФМ, ибо вызов через транзакцию -- очень медленно, времяемко (пока все нужные и ненужные поля заполнишь), чревато сбоями в самых неподходящих местах (кто-то на экране поле сделал невизимым либо закрытым для ввода -- и все перестает работать) и невозможно гарантировать атомарность (пример я приводил выше)

- невозможно установить SD на одну систему, а MM на другую. вызов транзакции невозможен между инстансами - ни о какой шине речи тут не идет.

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

- изменения надо вносить в миллион разных мест: в поставку (SD), в отпуск материала (ММ), в счет фактуру SD, в счет фактуру (FI), в проводку FI, в документ выравнивание (FI) - очень времяемко

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

уважаемый Мармелад, мы с вами уже выяснили все отношения. честно говоря, экскурс в историю мне не интересен (я сам могу много чего рассказать про PL/1, перфокарты и JCL), к текущей ситуации это никакого отношения не имеет, а ваше "Вот здесь уже начинается понимание.." просто неприятно. не обижайтесь, но неагировать на ваши высказывания я больше не буду

это сделано не через транзакции и "шину", чтобы это ни значило, а через MI, LE_DSD и его /dsd/bapi_*

посмотрел повнимательнее - это даже не LE_DSD, всего навсего доступ на портал, картинки заранее приготовленных отчетов смотреть

собственно мысль не в этом. у САП есть несколько решений, работающих с мобильным фронт-ендом, но только никаким "сервисами" там и не пахнет. мобильная инфраструктура (MI) работает только с САП-овской мобильной частью. сервис с одним потребителем... -- у меня в таком случае все программы сервисные - потребляют объекты и процедуры, написанные для того, чтобы их потребляли внутри программы

к САПу можно прикрутить сторонние мобильные решения, но так же, как и любая другая прикрутка к САПу - долго, дорого и медленно работает. и никаким транзакциями там даже близко не пахнет: бапи, idoc-и и XI

iscrafmПонимаете САП, если вы бухгалтер, то не стоит ввязываться в вопросы архитектуры
я уже писал кто я, какой у меня background, и сколько систем я спроектировал

а про вас у меня очень большие сомнения (применительно к САПу), xd03 назвать отчетом... -- сдается мне, что иконка у вас ведет в IDES или какую-то подобную песочницу и никакого реального САПа вы никогда не видели. с теоретиками вести дискуссию плодотворно невозможно, а вы пока что никакого реального примера, кроме повторов кем-то сделанных маркетинговых высказываний не привели

iscrafmа то так и буду в неведении с кем пообщался.
да тут и писал, только модератор, похоже, стер
так даже лучше, пусть буду анонимом

AlexsalogRAD не рассмативаем
я могу попробовать осветить вам часть вопросов в обмен на обещание сказать, почему RAD не рассматриваем.