Здравствуйте.

Я вэб разработчик. У нас разгорелся спор с 1с программистом. Хочу чтобы вы рассудили кто не прав.

Задача такая : 1с должна получать заказы из интернет магазина максимально быстро, насколько это возможно.
Я реализовал у себя GET метод по получению заказов. Пусть обращается так часто как хочет. Хоть раз в 20 сек.

1сник настаивает что я ему должен передавать заказ на его HTTP сервис. Если не полностью (что я точно не буду делать) то хотя бы id заказа.
Для этого на своей стороне организовать очередь, на случай если HTTP сервис 1с не отвечает.
И что с его стороны опрашивать мой сервер каждые 20 секунд это тупо.

Я посмотрел как работает апи гугл мапс. Там клиенты постоянно опрашивает сервер, а не сервер рассылает уведомления клиентам. Но для 1с-ника это не аргумент.

Как его убедить?

Выпейте с ним пива и сделайте обмен через файлы на фтп )))))

(1) по электропочте! какое фтп, ты чо

а вообще, позовите третьего, который будет перекладывать раз в 20 секунд от тебя к нему.
Все приделе и спору нет

такой третий называется шина преприятия

(1) (2) :) почта рф рулит

Прав ваш непосредственный руководитель. Они у вас разные?

(0) одинесник не прав - пусть курит типовой обмен CML

+ (7) ну а так конечно (6)

(7) В CML так организовано потому что этот формат еще мамонтов застал. Это даже нельзя назвать АПИ, когда куча файлов архивируется, передается серверу и сервер там с ними что-то шаманит.

Напишите скрипт, который будет дёргать сайт, а потом - дёргать 1С, если есть с чем.
Киньте его в крон и пейте пиво.

(9) апи это программыйирнтерфейс вы тут этого не увидели?  я не про  cml конкретно - в 99% одинэс дергает сайт ибо когда говоришь "а вот напишу в 1с вебсервис, пересчитывающий корзину по персценам" - вебпрогер профвебстудии закатывает глаза и мычит "ну это очень сложно и ввобще невозможно..."

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

(0) а как скидки планируете получать и рассчитывать?

(13) может быть и так что клиент должен до того как положит в корзину хочет видеть цену со скидкой. Еще интнреснее когда это b2b система и нужно скидки выгружать для каждого клиента отдельно на 100500 товаров. В крайний раз пришлось выгружать все скидки и на сайте уже считать

(0) Зависит от задачи.
Если, например, есть задача при нажатии на сайте на кнопку "заказать" и чтобы тут же были показаны позиции, по которым нет остатка, то сайт должен обращаться к 1С.
Если все совсем упрощено, то делайте у кого будет меньше трудозатрат.
Третий вариант: прав тот, у кого больше прав))).

У вас стоит задача максимально быстро. Если руководство не поставило какое время их устраивает, то получается 1сник прав. Сайт должен начинать обмен или хотя бы сообщать, о том, что у него нужно забрать данные. Это самый быстрый вариант получения заказа с сайта в 1с.
И про очередь прав. Сайт как источник данных должен понимать, что 1С в итоге получила, а что нет.

Стучаться раз в 20 секунд это избыточность.

ИМХО, 1С-ник прав. Ибо событие (новый заказ) генерирует сайт и логично в этот момент стучать в 1С. Так просто более изящно :) А так, второй вариант тоже рабочий, но 20 сек - это слишком часто.
Кстати, как реализуется при взаимодействии интернет-магазина и 1С (УТ11.4) обмен сущностями Партнер (Покупатель) и Контрагент (Плательщик). К примеру, в УТ заведены несколько торговых точек одной сети магазинов, а контрагент у них 1 - головной офис. Важно, чтобы при поступлении заказов с сайта эта структура не изменилась.
Такое только Битрикс поддерживает или есть и другие хорошие движки? Что вообще лучше для небольшого (3000 SKU) B2B магазина?

" ему должен передавать заказ на его HTTP сервис. Если не полностью (что я точно не буду делать)"

http://alphachan.org/art/src/133209252848.jpg

(17) обмен сущностями контрагент-партнер никак в связке ут11-битрикс не реализовано. Это вам не б2б система а интернет магаз. Но битрикс поддерживает загрузку в себя любых справочных данных - см references.xml но и разумеется кодинг нужен в битрикс в этом случае.

(0) а что тут обсуждать у вас фронт у 1с Бэк.
Бэк опрашивает фронт

Просто 1с не хочет просить ...:)

парсить

(20) Вообще-то событие возникает на фронте. Поэтому он и должен оповещать бек об этом.

(20) Наоборот

