SAP ABAPインスタンスの禁則文字について

年一くらいでABAPインスタンスの禁則文字について確認する機会があるので、関係各位とやり取りした内容も含めメモ。

■結論

  • ABAP言語(フレームワーク)標準仕様として共通的なテキスト項目の入力制限は存在しない。
  • ABAP言語(フレームワーク)標準仕様としては、必須項目チェック、型チェック、外部キーチェック、ドメイン値チェックのみ
  • 上記チェック以外は、それぞれの「Dynproの入出力template」機能や、PAIでやるチェックロジックで対応
  • SAP関係者なら誰もが知る(?)エクスクラメーションマーク*1の件は、歴史的な経緯とおのおのの標準PGがそのようにしているだけ。
     ⇒この機能は、「Dynproの入出力template」機能で設定されている。

■「Dynproの入出力template」機能について
エクスクラメーションマークは入力した値が消えてしまって、結果として入力不可文字となってしまうだけです。
それ以外にも意味がありますが、Note:1015345にこの機能の詳細が書かれています。但し、標準Dynproのどの項目で使用されているかは、一つ一つチェックしないといけないとわからないです。
チェック方法は、スクリーンペインタのレイアウトエディタの入力項目の属性。
 (標準テーブルのどこかに保存されているかもしれませんが、そこまでは不明)

レイアウトエディタの画面ショットは下記参照。
この画面ショットの一番したにある、Without templateにチェックが入っていないとこの機能が有効です。
 (日本語だとなぜか「入出力項目なし」というテキストとなり意味不明。。)

f:id:nyop:20180415124945p:plain

■その他参考Note
Note:734353

Note:1108179

■その他

  • 入力すると文字化けするので、入力できても使用してはいけないものがある。
    ユニコードシステムの場合、APサーバは、UTF-16なんだけどサロゲートペアの文字をサポートしないため入力してはいけない
  • キーボードの直接入力というより、webサイトのコピペとかで発生 

文字化けについてはトランザクションコードSCPで各文字セット毎の利用可能文字を調査可能。

得意先コード、仕入先コード、品目コードについては番号範囲チェックが適用されるため、1文字目は半角英数以外はエラーとなる。
また、品目コードについては、「&(アンパサンド)」「 *(アスタリスク)」「,(カンマ)」は2桁目以降もエラーとなります。

 

もし嘘ついていたら突っ込んでくだしあ。

*1:先頭一文字目に!を入れるとそのフィールドの入力文字列が消える

SAPのライセンス体系変更(Indirect Accessに対する明確化)

SAPのライセンス体系変更が発表されました。


これまではユーザーIDベースのライセンス体系が中心で、システム間連携(Indirect Access)でRFC*1とかSOAPとかRESTとか諸々のEAIツールとか、それ以外のシステム関連とか、いろんなアクセス手段があるにもかかわらず、どこまでユーザーライセンスが必要なのか明確でなかったので、歓迎すべきことかと。


詳細は以下のJSUGのページに掲載されているのでそちらをご参照ください。

間接アクセス向けの新しいライセンス体系のお知らせ | ニュース | JSUG -JAPAN SAP USERS' GROUP-

 

ざっくりまとめると以下のような感じかと。

  • Indirect Access用のライセンス方式を新たに追加し、SAPシステム上に記録されるドキュメント(トランザクション)をベースに課金する。
    ドキュメント種類毎*2に係数があり、登録(Create)は課金対象だが、Read/Update/Deleteは課金対象外。IDOCとかもこの方式が適用されそう。
  • 従来のライセンス方式で既にSAPを利用している場合、新しいライセンスモデルに移行するか否かは、ユーザー側に選択肢がある。
  • 既存のライセンス(Named User単位)は、新しいライセンスに変更することができる。

 

従来、リアルタイムアクセスはライセンスがいるとされていた、参照系が課金対象外というのはありがたいですね。

一方IDOCなど、バッチの伝票登録系は課金対象になりそうなので要注意かと。

また、伝票系はある程度明示されてるんですが、マスタ系の取り扱いはどうなるんだろう、という疑問が。。

 

なお、本記事の記載はリリースを元にざっくり記載したもので、SAP社のの公式見解に沿ったものではありませんので、内容に誤りが有っても何ら保証できません。
くわしくはSAP社の営業さんに聞いてください。

*1:Remote Function CallというSAP独自プロトコル

*2:受注伝票、請求伝票、購買発注、サービス/メンテナンス指図。製造指図、品質管理、タイムシート、会計伝票、在庫。会計と在庫の係数が低い

TrackRで迷子対策

我が家の次男氏(4歳)は、遊園地で唐突に「とーちゃんバイバイ!」と走り出して迷子になったり(しかも親側が迷子になったと思っている)割とたちの悪い息子でして。

