Bankir.Ru
3 декабря, суббота 18:40

Объявление

Свернуть

Третья ежегодная конференция-консилиум «ИТ-бюджет банка - 2017»

Показать больше
Показать меньше

Поделитесь опытом работы с филиалами

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Поделитесь опытом работы с филиалами

    Интересуют следующие вопросы:
    1.Есть филиал с базой на Oracle. Доступ только по модемному каналу. Как из Oracle выгружать только заданную информацию и грузить в базу головной конторы. Времени на написание каких-то сложных программ выгрузки-загрузки нет, а стандартные средства Oracle достаточно ограничены. Может есть какие-то программные продукты, которые выгружают только выборочные данные(т.е. можно указать where в запросе).
    2.Есть несколько филиалов с разными линиями связи, где-то постоянный, где-то временный, с разными пропускными способностями. Подскажите идеи по технологии сбора информации из нескольких таких филиалов и обьединение этой информации в одном месте.
    Спасибо, Дмитрий.

  • #2
    Извините, помочь не смогу... Но судя по всему, работаете на самописной АБС...

    Варианты безоператорной обработки запросов в филиалах в некоторых продвинутых АБС реализованы довольно-таки сносно...
    Сорри за ОФФ-ТОП...
    Да пребудет с Тобою Великая Сила! ©

    Комментарий


    • #3
      Dm_Ser

      Чудес на свете не бывает Если
      Времени на написание каких-то сложных программ выгрузки-загрузки нет, а стандартные средства Oracle достаточно ограничены

      то решение в данном случае только одно - покупать дорогой софт класса middle ware. Если, конечно, есть деньги Он и позволит указать where в запросе.

      Если денег нет, то придется самому писать выгрузку. Однако и здесь можно минимизировать свои усилия, если использовать единый межмодульный формат. Лучше всего для этого подходит XML. Кстати, межмодульный формат применяется и при использовании систем middle ware.

      Успехов!

      Комментарий


      • #4
        Вот и хотелось бы узнать, что существует из сторонних продуктов. Я встречал продукты, где возможен экспорт данных в ручном режиме, но это не подходит, т.к. в филиалах есть неподготовленные админы, а канал достаточно слабый, чтобы отсюда еще это обрабатывать. Т.е. хотелось бы настроить все в автоматическом режиме.
        В принципе, понятно, для этих целей пишут Date Warehouse, но это очень длительный процесс.
        А деньги то есть, надо только знать, за что их отдавать))

        Комментарий


        • #5
          Здравствуйте, уважаемый!
          Сложность решения вашей задачи зависит от более конкретных требований. Так (по первому вопросу) вы могли бы воспользоваться стандартным механизмом Oracle - репликацией данных. Но, возможно, в чистом виде вас это не устроит. Здесь уже надо смотреть на конкретные задачи.

          Со вторым вопросом сложнее. Сама задача "сбора и объединения информации" (будем называть это задачей интеграции данных) весьма нетривиальна. Мне кажется, здесь не обойтись без затрат, временных (на разработку) или финансовых (на покупку готового инструмента). А вообще, решения (готовые) этой задачи существуют. Вот Валерий Иванович пишет о лучшем на свете решении с использованием XML - как вариант. Ваш скромный слуга рискнет заявить, что существуют решения, отличающиеся от воспетых В.И. Кроме Интерсофтлаба и R-Style Softlab'а (из отечественных), есть решения западных компаний, например, Oracle (Wherehouse Builder) и Ardent (Data Stage). Всем им присущи свои достоинства и недостатки, все они стоят по-разному.
          Подробнее о технологии загрузки и очистки данных вы можете почитать в ж. "Банки и Технологии" №6 за 2001г. стр. 48.

          С уважением,
          Сергей Пожарненков
          R-Style Softlab.

          Комментарий


          • #6
            Dm_Ser

            Загадочные воросы вы задаете... Возможно, у вас времени совсем нет.
            А что разработчики АБС говорят?

            1. Достаточно быстро реализуется самописными средствами с помощью любого языка/СУБД поддерживающего SQL и связь с Оракл. (Нужно-то всего лишь в динамическом режиме сформировать SQL-запрос на выборку/добавление к базе данных Оракл и выполнить его - вот и вся программка.)
            Насчет неподготовленных админов - напишите им подробнейшую инструкцию для исполнения, распечатайте и пусть повесят на видном месте.


            2. Все зависит от того, что за данные вы хотите собирать, их размера и пр. А технология простая - собрал данные, подготовил к передаче, передал (по расписанию), принял, обработал. Стандартная схема двух-трехзвенки. Постоянная связь здесь абсолютно не нужна, если, конечно, вы не собираетесь гонять 2-.. Мб данных ежедневно.

            С уважением.

            К_Маркелов

            Мне кажется, если бы они сами писали, этих бы вопросов не возникло.[/B]

            Комментарий


            • #7
              godata если бы они сами писали, этих бы вопросов не возникло Как раз наоборот: Писали когда-то одни, а юзают сейчас другие... Сплошь и рядом такая ситуация... Или подобная возможность "органически" не заложена в систему при написании...
              pozharnenkov@softlab.ru - Жаль, что не зарегистрировались, но всё равно - себя назвали... Уважаю! Однако, не надо так болезненно реагировать на постинг Вашего коллеги Валерий: о лучшем на свете или отличающиеся от воспетых
              Dm_Ser А деньги то есть, надо только знать, за что их отдавать Как вариант - за консалтинг!!! ... И всё-таки, что юзает головной Банк, и что юзают филиалы??? Если не хотите писать здесь, то можно - в Би- или Е- мэйл.
              godata Конечно, можно писАть им подробнейшую инструкцию для исполнения, но я-то говорил, что есть варианты безоператорной обработки в филиалах подобных запросов, сформированных в центре в офф-лайне... Что более технологично. И от неподготовленныХ админОВ меньше зависимости...
              Да пребудет с Тобою Великая Сила! ©

              Комментарий


              • #8
                К_Маркелов

                Вообще-то я говорил об инструкции как о временном решении до ввода автоматической обработки... Я думал, это было понятно.

                Комментарий


                • #9
                  Спасибо за ответы. Но как говорил классик "Не учите жить, помогите материально" .
                  У нас своя банковская система, как всегда со своими плюсами и минусами.
                  У филиалов тоже самое.
                  В общих технологиях мы тоже сильны, просто хотел, чтобы кто-нибудь поделился конкретным опытом сбора информации из филиалов. Идей как это реализовать хватает. Но не хотелось бы писать что-то свое, если существуют какие-то готовые решения. Сложность в том, что непонятно, какие данные тащить из филиалов и набор информации может динамически изменяться. А нужно простейшее средство типа Oracle export, но только чтобы позволял экспортировать данные по условию(например, проводки за дату или новые счета, введенные сегодня и т.д.). А уже в головном оффисе мы эту информацию как-нибудь обработаем.
                  Спасибо, Дмитрий.

                  Комментарий


                  • #10
                    К Маркелов и остальные
                    Простите, если кого-нибудь обидел или задел. Мне, право, жаль, что мои высказывания были восприняты как "болезненная реакция на постинг коллеги". Уверяю, ничего подобного не было. Это просто такой стиль повествования. Еще раз прошу прощения.
                    А регистрироваться я пытался, но регистрация почему-то пропадает спустя какое-то время. Вот и приходится так...

                    Dm Ser
                    Я так и не понял, вас интересует именно опыт сбора данных из филиалов? В моем понимании эта задача включает в себя:
                    1) извлечение данных из учетных систем филиала
                    2) передачу данных в головной офис (ГО)
                    3) интеграция данных в информационной системе ГО так, чтобы в дальнейшем к этой информации можно было обращаться как к единому массиву систематизированных данных.

                    Если же вам необходимо простое средство извлечения данных, которые можно потом как-то передать в головной офис и там с ними как-нибудь разобраться, то это более простая задача.

                    Есть еще один момент, который стоит уточнить. Все стандартные средства Oracle работают с физическими объектами БД (таблицами, представлениями и т.п.). Как только вы начинаете говорить, что вам необходимо выгружать проводки, счета и пр., т.е. оперируете понятиями бизнес-логики и хотите с ними работать, вы неизбежно придете к необходимости написания репозитария (словаря, устанавливающего соответствия между бизнес-логикой и физическими объектами). Какой вариант вам нужен?

                    Решения, безусловно, существуют. Я не уверен, что здесь будет корректно их называть, нго вы можете обратиться и в Интерсофтлаб и в нашу компанию (R-Style Softlab) и узнать о конкретных продуктах.

                    С уважением,
                    Сергей Пожарненков
                    R-Style Softlab.

                    Комментарий


                    • #11
                      pozharnenkov@softlab.ru регистрироваться я пытался, но регистрация почему-то пропадает спустя какое-то время
                      Сергей! Гляньте сюда http://dom.bankir.ru/misc.php?s=&action=faq , или у Владимира Кузовлева спросите. Куки должны быть включены, ну и ... по мелочи...
                      Dm_Ser! Удачи Вам!!! Не умаляя достоинств Вашей системы, рекомендовал бы промышленную версию... Поверьте, Вашим программерам работы хватит. Только будут они не столько кодировщиками, сколько технологами.
                      ... И, насколько я понимаю, корректное решение Вашей проблемы зависит от заложенной Вами же архитектуры системы, которая нам неизвестна. Но если Вы пытаетесь найти решение на уровне "какие-то готовые решения", то, видимо, Вас ждёт разочарование...
                      По смыслу написанного я во-многом разделяю точки зрения ув. Валерий и pozharnenkov@softlab.ru
                      Ещё раз: Удачи Вам!!!
                      Да пребудет с Тобою Великая Сила! ©

                      Комментарий


                      • #12
                        Dm_Ser
                        В принципе, понятно, для этих целей пишут Date Warehouse, но это очень длительный процесс

                        Вот уж не согласен! По опыту знаю - это недолго. А за какой срок Вы хотите наладить ежедневный сбор данных и из какого количества филиалов и сколько видов АБС?

                        pozharnenkov@softlab.ru

                        Еще раз прошу прощения.

                        Извинения принимаются


                        К_Маркелов
                        Константин, добрый день! Ты нак всегда на высоте - тема вышла в конструктивное русло.

                        Комментарий


                        • #13
                          pozharnenkov@softlab.ru
                          Вот тут Вы и подошли к тому, что нам надо. Всю бизнес логику, необходимую нам, можно реализовать механизмом view в Oracle. Но нужен механизм, который выгружает эти view в обычный текстовый файл. Опять же это должно запускаться в командном режиме, а не manual. При добавлении нового view не хотелось бы переписывать программный код.
                          Возможный путь решения-разрабатываем свой формат выгрузки, пишем программу выгрузки из view через обычный select * from ... И т.д. и т.п.
                          Можно, конечно, воспользоваться SQL*Loader, но здесь мы втыкаемся в большое количество ctl-файлов, которые нужно сопровождать.
                          Неужели не существует такого готового решения?
                          К Маркелов
                          Вопрос не в структуре нашей системы, потому что мы не знаем точно какой набор данных готовить, а в механизме подготовки этих данных для передачи.
                          Спасибо за ответы.

                          Комментарий


                          • #14
                            Dm_Ser
                            По вопросу №1.
                            Есть такие продукты! Ну, например, из самых простых и доступных - Access, Excel, Crystal Reports, SQL Navigator.

                            По вопросу №2.
                            Вот Вам один из вариантов технологии сбора информации из филиалов.
                            Имеем три программки или процесса, которые крутятся постоянно.

                            Процесс 1. Выполняется в головном банке. По установленному расписанию формирует запрос на информацию вида:
                            Наименование отчета>, Параметр1>, Параметр2>, ...ПараметрN>
                            Этот запрос оформляется в виде письма электронной почты (можно использовать любую транспортную систему, где реализованы экспорт/импорт сообщений) и отправляется в филиал.
                            В филиале Процесс 2 по получению запроса обрабатывает его и запускает требуемый отчет, результат его выполнения посылается в головной банк.
                            В головном банке Процесс 3 получает отчет и загружает данные в общую базу данных.

                            Эта система работает полностью автоматически без участия администраторов в филиалах, что так важно в Вашем случае, не предъявляет никаких требований ни к каналам связи, т.к. между головным банком и филиалом происходит обмен сообщениями, а не выполнение транзакций, ни к уровню сложности отчетов, т.к. последние выполняются локально в филиалах. Кроме того, эта система легко модифицируется и расширяется.

                            Но в вашем случае о технологиях говорить преждевременно, т.к.

                            Сложность в том, что непонятно, какие данные тащить из филиалов

                            Определитесь сначала с постановкой задачи, а потом уже дамайте о ее решении. Вы же начинаете не с того конца.

                            Комментарий


                            • #15
                              Dm_Ser
                              Вы все время описываете различные технические аспекты реализации вашей задачи, при этом о самой задаче говорите лишь в общих чертах. Общие идеи вам не подходят. Если вы хотите получить конкретные советы, то вам стоит конкретизировать и саму задачу.

                              Что касается готового решения, то мне кажется, найти "фишечку", о которой вы пишите, будет сложно. Обычно подобные решения существуют как часть чего-то большого и универсального охватывающего весь процесс сбора данных из удаленных источников. Класс этих систем называется ETL (extraction-transformation-loading). При этом "фокус проработанности" таких решений смещен в сторону букв T и L.
                              Хотите обсуждать готовые продукты - добро пожаловать в мыло.

                              Комментарий


                              • #16
                                Dm_Ser
                                Пользоваться репликациями оракла я бы не рекомендовал - модемный трафик этого не потянет, да и всеровно софт придется переписывать, т.к. придется строить снапшоты и менять первичные ключи - зашивать туда номера узла. самописанная система - тут даж завидую. Я бы рекомендовал просмотреть решение такое:
                                1. Провести анализ филиальского функционала, который хоцца видеть в центре (например кредитные договора можно не тянуть, перетянуть только проводки)
                                2. Анализ основных таблиц, по котрым можно восстановить другие (например проводки перенести, а обороты можно и подсчитать)
                                3. Написать на таблицы из п.2 триггеры, которые будут собирать информацию о изменениях записей
                                4. Повесить джобы (можно даж оракловые) которые будут переодически выгружать данные. Отправлять можно и ручками, ничего страшного.
                                5. Написать загрузку.
                                6. Из ЦО достаточно реплицировать только проводки и документы по счетам филиала (для каждого отдельно).

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

                                Комментарий


                                • #17
                                  Unregistered

                                  Очень разумно. Но как быть с тем, что набор информации может динамически изменяться ? (по словам Дмитрия). Вы при этом переписывали софт в центре и филиалах?

                                  Комментарий


                                  • #18
                                    Валерий Не пойму пчему был Unregistered, но пусть это будет на совести админа сайта.

                                    Если под набором информации понимать функционал, то ессно переписывается софт. Или я что то не так понял. Если грубо реплицировать только проводки и документы, счета и клиентов (впринципе этого совершенно достаточно, токо часть отчетности сводить руками придется, типа 17 инстр и т.п.) то изменения в софте будут только при изменении соотв. структур. Я фактически предлагаю заменить оракловую репликацию на самописанно-банковско-функциональную. Прямого ораклового решения впринципе нету, ну резве что строить кластер и тянуть оптику, но и тоды возможны траблы с распределенными транзакциями, да и само по себе решение очччччч дорогое. Недаром во всех примерах оракла (не теоретических) ноды кластера связаны scsi стойкой общей...
                                    Т.о. Решение по любому выходит в изменении реплицирующего софта при изменении функционального. Надеюсь мои "наименования" и "разграничения" понятны.

                                    Комментарий


                                    • #19
                                      koticka
                                      Я фактически предлагаю заменить оракловую репликацию на самописанно-банковско-функциональную
                                      Двумя руками - за! Правда жизни в том, что нет "астролябии, которая все меряет" и все-равно приходится делать этот предметно-ориентированный софт, даже если есть под рукой те же фирменные ETL-средства. Тогда возникает вопрос - а в чем заключается счатье от их применения (фирменных средств)? Ряд простых задач под них хорошо ложится, но что касается банковской практики, часто их не хватает. К сожалению, мало кто это понимает

                                      Если под набором информации понимать функционал, то ессно переписывается софт. Или я что то не так понял.
                                      Вы правильно поняли. Вот этой писанины и хочется избежать, по-крайней мере - минимизировать. А Вы не рассматривали вариант генерации процедур выгрузки/загрузки на основе описаний структур и бизнес-логики?

                                      Комментарий


                                      • #20
                                        Валерий Ну можно и апгрейды так рассылать... это уже частности - формат файла, проц. загрузки и т.п. Теоретически можно сделать все. Но если это оракл я бы не стал сильно абстракный огород городить старые добрые FK, PK и т.п. и нормальное администрирование.... Можно все описать абстрактно и перекидывать.... ну допустим сериализованные жаба классы - сработает - но утопия.

                                        Комментарий

                                        Пользователи, просматривающие эту тему

                                        Свернуть

                                        Присутствует 1. Участников: 0, гостей: 1.

                                        Обработка...
                                        X