(23) разные системы . Никто ничего не знает. Первичка
Где то . Табличка не опрошена бэком.фидбэк не отправлен.

(25) Шта?

1Сник всегда прав.

(26) не терпится в (0) 1с ку свою базу
Опубликовать :) хотя в (0) уже есть веб ресурс в виде прога
специализированного. Он кучу сервисов напишет . Знай
Дергай регламентом в 1с и проблем нет

(0) Да пофигу, у меня и так и эта есть решения.
Это на уровне ТЗ обычно решается.

(29) а потом в тз напишут штааа неплохо бы третью базу прикрутить  в виде шины :) и туды данные складывать

(0) Тут нет понятия "прав/не прав". Как договоритесь - так и будет.

(28) АГа. Ну и сделает 1с ник дёргание раз в сутки....

(32) это как расписание дёрганий настроить да и это вопрос не технический. Доступность сервисов скорость отдачи и т.д это уже не головняк 1с

а вот например в яндекс-афише - яндекс сам кидает заказ в базу клиента.

(33) "это уже не головняк 1с".
С этого нужно было начинать. Потому что именно этот головняк завалит (может завалить) всю систему.

ЗЫ Согласен с (23).

(35) головняк не начнётся когда сервисы 1с поведут
Себя таким же образом :)

+(36) только это будут уже проблемсы 1с ка а веб прогер скажет ... это же ваш сервис
И будет прав

(36) "сервисы 1с" не должны себя никак вести. До получения оповещения от фронта.
Фронт должен оповестить бек. Любым доступным способом. Дернуть сервис, отправить оповещение, отправить мыло наконец. После этого 1с должна начать сеанс обмена. До получения оповещения от фронта дергать обмен нет никакого смысла.

(38) даже потыкать в него палочкой не нуна?

+ (38) А тем более с периодом в 20 сек. Как предлагает ТС. Вряд ли транзакция обмена может уложиться в это время. Заддосите сайт своими же запросами.

(39) Чем в твоём понимании " потыкать в него палочкой " отличается от "Дернуть сервис"?

(39) Зависит от того что хотите получить от "тыканья палочкой". Если на сайте нет ничего (или он занят обменом с 1С) - что хотите получить от "тыканья"?

Если стоит задача максимально быстро передавать заказы, то логично сразу в момент поступления заказа выгружать его в 1С, таким образом и заказы сразу будут появляться в 1С, и системы не будут перегружены частыми порожняковыми запросами (когда заказов нет).
Так что 1С-ник правильно вам сказал, учитесь работать с http сервисами :)

(41) отличить сайт лежит от тот балбес запрос поломал

(44) Ты этта... Кофейку выпьей, что-ли... А то твоё бормотание становится всё более невнятным.

(0) в общем соглашайся с 1ком . При каждом недоступном сеансе сервиса онлайн - выводи Алерт на форму .Внезависимости о времени суток . И работы тебе меньше . Снимаешь с себя все.

(44) Ну... это видимо да. Только это не связано с собственно обменом заказами.

(47) это отличяает хуякхуяк и в продакшен от остальных подходов

(46) И это правильно. Клиент (тело, в браузере которого открыт сайт) ни в чем не виноват. И должен знать, что его заказ по каким-то причинам обработан не будет.

(0) У нас 2 интернет-магазина на 1с-битрикс, обмены с 1с имеются.
Могу сказать так, что в вашем случае пофигу кто сервер, кто клиент.

Но в обработке обмена, которую я скачал и внедрил с сайта 1с-битрикс, в 1с запускается регламентное задание, которое с какой-то периодичностью опрашивает сайт.

Галка эта называется "Используется в режиме реального времени".
Скрин из 1с:
https://yadi.sk/i/cVITqI_39iFp6g

+ (49) И кстати да - "Внезависимости о времени суток"

(49) я бы сразу написал в чат о недоступности сервиса

или 1ску а час или два ночи

(46) Быдлокод. Если сервис недоступен, заказ должен быть принят и поставлен в очередь. При возникновении доступности - накопленная очередь отправляется.

(50) Это не "реальное время"

(55) Согласен, но поставить можно 30 секунд, это в округлении можно считать в реальном времени ))

(54) уже очередь

Если обмен синхронный (по расписанию), то монопенисуально кто его инициирует. Если асинхронный, то запускает обмен сторона, на которой произошло событие.

(54) а когда сервис то будет доступен ? 1с ник знает ?

(59) Это не важно. По истечение таймаута возращается фатальная ашипка, либо в конец очереди скидывается.

