Вход | Регистрация

  1  2  3  4  5  6  7  8  9  10  11   
Работа :: Вакансии

Требуются программисты и консультанты 1С 8 (Москва, 500 - 1200 рублей в час)

Ø [длинная ветка, 20.06.18 - 16:32]
Требуются программисты и консультанты 1С 8 (Москва, 500 - 1200 рублей в час)
Я
   KrisbitYA
 
18.05.18 - 10:29
4. Не, не хочется92% (11)
3. Вызываю самолет8% (1)
1. Бегу0% (0)
2. Лечу0% (0)
Всего мнений: 12

Савеловскому офису компании Первый БИТ нужны программисты и консультанты по восьмерке.

Требования к кандидату:
- Знание предметных областей
- Знание типовых продуктов 1С

Профессиональные обязанности:
- Конфигурации в основном БП, БИТ Финанс, ERP
- Командировок нет
- Сверхурочные по желанию

Условия работы:
- 7 минут от метро Савеловская
- Прекрасный двухэтажный офис
- Льготный ДМС
- Белая зарплата
- Полная занятость
- Зарплата 500 - 1200 рублей в час на руки по результатам собеседования
- Сверхурочные в случае их наличия оплачиваются

Телефон: +79264753139
Почта: KNSkryagina@1cbit.ru
http://bit-erp.ru
 
 
   Владимир1С
 
601 - 21.05.18 - 10:59
(600) Разве не "Отче наш" - резервная копия?
   Мигрень
 
602 - 21.05.18 - 11:03
(601) А может он и резервную копию тоже запрограммирует.
   PR
 
603 - 21.05.18 - 11:06
(601) Конечно же нет

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

Во-вторых, наличие архивной копии не означает, что можно на работу приглашать любой шлак, типа не страшно, восстановим из архива, если че
В ларьке такой подход прокатит, в Локотехе, У-УАЗе, Алмазе и пр. — нет, клиенты потому и обращаются, что не хотят ларечных технологий

Копии при этом конечно же делаются
   PR
 
604 - 21.05.18 - 11:08
+(603) А, пардон, не понял сразу, речь про копию, а не бекап
Копия конечно же да, все, что можно, делается на копии
Но все-равно очень многое делается на рабочей базе
Кроме того, все, что делается на копии, все-равно должно же попасть на рабочую
   Мигрень
 
605 - 21.05.18 - 11:14
(603) Как у вас все серьезно, как в пожарной части.
   Владимир1С
 
606 - 21.05.18 - 11:16
(605) Если вести речь о долгосрочном сотрудничестве с клиентом, то да, Резервные копии и адекватные прогерры очень важно. А так да, накосячили, потеряли клиента, да и ладно, пошли к следующему, косячить дальше.
   Мигрень
 
607 - 21.05.18 - 11:18
(606) Прикол в том, что, по моему опыту, от косяков этого так называемого Бита клиенты бегут как ошпареные тараканы.
   Владимир1С
 
608 - 21.05.18 - 11:20
(607) Ну не от всех спецов первобита же !
   shuhard
 
609 - 21.05.18 - 11:20
(607) [этого так называемого Бита]
на лицо симптомы эхолалии, срочно к доктору
   Мигрень
 
610 - 21.05.18 - 11:21
(608) Я так понимаю, что на крупных внедрениях у них опытные, а на ларьках практиканты.
 
 Рекламное место пустует
   Владимир1С
 
611 - 21.05.18 - 11:26
(610) Дело не в практикант/непрактикант. Дело в ориентации на точность достижения поставленной цели. А это уже жизненная философия индивида.
   Мигрень
 
612 - 21.05.18 - 11:28
(611) Ориентацию на хлеб не намажешь..
   Владимир1С
 
613 - 21.05.18 - 11:30
(612) За косячное выполнение денег не дадут ни прямой заказчик, ни франч-раздатчик заказов между тобой и заказчиком. Хоть куда мажь.
   Владимир1С
 
614 - 21.05.18 - 11:39
(607) Дайте их мне, штуки 3. Я к ним на полставки устроюсь, фикси.
   PR
 
615 - 21.05.18 - 11:51
(605) Так а как по-другому-то?
   PR
 