世間的に叩かれているハーネスとかも考えたのですが、流石に4歳にハーネスというのもなぁ、ということで別のツールを利用して割といい感じなのでご紹介。

www.kinakoneko.com

 

TrackR bravoって何?

最近、bluetoothスマホとペアリングして失くしたものを見つける系のガジェットがいくつか出ています。

TrackR bravoもその一つ。

 

  

機能としてはシンプルで、以下のようなもの。

  1. スマホbluetoothで繋がっているいると、スマホGPS+専用アプリで凡その位置情報を記憶しておける。
  2. bluetoothでつながっていると専用アプリから端末の音が鳴らせる。
  3. bluetoothでつながっていると端末のボタンを押すと、スマホの音が鳴らせる。
  4. bluetooth接続が切れるとアラートを鳴らせる。(設定次第、バッテリー消費増える)
  5. bluetoothで繋がっていない時に探索モードにしておくと、他のTrackR利用者のスマホが端末を検知すると場所が通知される。

 

1-4が基本機能で5はまだ利用者が少ないんでおまけな機能ですね。

鍵とかにキーホルダー代わりにつけて、見当たらない時に探す、というのが基本的な使い方かと。

 

迷子対策に使える?

子供のリュックにつけてみました。

f:id:nyop:20170305111907j:plain

 

基本的にはbluetoothで繋がっている必要があるので、つながっているかどうかで近くにいるかどうかを判断できます。

アプリの画面はこんなイメージ。

f:id:nyop:20170312094611p:plain

スピーカーボタンの周りのがbluetoothの接続状態の強さを表していて、どこで場所が確認されたかが上の地図で確認できます。

(場所の更新がアプリ立ち上げ都度では無いようなので、接続されていても場所が更新されないケースも。その場合はアプリを再起動すると最新化されます)

スピーカーボタンを押すと、端末の音がなる感じですね。

 

実際に使ってみた

次男氏には
「この丸っこいやつの音がなったら、とーちゃんが探してるってことだから立ち止まれ」
と教えた上で二週間ほど運用してみました。

 

結果、2度ほど行方不明になったのですが、割りといい感じ。

ショッピングモールで居なくなったときには、bluetoothでつながっているかで近くにいるかどうか分かるので、闇雲に探す、という感じではなくなりました。

 

端末から出る音はさほど大きくないので人混みでは聞こえませんが、音を鳴らすと
「とーちゃーん!ここだよー!」

と叫んでくれたので、すぐに見つけられたり。

 

接続が切れたときのアラートは今のところ設定していないのですが、お出かけの時だけ有効にする等すればより便利かも。

子供用のケータイを持たせるにはまだ早いけど、迷子が心配、と言った同じようなお悩みを持たれている人はお試しにどうぞ。

読書感想文ってなんやねん

先日、長男氏(小1)の小学校の面談で、

「感想を言ったり書いたりがあまり上手にできないですねー。」

と言われて、自分も昔そうだったし、それはそれでいいんじゃないか、と思っていたのですが、以下の五味太郎さんの記事を見てふと思ったこと。

netgeek.biz

そもそも、読書感想文って、以下2つの大きな壁があるんじゃないかと。

  • そもそも文章を読まされている
  • 感想を求められていない

そもそも文章を読まされている

読書感想文ってそのきっかけが強制的なんですよね。
例えば国語の教科書に乗っている文章であったり、宿題として本を読んで感想文を書いてこい、と言われたり。

与えられた課題に答えないと、とは思うけど、求められていることが理解できていないので、「別に読みたい文章でも無いのに、感想なんて無い」「ふーん」「別に」というのが小さい頃に思っていた記憶。

 

感想を求められていない

読書感想文で求められているのは感想ではなく、人にオススメする紹介文なんだと思うのです。

「私はこの本を読んでこう思いました。なぜなら、こういうところが素晴らしいと思ったからです。ほら、みんなも読みたいでしょう?」
みたいなことを求められているのではないかと。

