по апи, манагеры что-то меняет, статусы, что-то ещё, без разницы, долблю обратно по указанным адресам с json, что кто и когда поменял).
Сделано всё на ивентах, ивенты запускают джобы, джобы собирают данные и делают http запросы.
Проблема возникает, когда сервер клиента не отвечает. Сервер может у клиента лечь на пару часов, поэтому мы не ретраем запросы, однако, потом по просьбе клиента это иногда делать надо. Столкнулись с тем, что клиенту нужна хронология, когда, кем, какой статус был проставлен. Т.е. условно есть заказ, который сейчас уже в статусе done, а клиенту нужно выгрузить в 1С всю хронологию, когда статус был в start, когда в work итп.
Сейчас выгружаем всё руками из базы логов, но такое. Подумал, самое простое — отправлять http запросы через отдельные джобы. Тогда, в случае таймаута или другой ошибки джоба с http запросом, я в любой момент времени могу его повторить, заретраить, и он отправит именно те данные, которые были у него изначально, а не текущие данные заказа. И что-то в лоб решить не получается.
Логика сейчас такая, отказаться от фасада Http, написать на газле createRequest, отправить реквест в новый джоб, в джобе уже сделать send. Смущает, что выглядит немного громоздко. Может кто-то сталкивался с подобным или есть более элегантное решение?
сделай аля вебхук менеджер который умеет по заданным входным данным (урл, постдата) создавать в бд запись и возвращать ид вебхука. по этому ид делай джобу которая будет слать те данные что были при создании. статус пишите туда же. если надо перезаслать клиент жмёт на кнопку вы заново делаете джобу с вебхук ид тем самым ему уйдут те данные что были а не актуальные
Ну и очередность стоит в rebbitmq ложить с редисом идея плохая потеряешь данные
сейчас проект небольшой, очереди раскидываются на database, с rabbitmq скорее негативный опыт, есть проект, где 1 из 100 джобов теряется в небытие с rabbitmq. хотя может просто настроено так
Обсуждают сегодня