616 - 21.05.18 - 11:53
(606) Ларьки не жалко, да
Проектами на десятки миллионов как-то уже не поразбрасываешься
   Krendel
 
617 - 21.05.18 - 12:11
(613) В большинстве случаев закроют тебе работы
   Krendel
 
618 - 21.05.18 - 12:12
(605) Серьезно это когда срок восстановления из бекапа 4 минуты, а срок перевода на резервную машину порядка 1 минуты
   Владимир1С
 
619 - 21.05.18 - 12:15
(618) Это что за сфера деятельности, где такое оборудование ставиться?
   Krendel
 
620 - 21.05.18 - 12:15
(619) НПФ
   Krendel
 
621 - 21.05.18 - 12:17
фронт офис
   Krendel
 
622 - 21.05.18 - 12:21
(603) Во-первых, у большинства клиентов восстановление из архивной копии практически исключено

Напомню, когда были проблемы с БД Сбербанка и 4 дня простоя, Сбер выкупил всех СКЛщиков с рынка МСК, про Питер не помню
   Владимир1С
 
623 - 21.05.18 - 12:26
(622) На время решения проблемы? я правильно понял?
   Krendel
 
624 - 21.05.18 - 12:34
(623) У меня дружбан в рынке СКЛьщиков крутиться, там до проблем, практиковалась практика в айти брать родственников, а в руководителей левых людей вообще не было, отсюда проблемы с БД, ну и бахнуло, после этого туда набрали избыточное количество людей, и сформировали рабочие группы из профессионалов, теперь мы видим результат
   Владимир1С
 
625 - 21.05.18 - 12:37
(624) Пока гром не грянет... хорошо что так получилось.
   Владимир1С
 
626 - 21.05.18 - 12:38
(624) в личку хотел написать, жаль, не получается.
   Krendel
 
627 - 21.05.18 - 12:39
(625) Дык можно экономить на всем, кроме инфраструктуры ;-)

Поэтому у него и 2 ЦОДа в разных концах МСК, на физически разном оптиковолокне работают
   Krendel
 
628 - 21.05.18 - 12:40
(626) Напиши HeKrendel, у него должна быть открыта
   glebushka
 
629 - 21.05.18 - 12:41
(590) Не готов погружаться в общетеоретический спор. Я дал ответ на практический вопрос в чем отличие.
Все, кого я встречал с шиной данных на нашем рынке, делали упор на трансформацию данных внутри шины (тот же обмен точка-точка, только на единой технологической платформу).
Все, кого я встречал с брокером сообщений, делали упор на эволюционную архитектуру.
(591) Мы такие вещи делаем по-тихоньку. Правда не для внешнего рынка, а, в основном, для новых сотрудников, которые приходят к нам в офис. Но не вижу никаких проблем и наружу опубликовать. Пожелание записал. Сделаем.
   Krendel
 
630 - 21.05.18 - 12:41
Как говорится шлюпки и спасательные круги, средства пожаротушения нужны всего 1 раз,
   PR
 
631 - 21.05.18 - 14:50
(622) А это к чему?
   Новиков
 
632 - 21.05.18 - 15:03
(629) Я вроде как по-тихоньку разбираюсь :) Если не сложно, то можешь ответить на вопрос, я сейчас правильно понимаю тему или нет: если источник и приемник - это базы на 1С, то если мы используем рэббит, то из источника по какому-то событию, типа записали документ - мы отдаем рэббиту xml (через выгрузку по правилам КД любой). Дальше рэббит дергает хттп-сервис в приемнике и передает этот xml - в приемнике в этом сервисе происходит сериализация обратно по правилам в объект? Так все? Или лажа какая-то есть? Если это так, то какие-то плюсы еще рэббита есть именно в этом сценарии, кроме как доставки сообщения?
   Вафель
 
633 - 21.05.18 - 15:05
(632) Этот плюс перекрывает все остальное
 
 
   PR
 
634 - 21.05.18 - 15:14
(632) Нет, Rabbit MQ не дергает, дергает приемник регламентным заданием раз в три секунды
Rabbit MQ вообще ничего не знает про приемник, кто когда попросит, тому тогда и отдаст
   PR
 
