Суперконтролёры мегазвёздных систем – против зимнего времени

ivan Leave a comment

Читаю/слушаю роман “Регулюм” за авторством Василия Головачёва, датированный 1999-м годом.

Многослойная бурлящая вселенная и многоуровневый контроль реальности – это ещё не все.

Главная штаб-квартира контролёров жизни (так называемое Равновесие-А) находится в Москве. Простой москвоцентризм средней руки.

Кроме всего прочего там вспоминаются мифические трёхглазые атланты, а также наличествуют и гиперборейцы, указанные как прямые прародители расы людей.

Слово “телепортация” считается в романе некошерным, а кошерно говорить “туннельное просачивание” или попросту “волхварь”. Описание разницы сводится к словам “потенциальный барьер” и “мегазакон преодоления препятствий”.

Один из ГГ имеет роман с дочерью замглавногоуправляющегоадминистрациитворцавсеговсего. Ну если одному ГГ перепадает волею судеб суперсила и обычная русская женщина, то его напарнику должна была перепасть хотя бы прынцесса. Ибо справедливо.

Ещё позабавили имена двух основных героев – “Панов” и “Вадим”. Это реверанс или так сложилось?

Очень много хитронаучных девайсов в этом девайсе работают на так называемых “торсионных полях”.

Дополнительно в романе сообщается, что середина двадцать первого века – это некоторая крышка, которая прихлопывает наш регуюм по времени (большой пёс с пятью лапами). То есть, ближайшее будущее человечества – очень туманно (вероятно к концу романа ГГ разберётся и с этой проблемой посредством корректировки событий во времени).

Мы не понимаем, почему влияние СТАБСа ограничено серединой двадцать первого века". "То есть как ограничено? Я не понимаю…" "На хроноспейсное перемещение наложен запрет, нечто вроде физического закона, запрещающего пропуск в будущее физических тел. Мы не можем проникнуть в будущее Регулюма выше середины Двадцать первого века и контролировать баланс энергий в полной мере".

Так вот ещё и оказалось – Дмитрий Медведев является прямым агентом наивысших сил или объектом их прямого вмешательства. Один из его ходов по облагодетельствованию всего человечества – это отмена зимнего/летнего времени.

 

(далее…)

Шаманство вокруг поздней активации сплиттинга

ivan 1 Comment

Вот в одной конторе есть ситуация с поздней активацией сплиттинга.

Открытые позиции, созданные с момента активации отказываются выравниваться: говорит, что GLT0002 и хоть трава не расти.

Методов несколько.

Наиболее цивилизованным (вроде бы) является процедура миграции, там есть определённый сценарий "Subsequent Implementation of Document Splitting". Инструмент миграции (будто бы) является особой услугой – но на сайте как-то невнятно всё написано. Сами пумпочки этой функциональности в SPRO по этому поводу начинают спрашивать какие-то лицензии.  Боязливо ввязываться в такие действа. А мне-то хотелось всего лишь самому кнопочки понажимать…

Самым нецивилизованным способом является ручное струяченье записей сплиттинга в соответствующую таблицу. Тоже боязливо – за изменение таблиц SAP.

В качестве баланса между ними можно использовать метод, в котором запускаются поочерёдно три волшебные служебные программы в SA38.

Простые документы нормально обработались, но вот один из них споткнулся с расстройством настроек по сплиттингу. По счетам ГК – платёж, а по виду документа – фактура. Система встала в позу, и я её хорошо понимаю.

Так что потребовалось изменить настройки, прогнать документ, вернуть настройки обратно.

Каждый документ пропихивать вручную – сомнительное удовольствие, но требуется ли писать мега-программу (впрочем простую и небольшую), вызывающую три волшебных программы, особенно с учётом возможных раскоряков по настройкам… ?

Дату активации сплиттинга в продуктивной системе, так сложилось, что никто точно не знает. Забавен быстрый способ по которому это дело можно посмотреть… Узнаём имя ракурса, по которым проходит такая настройка, затем в системе настройки в служебной таблице ищем запросы, связанные с этим ракурсом. Осталось по журналам транспортной системы посмотреть дату импорта запроса.

С полученной датой активации можно отфильтровать таблицы открытых позиций контрагентов по полю CPUDT для пущей надёжности.

Получено число порядка четырёх сотен. Это не много, но и не мало…

Проводки между филиалами – БЕ против БС

ivan Leave a comment

Видел несколько вариантов реализаций большой организации с филиалами:

  • Несколько балансовых единиц
  • Только одна балансовая единица и несколько бизнес-сфер 

Я для себя дилемму решаю таким образом – разные юридические лица должны иметь разные БЕ.

(далее…)

Прокси-сервер в ABAP

ivan Leave a comment

Если вы из программы на ABAP пытаетесь получить веб-контент через HTTP, то соединение будет производиться не с компьютера клиента, а с сервера приложений. В зависимости от конфигурации локальной сети вам может понадобиться пробираться через прокси-сервер (иначе потребуется прямая видимость сервера или NAT).

