Все гораздо проще. Вы можете остаток меньше копейки накапливать, и как только он превысит копейку, ее добавить. Придраться сложно - так как это в пределах округления, но зато результат полностью соответствует взятию процентов с полной суммы.
PS: Да и хранить то ничего не нужно - если дельта больше 1 то добавляем 1:
дельта = (общая сумма) * процент - (сумма всех значений))
Насколько понимаю, тут следует разделить шедулинг и систему единичной копии. Кстати, решение единичной копии можно же решать и в отрыве от шедулинга. Можно, например вообще запускать отдельную копию которая и будет делать только отчет, тогда и проблемы единичного запуска нет. Да и контролировать потом эту копию легче.
первое: проверять на эндпоинте оставшееся время и если его мало для выполнения запроса то кидать ошибку; ну это-же на самом кленте сделать легко
второе: вам не обязательно использовать клиенский аксесс токен к другим сервисам; вы можете создать для каждого микросервиса клиента и уже с его аксесс токеном выполнять запросы; ясное дело что и этого аксесс токена время нужно контролировать, но тут с переполучением его проблем нет
Вы аппелируете к результату, а вам рассказывают про структуру хранения данных. Практически ни в одной программе структура результата и структура хранения не сопадают.
При том для хранения данных есть критерии. Хранение документов и проводок - это дублирование данных, что не очень хорошо. На это идут (дублирование) только для увеличения производительности. С производительностью сейчас проблем нет. Тогда в полный рост встает вопрос, а зачем дублировать данные.
Первичны все таки документы. В докомпьютерную эпоху нужно было их как-то генерализовать, вот и появился регистр да еще и двойная запись. В век компьютеров, компьютер может перелопатить сто раз в секунду ваши документы и создать отчет с любым видом и разрезом.
Он был непопулярен и у GOG - им сысла не было на шару игры раздавать, они от этого ничего не поучали. Им интереснее чтобы на их платформе деньги тратили.
Зачем? Ну, напрмер, если у вас много инциализаций через var, и в нем затесается определениечерез явный тип, то на таком определении ломается "чтение" кода.
Я так понимаю у вас здесь токен заменяе сессию, поэтому тут jwt токен явно и не нужен.
Всем нравятся JWT, но мало кто умеет их готовить. :) В правильной реализации сервер авторизации только ВЫДАЕТ токены, не НЕ ПРОВЕРЯЕТ их. А проверяют их уже конечные серверы ресуросов без участия сервера авторизации. В этои и есть суть - что это РАСПРЕДЕЛЕННАЯ система.
Если у вас сложный бизнес процесс, и там НУЖНО ручное участие пользователя, то такие движки - это самое то.
Если участия пользователя нет, то я бы не стал в бпм выносить кишки обработки оно сложности не уменьшит а только увеличит, дополнительной конфигуриуемости не даст. В этом случае лучше смотреть в сторону движков конечных автоматов.
Как понимаю, проблема только с к лючами. Вынесите их в конфигурацию и назовите персональным паролем. ;)
Это в постановке задачи.
А вообще проблема то не в округлении а в безграмотности. Вот сидит такая Клава, принимающая отчеты, у нее есть процент и ей плевать на округление...
В реальности это не так. А вон есть еще закон Бенфорда или что-то подобное. И поэтому разница будет большая. Все по законам Мерфи. :)
Все гораздо проще. Вы можете остаток меньше копейки накапливать, и как только он превысит копейку, ее добавить. Придраться сложно - так как это в пределах округления, но зато результат полностью соответствует взятию процентов с полной суммы.
PS: Да и хранить то ничего не нужно - если дельта больше 1 то добавляем 1:
дельта = (общая сумма) * процент - (сумма всех значений))
Насколько понимаю, тут следует разделить шедулинг и систему единичной копии. Кстати, решение единичной копии можно же решать и в отрыве от шедулинга. Можно, например вообще запускать отдельную копию которая и будет делать только отчет, тогда и проблемы единичного запуска нет. Да и контролировать потом эту копию легче.
Вообще решения вашей проблемы два:
первое: проверять на эндпоинте оставшееся время и если его мало для выполнения запроса то кидать ошибку; ну это-же на самом кленте сделать легко
второе: вам не обязательно использовать клиенский аксесс токен к другим сервисам; вы можете создать для каждого микросервиса клиента и уже с его аксесс токеном выполнять запросы; ясное дело что и этого аксесс токена время нужно контролировать, но тут с переполучением его проблем нет
Ужас какой!
Во первых билблиотеки keycloak для спринга - deprecated.
Во вторых спринг поддерживает OAUTH из коробки.
В третьих рефреш токен по хорошему должен быть одноразовым и поэтому вы не можете его использовать.
Хотя о чем это я, аксесс и рефреш токен в кажом запросе вместе. Зачем вам OAUTH вам бы и BASIC автризации хватило - вы ее как раз и сделали.
Вы аппелируете к результату, а вам рассказывают про структуру хранения данных. Практически ни в одной программе структура результата и структура хранения не сопадают.
При том для хранения данных есть критерии. Хранение документов и проводок - это дублирование данных, что не очень хорошо. На это идут (дублирование) только для увеличения производительности. С производительностью сейчас проблем нет. Тогда в полный рост встает вопрос, а зачем дублировать данные.
Первичны все таки документы. В докомпьютерную эпоху нужно было их как-то генерализовать, вот и появился регистр да еще и двойная запись. В век компьютеров, компьютер может перелопатить сто раз в секунду ваши документы и создать отчет с любым видом и разрезом.
Так что да - это атавизм.
Он был непопулярен и у GOG - им сысла не было на шару игры раздавать, они от этого ничего не поучали. Им интереснее чтобы на их платформе деньги тратили.
Хохма в том, что ASI неотключаем. Поэтому теперь всегда нужно писать код так, как если бы псих не смог вставить точку с запятой в ваш код. :)
Если что-то непонятно, стоит лучше почитать документацию - JEP 286.
Можно var инициализировать null:
var test = (AnyType) null;
Зачем? Ну, напрмер, если у вас много инциализаций через var, и в нем затесается определениечерез явный тип, то на таком определении ломается "чтение" кода.
Извините, данный пакет больше недоступен в вашей стране.
Я так понимаю у вас здесь токен заменяе сессию, поэтому тут jwt токен явно и не нужен.
Всем нравятся JWT, но мало кто умеет их готовить. :) В правильной реализации сервер авторизации только ВЫДАЕТ токены, не НЕ ПРОВЕРЯЕТ их. А проверяют их уже конечные серверы ресуросов без участия сервера авторизации. В этои и есть суть - что это РАСПРЕДЕЛЕННАЯ система.
Я так понимаю, это ожидаемое продолжение законов о приземлении и локализации баз для зарубежных сервисов.
Есть крутая книга со всеми алгоритмами
Implementing Elliptic Curve Cryptography - Michael Rosing
Метод forEach доступен у стрима. Не нужно результат коллекционировать в список (collect) - это лишняя операция, притом создающая ненужный List.
Если у вас сложный бизнес процесс, и там НУЖНО ручное участие пользователя, то такие движки - это самое то.
Если участия пользователя нет, то я бы не стал в бпм выносить кишки обработки оно сложности не уменьшит а только увеличит, дополнительной конфигуриуемости не даст. В этом случае лучше смотреть в сторону движков конечных автоматов.
Кто сказал слово "концлагерь"? Нет! Это поселение. :)
Плюс, в таком поселении все будет предоставлено государством! То есть зарплата не нужна или сугубо будет символической.