635 - 21.05.18 - 15:17
(632) Плюс в том, что Rabbit MQ — это типа такая почтовая служба, куда ты посылку отдал и уверен, что она будет отдана в руки получателю, когда он придет за ней
То есть не ты едешь к получателю с посылкой, а он типа в отпуске на две неделе в другой стране
И не ты вообще заморачиваешься тем, кому нужна твоя посылка и как именно упаковать в нее вещи
То есть принцип КД 3, только трехзвенка
   Новиков
 
636 - 21.05.18 - 15:59
(635) а регистрацию в планах обмена надо вообще делать в этом случае или нет? Или в этом и есть типа фишка - что вместо регистрации, я в рэббит всегда сообщению пуляю?
   NadezhdaGopkalo
 
637 - 21.05.18 - 16:58
А мне нравится работать здесь, советую :)
   PR
 
638 - 21.05.18 - 17:03
(637) О, SLA-щицы подтянулись :))
   PR
 
639 - 21.05.18 - 17:04
(637) Пол поменяй :))
   PR
 
640 - 22.05.18 - 11:18
(636) Пуляние в Rabbit MQ не отменяет регистрации в плане обмена
Можно при желании это асинхронно пулять
   Вафель
 
641 - 22.05.18 - 11:46
(640) и что реально у бита на проектах это используется?
   Вафель
 
642 - 22.05.18 - 11:46
можешь пример привести?
   PR
 
643 - 22.05.18 - 11:48
(641) Да, конечно
   PR
 
644 - 22.05.18 - 11:49
(642) Обмен НСИ и документами на У-УАЗе между 150 АРМами не на 1С и 1С с использованием базы БИТ:MDM
   Новиков
 
645 - 22.05.18 - 13:07
(640) Получается, что сам рэббит не дергает приемник. Он просто копит сообщения. Также все по старому должно регистрироваться в планах. И тогда единственный профит, который как я понял есть - это асинхронность и развязка обмена. Приемник и источник не связаны напрямую, а обмен идет через рэббит, который типа и развязывает эти два узла. Идея интересная безусловно. Подожду ваших обучающих материалов, т.к. вопросов осталось много.
   PR
 
646 - 22.05.18 - 14:59
(645) >>Получается, что сам рэббит не дергает приемник. Он просто копит сообщения.
Да

Я, кстати, сторонник идеи, чтобы дергал, в этом случае не нужно каждые три секунды запускать регламентное задание в приемнике
Но идея всей этой петрушки как раз в том, что кролик ничего ни про кого не знает и может только отдавать по запросу
А, казалось бы, что мешало сделать возможность подписки на события
   PR
 
647 - 22.05.18 - 18:07
(645) Я, кстати, чисто для себя, когда разбирался, набросал мини пример по связке двух баз через кролика, вникнуть в суть так сказать
   sknhb
 
648 - 22.05.18 - 18:37
(645) Дед, ты тоже нашел у кого спрашивать, купи уже запись у профессионалов https://event.infostart.ru/2017/#speaker375784
   Новиков
 
649 - 22.05.18 - 19:49
(648) мне не нужна абстрактная теория без привязке к конкретному решению. Здесь идет разговор про адаптер именно от них, и я уже попросил все обучающие материалы именно в контексте возможного приобретения готового решения. Т.е. нужен нормальный курс/ман/метода - как готовое решение использовать у себя и какие профиты получаются от этого.
 
 Рекламное место пустует
   Cyberhawk
 
650 - 22.05.18 - 20:36
(649) Ты (595) видел?
   PR
 
651 - 23.05.18 - 10:03
(648)  А что, запись у профессионалов сразу всё расшифрует и объяснит?
   sknhb
 
652 - 23.05.18 - 10:27
(649) а что тебе нужно? какую задачу ты хочешь решить? или ты просто повелся на модные слова?
(651) не сразу, постепенно
   Новиков
 
