ABAP2XLSX

Началось всё с осмотра одной разработки – abap2xlsx. Ещё один движок экспорта данных в Excel. Движок как движок – есть преимущества и недостатки.

Фишки:

• Экспорт происходит через  обработку XML.  Никаких OLE, CSV, HTML, макросов и прочих костылей
• Теоретически – самый быстрый вариант при большом количестве данных
• Теоретически доступны все возможности, если написать к ним верные обёртки – они не все написаны, но кое-что планируется по roadmap
• Клиент не участвует в обработке – файл полностью генерируется на сервере

Недостатки:

• Пока только развивается – ещё не совсем понятно, что из этого выйдет
• До поддержки шаблонного подхода похоже ещё очень далеко – ещё несколько мажорных версий по roadmap (если я правильно понимаю фразу “v.3.0 — Add xlsx reader”

Выводы:

• уже можно использовать в качестве замены чистому OLE-подходу
• не годится для Excel 2003 в общем случае – требуется установка адд-она на клиентскую машину

Ничего особенно удивительного, но это погрузило меня в другое – целую кучу другого.

http://code.google.com/p/abap2xlsx/

Google Code

 

http://code.google.com/

Больше напомнило, чем удивило. Goole Code является альтернативой старому SourceForge. Просто и доступно, как и всё что Гугл делает. Что там есть:

• страница проекта
• документация в стиле Wiki
• раздел файлов для загрузки
• баготреккер
• репозитарий на базе SVN

А что ещё нужно для коллективной работы над исходниками?

Google Wave

 

http://wave.google.com/

Данный способ колаборации анонсирован уже давно, но открыт публично совсем недавно. Однако его вполне можно использовать и для обсуждения моментов вокруг проектов. Волны -  как заменитель тредов на форуме или чата. Почему бы и нет.

 

ZSAPLINK

 

http://code.google.com/p/saplink/

ZSAPLINK – это движок, через который можно обмениваться разработками. Интересный проект со своими заморочками.

Основная задача: формировать что-то вроде запросов – некоторый файл в формате XML, в котором лежат объекты разработки (отчёты, классы, таблицы, группы функций и так далее).

Этот файл можно получить из одной системы и развернуть на другой системе.

Как альтернатива файлам запросов имеет некоторые преимущества:

• не требует деблокирования
• не требует вмешательства администатора системы и транспортной системы
• работает также и с локальными объектами
• прозрачность файла-контейнера – формат XML
• контейнер можно нормально класть в репозитарий (SVN) со всеми вытекающими
• контейнер дополняем

В качестве заморочек можно отметить, что движку неизвестны все типы объектов разработки. К основным единицам разработки сделаны “плагины”, а к остальным плагины пока никто не написал – к таким можно отнести например объекты авторизации, диапазоны номеров и другие мелочные штучки.

Ещё из заморочек можно упомянуть необходимость ручной активации всех перенесённых объектов.

Тем не менее — полезная штука.

Есть к ней и альтернатива ZAPLINK – что-то похожее, но со своими заморочками.

Шахматы – ZSAPChess

 

http://code.google.com/p/sapchess/

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

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

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

SAP-Commander

 

http://code.google.com/p/sapcommander/

Двух-панельный файловый интерфейс с базовой функциональностью – F5-F6-F7-F8.

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

ZAKE

А это просто штука, которая позволяет работать с SVN-клиентом. Работает в паре с ZSAPLink.

В самом ABAP необходимости в SVN/CVS необходимости нет, потому что:

• Исходный код и прочие объекты репозитария уже централизованно хранятся на сервере, а не локально
• имеется версионный контроль
• имеется система переносов

А пригодиться это может в двух случаях:

• если ввязаться в какой-то проект на том же Google Code
• если есть несколько систем с большим перечнем общих разработок универсального характера – тут синхронизация через SVN поможет

Пока такой необходимости нет.

ABAP Report Wizard

 

http://code.google.com/p/abap-report-wizard/

Забавный генератор отчетов в виде мастера.

Основные шаги:

1. С помощью визуального редактора добавляются таблицы и выстраиваются связи между ними
2. Галочками отмечаются поля, которые необходимо вынести на селективный экран
3. Галочками отмечаются поля, которые надо вынести на экран

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

Заготовка содержит:

• Селективный экран
• Описание внутренней таблицы
• Выборку данных (select … inner join …)
• Подготовку и вывод ALV-grid

Ну а затем можно уже и напильником.

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

Есть к нему ещё более специализированная штука (ABAP Join Wizard), которая только выдаёт заготовку сложной выборки – описание внутренней таблицы и соответствующий оператор select.

Вот такая забавная штука.

Нашлась случайно фишка по получению случайного числа:

 

По большей части забава для написания примитивных игр на АБАПе, но может быть использована в алгоритмах криптования и рядом с ними.

А нашлась такая цитатка в книге “ABAP Cookbook, Programming Recipes for Everyday Solutions” за авторством некоего James Wood.

В остальном в бесплатной главе не нашел ничего особенного.

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

А возможно там есть кое-что интересное, очень хотелось бы полистать вот это:

3.3 Introspection with ABAP Run Time Type Services …………………… 98
3.3.1 ABAP RTTS System Classes ………………………………………. 99
3.3.2 Working with Type Objects …………………………………….. 100
3.3.3 Defining Custom Data Types Dynamically …………………… 102
3.3.4 Case Study: RTTS Usage in the ALV Object Model ……….. 104

 

7.2 Transaction Processing with SAP LUWs … 235
7.2.1 Introduction to SAP Logical Units of Work … 235
7.2.2 Bundling Database Changes in Update Function Modules … 239
7.2.3 Bundling Database Changes in Subroutines … 242
7.2.4 Performing Local Updates … 244
7.2.5 Dealing with Exceptions in the Update Task … 245

 

7.5 Tracking Changes with Change Documents ……………………………. 268
7.5.1 What Are Change Documents? …………………………………. 269
7.5.2 Creating Change Document Objects ………………………….. 269
7.5.3 Configuring Change-Relevant Fields ………………………….. 273
7.5.4 Programming with Change Documents ……………………… 274

М-м-м…

Как это нередко бывает в системе требуются собственные справочники.

Первым делом делается соответствующая таблица ZRATES в транзакции SE11, затем она заполняется данными и используется в нужных разработках (Z-программах, расширениях, средствах поиска и так далее).

Потом уже в связи с тем, что записи надо изменять, включать в перенос – создается ведение таблицы посредством генератора.

Однако рано или поздно надо её отдавать конечному пользователю, а так как проверок в SM30 практически никаких не делается, то вероятность ошибки имеется.

Даже в самой примитивной таблице-справочнике в стиле [код + название] можно делать логические ошибки – добавлять записи с одинаковыми названиями. Ключом понятное дело является Код, а проверка на уникальность стандартно делается только по ключу. Так как же запретить пользователю вводить неверные данные ?

(далее…)

Стыдно признаться, но я не использую (но стремлюсь использовать) такие конструкции:

ASSERT [ [ID group [SUBKEY sub]]  [FIELDS dobj1 dobj2 …] CONDITION ] log_exp.

Вот пример простого использования:

assert  i_debet = i_kredit.

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

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

(далее…)

В такой строке кода нет ничего удивительного:

delete adjacent duplicates from lt_table.

Здесь всё просто и понятно. Дубликаты удаляются, уникальные записи остаются.

Однако если попытаться с помощью добавки comparing удалять дубликаты только по нужным полям, то есть свои тонкости:

delete adjacent duplicates from lt_bseg comparing lifnr zuonr.

Тонкость первая: Дубликаты могут и не совсем удалиться. Удаление будет происходить только в сортированной последовательности. Таким образом результат будет слабопредсказуемым. То есть из последовательности А-А-Б-Б-А-А будет создана последовательность А-Б-А.

Тонкость вторая: Дубликаты удаляются после первого совпадения. Таким образом во внутренней таблице будет оставлено именно первое совпадение.

Следовательно вместо вышеуказанного примера кода всегда следует писать примерно так:

sort lt_bseg by lifnr zuonr zfbdt.
delete adjacent duplicates from lt_bseg comparing lifnr zuonr.

Больше полей в операторе SORT даёт большую предсказуемость и адекватность результата. Добавка сортировки по дате (ZFBDT) уточняет, что останется самая ранняя (первая) запись из всех .

Кое-что об основных счетах главной книги я уже говорил (тут: https://entropii.net/?p=317), а теперь поподробнее расскажу о массовом изменении счетов.

Счета массово можно изменить в транзакциях OB_GLACC11/12/13.

В качестве примера могу предложить задачу такую: расставить флаг “Просмотр отдельных позиций” на всех счетах, где он не стоит. Произошёл у меня такой “прокол”. Оказывается, что именно поэтому может не существовать строка проводки в таблице BSIS – раньше с таким не сталкивался.

(далее…)

Вот а теперь речь пойдёт об упрощенном доступе к ветвям SPRO, в том числе и к собственным.

Первая часть лежит тут: Кое-что о настройке SPRO (часть 1) – расширение SPRO и добавление собственных таблиц

(далее…)

Да, именно так. хотя SPRO и является основной транзакцией настройки, но и её тоже можно немножко настроить.

В качестве предыстории этой статьи я взял для себя несколько проблем:

Во-первых, в практике внедрения как правило появляются настроечные таблицы, которые нужно периодически вести в транзакции SM30. Для красоты и полноты картины они должны быть видны в транзакции SPRO.

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

В-третьих, иногда мне очень лениво  заходить отдельно в настроечный эталонный мандант. 

Изменяем SPRO своими руками

Для решения первой проблемы нам понадобятся две транзакции:

(далее…)