При оформлении HTTP запроса можно непосредственно указать прокси-сервер:

Пример вызова HTTP

Однако здесь есть пара моментов. Во-первых: “прошитость” настройки в коде (не приветствуется), а во-вторых: нет авторизации.

Глобальную настройку HTTP-прокси можно обнаружить в транзакции SM59:

Прокси в транзакции SM59

И там уже в появившемся окошечке можно указать не только сервер/порт, но также и логин/пароль для авторизации.

Почему исходники ABAP в скриншотах

ivan 1 Comment

Если вы тут регулярно посматриваете, то могли заметить, что основная масса исходного кода показана скриншотами. Это не защита от копирования. Связано это с тем, что инструменты для публикации иногда очень вольно могут коверкать эти исходники (не только при подготовке публикации, но и потом — при редактировании).

Инструмент может и строки склеивать, и пробелы лидирующие для "лесенки" убирать, и цветовая разметка страдать — это всё требует подхода, имеет нюансы и даже требует владения HTML.

Много раз видел побитые таким образом исходники на ресурсах типа SDN и иже с ними. Очень расстраивает.

Скриншоты же делаются проще, и с ними почти ничего не происходит — и голова не болит. Если вдруг подберу удачный инструмент или подход — то ситуация изменится.

Проверки при создании контрагента

ivan Leave a comment

Если мы создаём контрагента(дебитора/кредитора) в системе, то к нему очень рекомендуется делать базовые проверки, для контроля.

Самая примитивная проверка – проверка на дублирование через уникальный налоговый номер (ИНН, РНН …). Обычно для этого используется поле типа STCD1.

Для реализации у нас есть в CMOD пара очень тривиальных расширений:

SAPMF02D — Программы пользователя: основные данные дебиторов
SAPMF02K — Программы пользователей: основные данные кредиторов

Вот примерный кусок кода (для кредиторов) который нужно вставить:

Пример расширения проверки

Надеюсь в этом коде даже объяснять ничего не надо…

Для дебиторов – почти то же самое, только имена полей/таблиц чуточку подправить…

Торрента полезна в хозяйстве

ivan Leave a comment

Сложилась такая ситуация: сотруднику в командировке понадобилось получить большой объём данных, и чем раньше – тем лучше.

Дано: объём данных 10гб. Входящий канал – 200к, есть некоторые ограничения. В офисе исходящий канал 50к, ограничений нет. На крайний случай есть домашний канал – 100к исходящего канала.

Решение первое: порезать по частям и заливать на бесплатные файлопомойки.

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

Решение второе: порезать по частям и поднять файлы на локальном http/ftp сервере.

Если необходимо разделить файлы на два исходящих канала – требуются дополнительные движения извилин и мониторинг.

Для надёжности требуется контроль целостности. Если контроль не сошёлся – требуется перекачивать весь том. Если в архиве большой файл размазан на несколько томов, то проверка целостности может потребовать все тома. Требуется работа мозга или рук для правильной нарезки и выверки. Контролировать нумерованные тома легче, чем отдельные файлы – но это не значит что их не надо контролировать вообще.

Решение третье: торрента и p2p-соединения.

1. На исходящем канале поднимается торрента (в виде мю-торрента, легковесного клиента).

2. В мю-торренте подбирается исходящий порт, видимый для клиента. В случае ограничения можно выбрать “полезные” порты: 80, 8080, 443 и подобные. Если требуется, порт необходимо открыть(прокинуть) на мопеде через “порт-форвардинг”. Порт тестируется (получателем) через браузер до достижения успешного результата в виде “инвалид реквест”.

3. В качестве вспомогательного инструмента можно воспользоваться сервисом типа динднс, это безусловно полезно если провайдер интернета  даёт динамический айпи-адрес. Да и вообще динднс в хозяйстве может пригодиться.

4. Создаётся торрент-файл для целевой папки. Треккер в него прописывать не надо (впрочем можно копнуть сюда). Добавляем веб-сиды для “раздающих”.

5. Торрент-файл отправляем (по почте) получателю и подкладываем в мю-торрент, перехешируем и запускаем.

6. На входящем канале получатель также ставит мю-торренту и добавляет торрент файл. Сразу всё может и не зафырчит, следует вручную добавить раздающего на закладке Пиры. Требуется указать его в виде ip-адрес:порт (см пункты 2 и 3).

7. Затем с файлами и торрент-файлом перемещаемся к домашней точке раздачи. Пробегаемся по пунктам 1-2-3-5.

Результат – достигается суммарная исходящая скорость 50к+100к, нет особой возни с балансировкой, томами и файлами, контроль целостности достигается микроблоками и легко исправляется. Архивация не требуется в целях контроля целостности, только для сжатия данных. Папка с тучей файлов или один большой файл – также особого значения не имеет.

Другие решения: например, можно попробовать работать через файлосинхронизационные сервисы совместно с хранилищами – хостинг, лайв, гугл, дропбокс и так далее по списку.