653 - 23.05.18 - 11:25
(652) Мне нужно вот что, и кажется я повелся на модные слова тоже: есть два узла на 1С. В данный момент есть обмен, который происходит по расписанию. В качестве формата обмена используются правила КД 2. Планы обмена не подключены, и не хочется их подключать. Хочется перейти от такой модели, к событие-ориентированной - отдать сообщение брокеру/адаптеру, тот сам дернул бы хттп-сервис приемника и отдал что нужно. Это в общем виде. Хотелось бы покурить эту тему.
   PR
 
654 - 23.05.18 - 17:29
(653) >>Планы обмена не подключены, и не хочется их подключать.
А как понять, что нужно передать?
Допустим, ты при записи что-то попытался передать, но приемник не был доступен, нужно же попробовать позже передать?

>>тот сам дернул бы хттп-сервис приемника и отдал что нужно.
Вот да, было бы неплохо, но я, например, не знаю как
   Новиков
 
655 - 23.05.18 - 18:21
(654) >>нужно же попробовать позже передать?
Судя по промо аналогов вашего адаптера, эта проблема там как-то решается, но не спрашивай как - я сам не знаю ;)

>>Вот да, было бы неплохо, но я, например, не знаю как
Знающие люди, которые курили не только кролика, утверждают, что такое возможно. Но я пока в танке. Мне бы хотелось вот по такой архитектуре построить обмен - без плана, на хттп с учетом какого-то адаптера-брокера.
   PR
 
656 - 23.05.18 - 19:07
(655) У нас это решается просто:
При передаче считается, что Кролик всегда доступен, поэтому передается при записи объекта
Получение инициируется получателем, а не Кроликом, поэтому когда получатель попросит, тогда Кролик ему и отдаст
   PR
 
657 - 24.05.18 - 10:23
+(656) Кстати, если допускать мысль, что Кролик тоже может быть недоступен, то как раз для этого и нужно делать план обмена и регламентное задание, периодически повторяющее попытки отправить зарегистрированные объекты в Кролик
   PR
 
658 - 24.05.18 - 14:34
https://job.mista.ru/users.php?id=118459 фотку обновила, теперь на фоне офиса :))
   glebushka
 
659 - 24.05.18 - 22:49
(653) "дергать" что-то это неправильно архитектурно. Приемник сам, когда ему удобно, должен "дергать" брокер, и получать то, что его интересует. Так ты легко заддосить можешь приемник, если из-за каждого сообщения будешь стучаться в приемник.
Расскажи, зачем ты хочешь уведомлять приемник о том, что появилось новое сообщение?
   Волшебник
 
660 - 24.05.18 - 22:52
(658) Ох! Крутой у вас офис!
   PR
 
661 - 24.05.18 - 23:07
(660) Да, сами тащимся :))
   Cyberhawk
 
662 - 24.05.18 - 23:19
(659) Вроде очевидно: когда в приемник данные поступают нечасто (редко). При этом:
- часто вхолостую дергать шину из приемника не айс
- задержка поступления "редких" данных в приемник (после поступления их в шину) не должна быть большой
.
Вот для этого шина и должна дергать приемник.
   glebushka
 
663 - 25.05.18 - 01:39
(662)
1. Путать шину данных и брокер сообщений не стоит. Это разные классы софта.
2. Мы на своей практике ни разу не встречали ситуацию, когда запуск фонового задания 1С для проверки новых сообщений каждые 3 секунды, например, вызывал бы какие-то реальные проблемы.
3. Если у тебя есть реальный пример, когда это вызывает проблемы, то:
а) изложи, пожалуйста, подробнее, думаю не только мне будет интересно узнать о таком опыте
б) никто не мешает написать на каком-нибудь языке программирования, у которого нет таких накладных расходов для проверки новых сообщений, какие есть при запуске фонового задания в 1С, простенькую программку, которая будет постоянно висеть в памяти и сообщать по приходу сообщений 1С о том, что появились сообщения. На недавнем хакатоне, помнится, кто-то об этом рассказывал. Но, повторюсь, хотелось бы услышать примеры, когда такое усложнение было бы оправдано
   Cyberhawk
 
