V
но если у него там строка – должно работать
Это если строка будет такая-же передаваться в метод как значение user.getUsername()
Size: a a a
2020 July 12
IK
Vlad
Это если строка будет такая-же передаваться в метод как значение user.getUsername()
ну так он вроде ее и передает (я надеюсь)
НБ
Нет, оно все равно лезет внутрь метода, при чем не только в этот и во всех других моках тоже
НБ
Придется тикет писать на стаковерфлоу, блин(
IK
А есть ли возможность код скинуть на gist.github.com?
НБ
А есть ли возможность код скинуть на gist.github.com?
IK
У вас loginCommand никак не использует ваши моки, можно удалить код с ними и ничего не изменится. Видимо где-то внутри осуществляется инициализация реальных объектов...
НБ
А разве эта аннотация, не инжектит моки внутрь? @InjectMocks
LoginCommand loginCommand;
LoginCommand loginCommand;
SP
new LoginCommand не нужен
SP
А разве эта аннотация, не инжектит моки внутрь? @InjectMocks
LoginCommand loginCommand;
LoginCommand loginCommand;
Инжектит, но ты же в тесте инстанс переприсваиваешь
IK
Всем привет! Есть такой вопрос или даже просьба поделиться опытом и советом.
Заранее извиняюсь, что много текста…
Дано: система обрабатывающая заявки на выдачу разных продуктов. Во время обработки заявка проходит через несколько этапов, в каждом из которых также есть подмножество операций (зачастую АСИНХРОННЫХ) с обращениями во внешние системы.
На данный момент архитектура основана на статусной модели и батчевой обработке записей.
То есть заявка на выдачу печенья условно живет так: готова к валидация -> валидация закончена -> готова к поиску клиента -> клиент найден -> ну и так далее. По шедулерам запускается множество сервисов, которые отбирают записи в нужном им статусе и делают с ними, что им надо.
Долгое время система работала с продукцией только небольшого количества фирм, но пришел бизнес и говорит, что хочет запустить кучу других продуктов на нашей платформе, и запускать он их хочет раз в месяц и вообще бизнес логика обработки новых продуктов сулит кучу разных вариаций обработки заявок на выдачу. Например, для одного продукта не надо проводить нотификацию, для второго не надо заключать договор, а для третьего надо заключать договор, но особенный, ну, и так далее.
Цель: Одна из мыслей это создать некий конструктор, где с помощью веб интерфейса можно будет для разных продуктов, например, определять разный порядок этапов обработки, их необходимость и т.д..
Ну и собственно вопрос в том, был ли у кого-то подобный опыт или может быть читали о таком или просто может есть идеи, как спроектировать?
Заранее спасибо!
Заранее извиняюсь, что много текста…
Дано: система обрабатывающая заявки на выдачу разных продуктов. Во время обработки заявка проходит через несколько этапов, в каждом из которых также есть подмножество операций (зачастую АСИНХРОННЫХ) с обращениями во внешние системы.
На данный момент архитектура основана на статусной модели и батчевой обработке записей.
То есть заявка на выдачу печенья условно живет так: готова к валидация -> валидация закончена -> готова к поиску клиента -> клиент найден -> ну и так далее. По шедулерам запускается множество сервисов, которые отбирают записи в нужном им статусе и делают с ними, что им надо.
Долгое время система работала с продукцией только небольшого количества фирм, но пришел бизнес и говорит, что хочет запустить кучу других продуктов на нашей платформе, и запускать он их хочет раз в месяц и вообще бизнес логика обработки новых продуктов сулит кучу разных вариаций обработки заявок на выдачу. Например, для одного продукта не надо проводить нотификацию, для второго не надо заключать договор, а для третьего надо заключать договор, но особенный, ну, и так далее.
Цель: Одна из мыслей это создать некий конструктор, где с помощью веб интерфейса можно будет для разных продуктов, например, определять разный порядок этапов обработки, их необходимость и т.д..
Ну и собственно вопрос в том, был ли у кого-то подобный опыт или может быть читали о таком или просто может есть идеи, как спроектировать?
Заранее спасибо!
НБ
Инжектит, но ты же в тесте инстанс переприсваиваешь
Убрал, все равно тоже самое
SP
Всем привет! Есть такой вопрос или даже просьба поделиться опытом и советом.
Заранее извиняюсь, что много текста…
Дано: система обрабатывающая заявки на выдачу разных продуктов. Во время обработки заявка проходит через несколько этапов, в каждом из которых также есть подмножество операций (зачастую АСИНХРОННЫХ) с обращениями во внешние системы.
На данный момент архитектура основана на статусной модели и батчевой обработке записей.
То есть заявка на выдачу печенья условно живет так: готова к валидация -> валидация закончена -> готова к поиску клиента -> клиент найден -> ну и так далее. По шедулерам запускается множество сервисов, которые отбирают записи в нужном им статусе и делают с ними, что им надо.
Долгое время система работала с продукцией только небольшого количества фирм, но пришел бизнес и говорит, что хочет запустить кучу других продуктов на нашей платформе, и запускать он их хочет раз в месяц и вообще бизнес логика обработки новых продуктов сулит кучу разных вариаций обработки заявок на выдачу. Например, для одного продукта не надо проводить нотификацию, для второго не надо заключать договор, а для третьего надо заключать договор, но особенный, ну, и так далее.
Цель: Одна из мыслей это создать некий конструктор, где с помощью веб интерфейса можно будет для разных продуктов, например, определять разный порядок этапов обработки, их необходимость и т.д..
Ну и собственно вопрос в том, был ли у кого-то подобный опыт или может быть читали о таком или просто может есть идеи, как спроектировать?
Заранее спасибо!
Заранее извиняюсь, что много текста…
Дано: система обрабатывающая заявки на выдачу разных продуктов. Во время обработки заявка проходит через несколько этапов, в каждом из которых также есть подмножество операций (зачастую АСИНХРОННЫХ) с обращениями во внешние системы.
На данный момент архитектура основана на статусной модели и батчевой обработке записей.
То есть заявка на выдачу печенья условно живет так: готова к валидация -> валидация закончена -> готова к поиску клиента -> клиент найден -> ну и так далее. По шедулерам запускается множество сервисов, которые отбирают записи в нужном им статусе и делают с ними, что им надо.
Долгое время система работала с продукцией только небольшого количества фирм, но пришел бизнес и говорит, что хочет запустить кучу других продуктов на нашей платформе, и запускать он их хочет раз в месяц и вообще бизнес логика обработки новых продуктов сулит кучу разных вариаций обработки заявок на выдачу. Например, для одного продукта не надо проводить нотификацию, для второго не надо заключать договор, а для третьего надо заключать договор, но особенный, ну, и так далее.
Цель: Одна из мыслей это создать некий конструктор, где с помощью веб интерфейса можно будет для разных продуктов, например, определять разный порядок этапов обработки, их необходимость и т.д..
Ну и собственно вопрос в том, был ли у кого-то подобный опыт или может быть читали о таком или просто может есть идеи, как спроектировать?
Заранее спасибо!
BPM и его движки
SP
Убрал, все равно тоже самое
Гист показывай новый
IG
Всем привет! Есть такой вопрос или даже просьба поделиться опытом и советом.
Заранее извиняюсь, что много текста…
Дано: система обрабатывающая заявки на выдачу разных продуктов. Во время обработки заявка проходит через несколько этапов, в каждом из которых также есть подмножество операций (зачастую АСИНХРОННЫХ) с обращениями во внешние системы.
На данный момент архитектура основана на статусной модели и батчевой обработке записей.
То есть заявка на выдачу печенья условно живет так: готова к валидация -> валидация закончена -> готова к поиску клиента -> клиент найден -> ну и так далее. По шедулерам запускается множество сервисов, которые отбирают записи в нужном им статусе и делают с ними, что им надо.
Долгое время система работала с продукцией только небольшого количества фирм, но пришел бизнес и говорит, что хочет запустить кучу других продуктов на нашей платформе, и запускать он их хочет раз в месяц и вообще бизнес логика обработки новых продуктов сулит кучу разных вариаций обработки заявок на выдачу. Например, для одного продукта не надо проводить нотификацию, для второго не надо заключать договор, а для третьего надо заключать договор, но особенный, ну, и так далее.
Цель: Одна из мыслей это создать некий конструктор, где с помощью веб интерфейса можно будет для разных продуктов, например, определять разный порядок этапов обработки, их необходимость и т.д..
Ну и собственно вопрос в том, был ли у кого-то подобный опыт или может быть читали о таком или просто может есть идеи, как спроектировать?
Заранее спасибо!
Заранее извиняюсь, что много текста…
Дано: система обрабатывающая заявки на выдачу разных продуктов. Во время обработки заявка проходит через несколько этапов, в каждом из которых также есть подмножество операций (зачастую АСИНХРОННЫХ) с обращениями во внешние системы.
На данный момент архитектура основана на статусной модели и батчевой обработке записей.
То есть заявка на выдачу печенья условно живет так: готова к валидация -> валидация закончена -> готова к поиску клиента -> клиент найден -> ну и так далее. По шедулерам запускается множество сервисов, которые отбирают записи в нужном им статусе и делают с ними, что им надо.
Долгое время система работала с продукцией только небольшого количества фирм, но пришел бизнес и говорит, что хочет запустить кучу других продуктов на нашей платформе, и запускать он их хочет раз в месяц и вообще бизнес логика обработки новых продуктов сулит кучу разных вариаций обработки заявок на выдачу. Например, для одного продукта не надо проводить нотификацию, для второго не надо заключать договор, а для третьего надо заключать договор, но особенный, ну, и так далее.
Цель: Одна из мыслей это создать некий конструктор, где с помощью веб интерфейса можно будет для разных продуктов, например, определять разный порядок этапов обработки, их необходимость и т.д..
Ну и собственно вопрос в том, был ли у кого-то подобный опыт или может быть читали о таком или просто может есть идеи, как спроектировать?
Заранее спасибо!
Главное не унифицировать БП в этом случае. По-хорошому тут должен быть BPM engine (но так как у вас всё навелосипежено, то уже хз)
IK
Главное не унифицировать БП в этом случае. По-хорошому тут должен быть BPM engine (но так как у вас всё навелосипежено, то уже хз)
имеешь ввиду использовать всякие решения от Oralce и IBM?
IG
имеешь ввиду использовать всякие решения от Oralce и IBM?
Camunda.