Настроить "План обмена" на отправку у вас не получится - это, грубо говоря, таблица для регистрации свежих изменений по отслеживаемым объектам в системе в целях уменьшения объема синхронизации. Хотя его событийная модель позволяет при регистрации делать еще какие-то другие действия. Можно их сразу же отправлять (или по заполнению некоторого буфера) на ваш веб-сервис и при получении подтверждения делать очистку. Получается альтернатива подписке на события только с приятным бонусом - в подписке вы знаете только про объект, который инициировал событие, а тут с помощью специальной обработки можно самому регистрировать произвольные объекты для "ручной выгрузки". Обработка регистрации встроена в большинство конфигураций, а для самописок ее можно взять с диска/сайта ИТС.
Все зависит от целей. Обычно создают константы. Если внешних приемников несколько и каждый со своими настройками, то создают справочник с настройками. Если нет желания, что бы какой-то хитрый манагер полез консолью отчетов в базу и узнал все пароли, то или прописывают прямо в коде (но это не гибко, так как при изменении пароля нужно код менять), или хранят в настройках пользователя, под которым проходит обмен.
Андрей: План обмена позволяет описать внешние по отношению к текущей базе 1С сущности. Это могут быть базы филиалов, или мобильные устройства сотрудников или сайт. При создании плана обмена указываются виды данных, которыми предполагается обмениваться. Далее при внесении изменений в каком-то справочнике (в тех же сотрудниках), этот элемент регистрируется на отправку в узлы (экземпляры данного плана обмена). Потом при обмене с конкретным узлом все объекты, которые зарегистрированы на отправку в него будут выгружены в XML-файл, а в свойствах узла счетчик выгруженных пакетов увеличиться на единичку. Если в рамках обмена приходит "квитанция о получении", то регистрация элементов в узле очищается (кроме тех, которые зарегистрировались между отправкой и получением обратного ответа); если обратной связи не было, то данные считаются потерянными в пути и при последующем обмене выполняется новая попытка их выгрузить.
Это стандартный механизм, которым можно пользоваться сразу же после создания в конфигураторе нового плана обмена. Если применить фантазию и навыки программирования, то можно сделать много чего полезного. К примеру, регистрировать не всех сотрудников для отправки в удаленный филиал, а только тех, которые работают в этом филиале и руководство компании; для отправки на сайт регистрировать только те товары, которыми предполагается он-лайн торговля (а вовсе не запчасти, бензин, бумагу для принтеров и прочие расходники ежедневной деятельности). Так же достаточно использовать узлы плана обмена в качестве регистратора изменений, а сами пакеты на отправку и получение формировать своими силами - это позволит отойти от XML-файликов к другим каналам коммуникации - к примеру, к отправке по веб-сервису файлов JSON.
agent1156: вы же в курсе, что 1С бесплатно раздает в учебных целях платформу для самостоятельного изучения вместе с учебной литературой и демонстрационными материалами? Начните от сюда - https://online.1c.ru/catalog/free/learning.php
ASDF13: обманчивый тренд, но выбор делать только вам.
У 1С есть еще большой запас для роста и ниши из которых она будет вытрясать конкурентов - в конце конов это не просто язык или платформа, но еще и целая экосистема. А какие перспективы для распространения PHP помимо занятых ниш? А на ноги наступают erlang, go и прочие серверные языки, не говоря про моностек JavaScript с их серверным движком Node.js
Дмитрий: менее болезненным будет выбрать то, что знаете. Если не знаете обе системы, то поставьте демо-базы и просто прощелкайте документы и отчеты. УТ10 более похожа на торговые решения 7.7, но УТ11 более функциональная и именно она будет развиваться (для УТ10 будут только делать косметические правки под изменения законодательства).
АртемЪ: т.е. ваше предложение в поднятии в локалке своего NS-сервера, который бы по имени интернет шлюза (1cserver.rogaIkoputa.ru) направлял бы на адрес реального сервера 1С в локалке? Это действительно удобнее чем делать записи в hosts на компах клиентов, но при наличии других сервисов в сети, которые находятся на других компьютерах локалки может привести к другим проблемам админу (собственно из-за этого мы даже не стали думать в таком направлении, а еще у нас доменное имя изменялось). Но в целом, идея хорошая :)
АртемЪ: не совсем понял как может помочь редактирование DNS, что бы с любой точки интернета попасть по netbios-имени либо по локальному айпишнику (в зависимости от настроек главного узла кластера) на шлюзовый сервер, который светит в интернет.
АртемЪ: условно работает, но далеко не "прекрасно"!
Сервер передает свое имя для колбека и когда кто-то из интернета пытается подключится к условному серверу 1c.server.com , где настроен форвардинг портов 15** на сервера Server1C в его локальной сети, то выдается ошибка "Server1C не найден". Разве что каждому из клиентов прописать в файле hosts названию Server1C ай-пишник сервера, который светит в интернет - то такой путь действительно работает, но мы отказались от этой идеи, так как админить домашние компы удаленных сотрудников очень сложно и проще пустить через remoteApp.
Для начала какая у вас конфигурация? ERP, УНФ, УТ11, или что-то другое заточенное под веб? Или какая-то самописка под неуправляемый интерфейс, которую вы хотите заставить работать в вебе? В первых случаях все работает из коробки при наличии прав. Во втором случае вам для работы нужно будет создать недостающие формы.
SyavaSyava: в таком случае вам будет интересна статья, которую я держу в закладках на случай необходимости работы с MsSQL - infostart.ru/public/574078
На счет Линукса, то это было мое личное мнение. Я больше программист, а не сисадмин. Знаю только то, что нашел и изучил в открытом доступе, а по линуксовым серверам инфы на порядки больше чем про настройки виндузных корпоративных сетей и магии использования PowerShell. Я даже банально зависший процесс иногда не могу снять и не понятно что там вообще происходит, в то время как линуксовый килл справляется с такой проблемой за мгновения.
АртемЪ: давайте без холиваров. Обе системы уже давно обкатаны и могут эффективно использоваться в продакшене. Выбор зависит уже давно не от стоимости покупки, а от стоимости владения (зарплаты специалистам сопровождения). Если найти опытного DBA, то любая из этих систем (уже не говорю про Oracle и IBM) будет превосходно летать с сотнями пользователей. А вот если админ мануалы не читает, по курсам повышения квалификации не ходит и свято верит в силу настроек по-умолчанию, то тут MsSQL до некоторого порога будет давать жару постгре. Но 500 пользователей - это уже намного выше этого порога.
"Ничего нового я не планировал услышать." - тогда зачем вообще написали этот вопрос? Вам стороннее мнение вообще интересно?
---
Вот вы отметили как гениальную мысль, что доступ к вашей бухгалтерской базе по удаленке могут получить новенькие сотрудники и это ужасно плохо. Т.е. вы искренне считаете, что запрет подключится по удаленке помешает руководству отправить этих же сотрудников напрямик в ваш офис, где они могут совершить те же самые диструктивные действия? Или можете ли вы гарантировать что ваш подрядчик уведомит вас об увольнении своего сотрудника, который наделал пакостей, а ваша бухгалтерша по привычке не позвонит ему на мобильный с просьбой приехать и "все починить" - а ему только и нужно насолить своей старой конторе и он с радостью совершит любые новые злонамеренные действия?
---
В общем мое мнение вы услышали. Вам предлагают оперативность и повышения контроля с вашей стороны, а вы выступаете за неуправляемость и за повышение рисков получить убытки от простоя учетной системы. Ваше право.