664 - 25.05.18 - 11:02
"ни разу не встречали ситуацию, когда запуск фонового задания 1С для проверки новых сообщений каждые 3 секунды, например, вызывал бы какие-то реальные проблемы" // Ага: приемник, куда пару раз в неделю данные приходят, и он за эту неделю дернет шину вхолостую более 200 тысяч раз нормально? :)
Почему-то ты заботишься о приемнике (пишешь "легко заддосить можешь приемник"), а о шине - нет.
   PR
 
665 - 25.05.18 - 13:36
(664) Ну, так-то если уж на то пошло, Кролик для того и предназначен, чтобы его дергали
Но возможность подписаться на события было бы круто, да
   Cyberhawk
 
666 - 25.05.18 - 17:07
(665) "Кролик для того и предназначен, чтобы его дергали" // Кто ж с этим спорит - это предназначение у него никто не оспаривает и не отбирает.
Но вроде странным будет отрицать, что шина / брокер становится универсальнее, если помимо "пассивного режима" начинает мочь еще и "активный" (самостоятельно стучаться в приемник - хотя бы с целью уведомления, а не сразу для передачи данных).
Возможно, это противоречит каким-нибудь представлениям / теориям массового обслуживания или каким-нибудь еще там "бест практисес". Но на каждом первом проекте по интеграции с применением шины / брокера вопрос об этой функциональности поднимается, а на каждом втором - реализуется :)
   PR
 
667 - 25.05.18 - 18:30
(666) Универсальность вообще как бы в общем смысле не аргумент, а то так-то, если калькулятор в Кролика встроить, то тоже универсальнее станет
   glebushka
 
668 - 25.05.18 - 20:39
(664) Какие проблемы для заказчика создают создают запросы 1 раз в 3 секунды?
Если проблема реальна, её нужно описать. А дальше выбрать оптимальное решение, и посчитать стоимость его реализации. Далее сравнить стоимость проблемы со стоимостью её решения. И действовать.
При анализе стоимости решения проблемы необходимо учитывать и стоимость дальнейшего сопровождения и поддержки. Ситуация, когда брокер является "активным" усложняет всю архитектуру и в общем случае добавляет гораздо больше проблем, чем решает, например:
1. приемник переехал, как отследить факт переезда и переписать настройки?
2. как часто уведомлять приемник?
3. А если одну очередь разбирают не один приенмник, а несколько? То что делать, сразу всем сообщить?
4. А если число приемников вообще меняется динамически? Используется, например, балансировка нагрузки и в автомате при увеличении нагрузки разворачиваются новые виртуалки, и убиваются, при падении нагрузку?
Ну а про универсальность написал PR в (667)
На хакатоне 1с, кстати, вроде бы был чувак, который решил этот вопрос, только опять же не смог пояснить зачем. Решил тем, что на гитхабе нашел маленькую прогу, которая потребляет мало ресурсов, зато висит в памяти, и при поступлении в очередь сообщения умеет дергать веб-сервис.
   Genayo
 
669 - 25.05.18 - 21:34
(668) А почему нельзя совмещать шину данных и брокер?
   PR
 
670 - 25.05.18 - 22:19
Кстати, немного от 1С в сторону всяких континиус интегрейшенов https://habr.com/company/1c/blog/352210/
   PR
 
671 - 25.05.18 - 22:26
(669) Если я правильно понимаю, шина — это протокол, так сказать некий драйвер, позволяющий одной системе общаться с другой на одном языке
А брокер — это уже более сложная система, которая позволяет хранить сообщения и упорядочивать их по очередям
   Genayo
 
672 - 25.05.18 - 22:42
(671) Понятно, что шина обеспечивает трансформацию сообщений источника в понятный приемникам формат, а брокер - доставку. Не понятно,  почему для "правильной" архитектуры нельзя их совмещать?
   PR
 
673 - 25.05.18 - 22:48
(672) Если я правильно понимаю, при использовании обмена через того же Кролика используется и шина и брокер, иначе не очень понятно, как без того или другого все будет работать
   Cyberhawk
 
674 - 25.05.18 - 22:55
(667) Не в тему последнего предложения
   Cyberhawk
 