Amazonのトップレビューをコピペすれば非常に良い感想文が出来そうですね!(ダメ

 

読書感想文の意義

結局、読書感想文で養われるのは
「大きくなって、別に好きでもないなんの思い入れもない商品を人に売り込まないとイケない時に役立つスキル」
なんだと思う。

 

長男に本や文章を読ませて感想を聞いても以下のような感じ。

 自分 「その文章読んでどう思った?」

 長男氏「おもしろかった。」

 自分 「どこが?」

 長男氏「主人公がxxしたところー。(文章後半の覚えてる所)」

 自分 「なんで?」

 長男氏「……」

 

全くもって興味ないんだろうなー。
別に読書感想文をうまく書け、とは思わないけど、まずは興味のある事や話に出会わせてやる所からだ。

N+1問題

 

N+1問題ってご存知でしょうか?

 

N+1問題 / Eager Loading とは - Rails Webook

 

N件のデータをSelectした後に取得してきた1件ずつをfor文で回して再度Select処理して、N件が大きくなればなるほどパフォーマンスに影響を及ぼすやつですね。

 

1+n問題って言ったほうがわかり易くないか?と心の底から思っていますが。

 

SQLレベルだとJoinとかINとかサブクエリでSelectするとかっていうので対応できるので、まぁ作る時にきちんと気にしましょうね、という話。

 

ではこれがどんな時に問題になるのか、というと、ここのところAPIエコノミーみたいに流行り言葉になっていますが、APIが固定されていると問題起きがち。 

 

一覧取得系のAPIと、詳細取得系のAPIが分かれて実装されていたりすると、クライアント側の実装によってはすごい負荷になります。

 

APIをリリースする側が大量アクセスで負荷が高くなったり、クライアント側で大量のアクセスが発生してブラックリスト入りしたりするので、結局公開側とクライアント側の双方で気をつけるべき話なんですが。

 

なんでこんな話をしているかというと、某S社のCRMの標準APIってgetlistとgetdetailを分けて実装になっており、先日Multi Thread Programmingのブログが上がっていて、そもそもの解決策ってそんなとこじゃないよなぁ、と思った次第。

Use ABAP Multi-“Thread” programming to deal with a real performance issue | SAP Blogs

具体と抽象

抽象。つまり。般化。観点。軸。切り口。パターン。

 

具体を知らないと抽象は理解できない。

 

二者択一と二項対立。

 

レベル感。視座の高さ。抽象度のレベル。階層化。to beとto do。

 

抽象と具体の往復。

 

精神世界と物理世界。

 

法則性と関係性は異なる。パターンと因果。

コンウェイの法則と企業情報システムアーキテクチャ

コンウェイの法則とは

Conway's law - Wikipedia

The organization of the software and the organization of the software team will be congruent, (中略)If you have four groups working on a compiler, you’ll get a 4-pass compiler

訳すと、

『ソフトウェアとチームの構成は一致する。4つのグループでコンパイラーを作れば4つのコンパイラーができる。』

もうちょっと意訳すると

アーキテクチャは組織に依存する

という話ですね。

以下の記事ではOSを例に挙げており、なるほどなぁ、と思ったり。

コンウェイの法則(Conway's Law) - Plan9日記

3機関が協業した複雑なMulticsに対して少数精鋭の研究者がシンプルに作ったUNIX。巨大化する商用UNIXと、原点回帰したPlan9Microsoftの発展と、MS-DOSからWindowsへの流れ。オープンソース革命とLinux

ソフトウェア開発においては、

開発チームの構成に依存してアーキテクチャが決まる為

逆に

アーキテクチャに応じて開発チームを構成すべき

とも言われたりします。

コンウェイの法則と企業情報システムアーキテクチャ

よくソフトウェア構成や開発について言及されるのですが、企業情報システムアーキテクチャにおいても同様だと思っています。

というかそういう例をクソほど見てきました。

旧来の企業情報システムは組織ごとにシステム化が進んできました。

財務会計、出納、外貨管理、人事、在庫管理、生産計画、生産管理、設計、受発注などなど。

1990年台後半からERPが流行り始め、システム統合が進みました。

ERPといえば

「ベストプラクティスがー」とか「BPRがー」とか言われますが個人的にはどうでもよくて、

アーキテクチャ観点での本質は

「組織間のデータの共用化」

だと思っています。

本来的に企業の組織は相互に影響し合う振る舞いが必要で、これまでバッチでインターフェース連携していたのが、ERPになって、データの連携が自動化・リアルタイム化されて、また、領域をまたいでデータが見られるようになった。

が、最近はSaasSoEやSoRといった考え方で、部門ごとにシステムを切り出す方向にトレンドが流れている。

多分その流れは止められないのですが、これをIT部門が弱い企業で進めると、かなりカオスになります。(というか、なっています。まじで。)

システムを分ける、というものの、一度ERPで実現したシステム間の相互連携は必要で、個別システム化にあたってのポリシーがないと、ツギハギだらけの増築を繰り返したいびつな旅館みたいなシステムが出来上がります。

利用言語、OS、MW、基盤の乱立、システム間連携のトポロジー複雑化、言われるがままに仕様追加してスパゲッティ化した仕様やコード、再利用なんてとんでもない。

企業の場合、アーキテクチャに応じて組織を設計する、というのは難しい話。

組織毎のシステム構築の流れが進む今、全体を俯瞰して計画する従来のEAを推進するような役割アーキテクチャに対する原則やデザインルールなんかを整備できない企業は、気がついたら90年代以前の手がつけられない情報システムの状態の再来を招くことになりそうです。