(60) т..е заказы есть и как бы их нет :(

(59) Я по своей природной тупости не могу понять. Какая разница в какой из схем работы накроется 1С?
Кто будет опрашивать сайт, если накроется 1С. Скажем в "час или два ночи" ЦЫ(53)

(61) Почему? В очереди может быть не один заказ. Если за время тайм-аута заказ не обработан, значит что-то "неладно в королевстве датском". Нужно разбираться с сервисом.

Тогда по почте екселем или тексовиком

(0)(50) Это я к тому написал, если автор хочет победить в споре.
То может смело тыкать пальцем в 1с-битрекс.
Типа если сам 1с-битрикс сделал, что 1с это клиент, то не нужно изобретать велосипед )))

(0) 1с ник прав. вы явлеетесь "автором" документов. ваша задача их отдать на обмен

(0) ещё плюс . Разбираться уже не тебе .

можно представить что будет "шина обмена". тогда никто опрашивать ваш веб-сервис не сможет

(68) уже было . Выше

(67) Типа если 1с должна опрашивать сайт но не делает этого - разбираться веб-прогеру?

(70) конечно, первый заказ будет через пятилетку, как понять что оно работает?)

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

(71) Подожди. Мне нужен ответ от rsv

(70) почему не сработал регламент вызова сервиса
Магазина- разбираться одноэснику

Есть 4 варианта:
- событийный пост ("пуш")
- событийный гет
- регулярный (в большинстве времени холостой) пост ("пуш")
- регулярный (холостой) гет

Вообще ИМХО правильный ответ ТС-у дан в (23). Потом пошла пурга в стиле "а я еще могу вот так".

почему не сработал сервис магазина - разбираться спец ресурсу разработчика сервиса магазина

(75) Событийная модель конечно же иделогически более правильная и универсальная, но не всегда выбор обусловлен этой технической правильностью.
Иногда тупо сроком / удобством / стоимостью разработки. Какие-нибудь жаберы-ораклисты будут 2 месяца одну только очередь отправки реализовывать, чтоб отправляемые заказы никогда не терялись. А в 1С это сделать 2 часа.

(77) И это как-то зависит от схемы обмена?
1. как обработать исключение, когда 1С должна опрашивать сайт, но не делает этого.
2. как обработать исключение, когда сайт не смог дернуть веб-сервис на стороне 1с.
Кому в каком случае разбираться? В каком случае ситуацию спасут звонки 1с-нику в час ночи, а в каком не спасут?

(78) Техусловия ТС описал достаточно доступно для понимания : "Я посмотрел как работает апи гугл мапс."

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

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

(79)  в понимании того что фронт этот независимая безуха с формами . Ее задача положить в табличку что то что напечатать возможно денежку взять чере он Лайн. На ней в (0) спец ресурс. Он пишет к ней доступ в виде сервисов и сопровождаете веб сервисы и сервер веб и базу свою

Чем это дергается - хоть VB

(0) вопрос то у вас, кто будет делать, а не как быстрее)

(14) дублировать логику расчета скидоки/наценок

?

1с ник до ничего не разворачивает в виде веб-сервера и сервисов ..берет мануал и пишет функционал обращения к сторонним сервисам

(83) ЯННП.
Кто все-таки кого должен опрашивать? И кто будет обрабатывать исключительную ситуацию "опрос не прошел"? Не "обмен", а именно "опрос"?
Могу ошибаться, но понял так, по-вашему :
- в случае "опрашивает 1С" - решает веб-разработчик.
- в случае "оповещает сайт" - решает 1с-ник?

(0)Зачем воду в решете носить и постоянно бегать спрашивать?
у тебя появился заказ ты и отправляй. В данном случае 1с Сервет

(88) вы все поняли .я написал выше / если не сработал регламент вызова движка один эс- разбираться 1ску . если сервис генерит ошибку - тот кто его написал.

(89) Тоже не совсем правильно. Не "ты и отправляй", а "ты оповести, что есть что отправить". А уже забирает пускай 1С.

1С-ник прав! Всегда надо идти от события - кто его инициализирует - тот кто жмет кнопки на сайте, значит как кнопка нажата будь добр отправить данные. А опрашивать да еще и каждые 20 сек совсем не правильно ИМХО.

(0)Почему вы решили , что вы "гугл мапс"? К вам туева хуча 1с обращается?  Мне думается, вы оба клиенты "колхозные", а не гугель.

Опрашивать будет бэк т.е 1с .

(88) Чтобы не вашим и не нашим, скидывай файл с заказом в папку, и пусть 1С сама определяет как часто ей папку мониторить

голосуем товарищи

Ибо нефик.

Событие на фронте - оно инициатор

Ест-но

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