675 - 25.05.18 - 23:09
(668) "Какие проблемы для заказчика создают создают запросы 1 раз в 3 секунды?" // Жирновато 200 тыщ раз в неделю создавать ФЗ и дергать шину / брокер, даже если на это расходуется 1-2 секунды, ибо:
- количество секунд в неделе конечно
- сеанс ФЗ в потребителе веб-сервиса и сеанс веб-сервиса (в поставщике веб-сервиса, если шина/брокер на 1С) занимает IP-порт рабочего сервера, в случае нехватки которых все встает в очередь
Конечно же в процентном соотношении как доля времени, так и доля кол-ва портов ничтожна по сравнению с доступным кол-вом этих свободных ресурсов, но это в наше время.

"1. приемник переехал, как отследить факт переезда и переписать настройки?" // Конечно же в шине / брокере есть сервис уведомлений при превышении допустимой паузы отправки и / или ошибках отправки.
"2. как часто уведомлять приемник?" // Мгновенно - по факту готовности для него очередного сообщения, далее - по регламенту. Для особо взыскательных - с увеличивающимся интервалом.
"3. А если одну очередь разбирают не один приенмник, а несколько? То что делать, сразу всем сообщить?" // Что за очередь - несколько накопившихся изходящих сообщений для приемника ты так называешь? Если в шине / брокере появляется очередное изходящее сообщение для того приемника, для которого взведен флажок "Немедленная доставка", то уведомлять каждый такой приемник (если таких получателей несколько - уведомлять их всех).
"4. А если число приемников вообще меняется динамически?" // Хз, такого не видал, расскажи подробнее, что за приемники-гидры эдакие?
"про универсальность написал PR в (667)" // Ты тоже, видимо, невнимательно весь изходный пост прочитал (касательно востребованности этой фичи).
   PR
 
676 - 28.05.18 - 00:19
(674) Не понял
   PR
 
677 - 28.05.18 - 00:27
(675) Жирновато — это что-то непонятное
Я бы понял, если бы ты сказал, например, что это как-то противоестественно постоянно спрашивать брокера, если тот сам может сказать, когда ему что-то придет

Я, кстати, еще раз повторюсь, тоже топлю за возможность подписаться на события в брокере, было бы прикольно

Я бы на вопросы поотвечал так:

>>1. приемник переехал, как отследить факт переезда и переписать настройки?
Об этом должен позаботиться приемник, раз он подписался на события в брокере
Переехал — переподпишись, че

>>2. как часто уведомлять приемник?
Мгновенно, да
В случае недоступности с указанной в подписке периодичностью, хоть каждые те же три секунды

>>3. А если одну очередь разбирают не один приенмник, а несколько? То что делать, сразу всем сообщить?
И что? Сколько подписок — столько уведомлений
сообщать да, сразу всем

>>4. А если число приемников вообще меняется динамически?
И что? Если приемник каким-то макаром создал подписку — получает уведомления, нет — будь добр бегай в брокер сам
   Cyberhawk
 
678 - 28.05.18 - 00:57
(677) "Жирновато — это что-то непонятное" // Я надеялся, что пара пунктов ниже (про ограниченность ресурсов) раскрывает суть. Короче, если считать, что это - фоном каждые 3 секунды вхолостую дергать шину / брокера - нормально (ибо "незаметно" / "не создает проблем", как glebushka говорит), то при разпространении такого подхода на сколько-нибудь достаточное количество приемников N наступит момент, когда это станет проблемой. Другое дело, что это число N (при котором будут проблемы) может быть настолько большим (ввиду "жирных" ресурсов в наши дни), что не встретится в реальной жизни вовсе.
(676) Универсальнее становится не в глобальном смысле, а конкретно в роли шины / брокера. Ибо фича востребованная.
   Genayo
 
679 - 28.05.18 - 08:14
(673) В теории шина может быть не нужна, если не нужна трансформация сообщений. Тогда в общем все логично.
   PR
 
680 - 28.05.18 - 11:03
Еще одно место в отделе занялось :))
   PR
 
681 - 28.05.18 - 11:15
Хех, как выяснилось, мои представления о шине отличаются от реальности, надо бы помучить руководство распросами
   glebushka
 
682 - 28.05.18 - 11:22
(669) Большинство шин включает брокер сообщений. Вопрос здесь в архитектуре.
(671) неправильно понимаешь. Я бы даже сказал наоборот всё :) Брокер - относительно простая система, шина - большая и сложная система. С кучей компонентов (брокер сообщений лишь один из сервисов предоставляемых шиной).
(672) Одна из основных идей событийной интеграции - это уход от архитектуры точка-точка.
Для того, чтобы сделать трансформацию необходимо знать формат источника и формат приемника. Причем формате в широком смысле - т.е. не только xml, json, csv, xls и т.п., а и замена гуидов, "обогащение" данных запросами к другой системе и т.п.
Ничего не напоминает? Это та же точка-точка, только на другом технологическом уровне. Но суть та же.
Если тебе нужно передавать в 5 систем информацию, то тебе нужно написать 5 "трансформаций" одного и того же сообщения. Появится 6-я система, будешь писать 6-ю трансформацию.
   Genayo
 
683 - 28.05.18 - 11:57
(682) Если рассмотреть пример - выгрузка заказа с сайта в несколько систем, я правильно понимаю, что сайт должен сформировать сообщение в нектором своем формате и отправить его в брокер, брокер должен без изменений передать его шине, шина делает трансформацию сообщения, и отправляет сообщения для всех систем брокеру. Далее системы опрашивают брокер на предмет наличия сообщений для них?
   glebushka
 
684 - 28.05.18 - 12:27
(683) всё верно, только без шины и трансформации данных
   Genayo
 
685 - 28.05.18 - 12:34
(684) В смысле, если нужна трансформация, получателем сообщений всегда будет шина, а если не нужна, то получателем будет конечная система? И если получатель шина, то после трансформации она становится отправителем сообщений в брокер для конечной системы?
   PR
 
686 - 28.05.18 - 16:45
   glebushka
 
687 - 28.05.18 - 20:35
(685) трансформацию всегда должна выполнять конечная система. Как только мы вводим понятие шины, мы сразу переходим к архитектуре точка-точка.
   Genayo
 
688 - 28.05.18 - 22:24
(687) О как. Значит, данный подход (с брокером на очередях) достаточно узко специализированный, а не универсальный.
   PR
 
689 - 29.05.18 - 08:43
(688) Что значит узкоспециализированный?
Нельзя с помощью него обои поклеить или что?
Вроде наоборот универсальный, передавай что хочешь, брокеру пофиг, он лишь гарантирует доставку
   Genayo
 
690 - 29.05.18 - 09:11
(689) В том смысле, что его применение оправдано только на высоконагруженных проектах с большим количеством обменивающихся систем.
   shuhard
 
691 - 29.05.18 - 09:13
(690) не соглашусь
нагруженность не ведущий фактор
в первую очередь сокращается стоимость владения системой
   Genayo
 
692 - 29.05.18 - 09:29
(691) От одного брокера сообщений снижается? Это же по сути замена обмена файлами через шару/фтп, при котором также асинхронность и отсутствие точка/точка получается...
   shuhard
 
693 - 29.05.18 - 09:40
(692) упавший обмен замечают через часы,
зависшую очередь за секунды
   Genayo
 
694 - 29.05.18 - 10:08
(693) Это смотря как настроить и написать обмен. Если контролировать, заметят тогда, когда запрограммировано.
   PR
 
695 - 30.05.18 - 09:24
(694) Глубокая мысль, подходит ко всему
   Genayo
 
696 - 30.05.18 - 09:28
(695) Про универсальные преимущества Кролика есть что сказать?
   melabea
 
697 - 30.05.18 - 09:32
Прежде чем нанимать, на всякий случай проверяйте здесь: http://bl-p.xyz/ Черный список сотрудников
   KrisbitYA
 
698 - 30.05.18 - 13:54
Как скучно я живу...
   PR
 
699 - 30.05.18 - 15:09
(698) И не говори
У меня (697) даже не открывается
   vis_tmp
 
700 - 30.05.18 - 15:52
700
  1  2  3  4  5  6  7  8  9  10  11   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
В секцию Вакансии можно добавлять сообщения только после регистрации на форуме.
Если вы уже зарегистрированы, вам нужно войти на форум.
Рекламное место пустует