SSH Keyを作成してGitHubなどに接続してみる - Qiita

大事なことなので。

SSH Keyを作成してGitHubなどに接続してみる - Qiita: GitHubやGitLab上のリポジトリへgitコマンドでファイルをpushする時に、上手く接続出来なかったのでSSH Keyの作成からやり直してみました。これはその作業ログなので自分用忘備録です。 [参考資料] Connectin...

OneDriveをUbuntuで（20.04 LTS）

 備忘録

• 本家
  Github　　　
  abraunegg / onedrive
  https://github.com/abraunegg/onedrive
   
• 参考
  blog.PanicBlanket.com
  https://blog.panicblanket.com/archives/5391

 

実行中の状況確認

 onedrive --monitor

 

 

 

 

 

 

 

        

     同期中の状況が見える。

 

Test

ちょっとしたテスト。

https://play.google.com/store/apps/details?id=co.vero.app

文字だけの投稿が今のところできないけど、考え方を変えて、文章の投稿はBlogでしてそれを共有するって事ではどうだろう？

設計書ってさ。

ある職場で、設計書書いてた時の話。
レビュー時の指摘事項で。
・処理の階層が深すぎるから、そうならない様にして。
・サブ処理として書かれると、判りづらいから、そうならない様にして。

で、思ったのが…
「…それ、相反してなくない？」

フラットに書いたら、深くならざるを得ないと思うし、自分としてはそうならない様に…と思って、サブ処理の記述にしたんだけど。

で、既に有る設計書見てみたらば、
・処理のブロックは罫線引いて区別する。
　（当然、ネストもそれで表現）
・結果として、「項番が深くならない」。
という事だったんだけど。

（深くしないのは、項番であって処理ではないって言うね (^_^;)）

ただ、詳細設計書として考えた時に、これをそのままコード化なんてしないから（したら、読み辛くってしょうがない）、サブ処理に分けるんだけど、そうなったら、設計書とコードの乖離が発生しないかな…と。

個人的には、もうこう言うドキュメント（設計書）は書かない方向で良いんじゃないかと思ってる。
勿論、「するべき事」を書いたドキュメントは必要では有るけれど、コードと１：１になる様に記述する設計書は無くてもいいと思う。
改修しても、コードだけ修正してドキュメントなんてメンテしないだろうし。

例えば、バグが出て改修しても、改修後のテストはしても、改修に先立ってドキュメント修正→レビュー→改修なんて手順踏んでるところって（自分が見た限り）無いと思う。（個人的にやってた事は有る）
ドキュメント大事。と言うなら、本来そう言う手順を踏むべきだとは思うんだけどね。

あと、ドキュメントのフォーマットもね。会社毎とか、ベンダ毎に違うのも……どうにかならんのかな。
あんなに「業界標準」が好きな業界なのに、こういう所を標準作らないってのもね。

結局、大手がメインフレームやってた頃のやり方をそのままSAPに持ってきてるから、そんな事になってるんよね。

むぅ。どーーにかならんもんかな。

Spotify Discovered Weekly

自宅にいる時に音楽聴くのは、殆どSpotifyなんだけど、 "Discovered Weekly"が一々ツボを押さえていて楽しくてしょうがない。

"Discovered Weekly"ってのは、今まで聴いた曲の傾向から勝手にPlaylistを作ってくれるんだけど、知ってるバンドやミュージシャン以外も選曲されていて
「あ、こんなのも聴いてたな」
なんて発見も有ったりしてる。

どちらかと言えば、80,90年代のRockが中心でボカロ曲出て来てないけど、恐らくそれは、Spotify自身にそのジャンルがラインナップされて無いからじゃないかとおもう。

どちらにしても、週末。どんな曲やバンドが有るのかちょっと期待してSpotifyを開けている。

やっばり、無駄な気がしてきた。

通勤にかかる時間と費用。

社員に定期代支給するより、通信インフラ調えてテレワークさせた方が人件費は抑えられると思うんだがな。

なんか最近、客先常駐って作業形態自体が無駄な気がしてきた。

極論すれば「予定通り、予定された品質のもの」が納品出来れば誰も困らん訳で。

恐らくそれが解っているにも関わらず、踏み切れないのは、





単に面倒臭いだけ

何じゃないかと思ってみたり。

SAPでの開発って…

SAPの開発の仕事をずっとしていて、今更ながらに感じるのは、

「今の大半の企業のSAPの使い方は間違っているんじゃないか？」

と言う事。

殆どの企業は、自社の業務にSAPを合わせ様としていて、だからアドオンが多かったりしている。

でも、本来のSAP(ERP)って言うのは、「業務改善」のはず。

その為に、SAPではベストプラクティスとテンプレートが有るのだけど、ベストプラクティスを導入していても、それに合わせての改善をしているところを見た事が無い。

業務ヒアリングしてFIT&Gapをする。とは言っても、「Gapが有るのはシステム。だからFitさせる為にアドオン」と言う方向性ばかりではないんだろうか。

それでいて、作ったアドオンの改修にはスピードを求めてアドホックな改修を入れるからメンテナンスし辛い物ばかり出来て来る。

system構築するのに、時間と金を掛けたく無ければ、systemに合わせる為の業務改善をするべきだと、最近思ってる。

Posted via Blogaway

2016年を迎えて。

さてさて。
世界はいよいよ混沌の渡を増してきた。
２０世紀は米ソと言う武力対立の中に有って、その傘の中にいれば「取り敢えず安心」だった。
今、そう言う対立項が無くなって分散した事であまり表に出てこなかった宗教の様な精神世界を基盤とした対立が中心になって来た。

さて…
これを如何にして収拾するのか。
少なくとも、中東に限って言えば銭金で動くわけではない事だけは確か。
宗教的な和解が出来れば一番いい。

で、中国。
日本を含めた欧米各国の対応ミスなんだろうね。
やすい賃金を先に立てて中国経済を立たせてしまった感は否めない。
結果として、今の極東地域での振る舞いに結びついてる。
共産主義を「捨てた」訳ではなない以上、「世界赤化」「拡張主義」はいずれ出てくる事を考えるべきだった。

今年は昨年以上に混沌の度が嫌でも増して、そのままの状態で2017年を迎える可能性も否定できないよね。

Posted via Blogaway

久々に…。

久々に投稿。

スマフォからのアプリ経由での投稿のテスト。

今更〜？

今日(ってか、昨日だな)の昼にうちの会社の営業さんが来て、「一度、(無呼吸症の)病院で診察してもらって下さい」とか言われたんだが…最初にその事を話したのって二年前やよ？
それまで、放ったらかしで、しかも、行った先には「言わないで」と言い。うつらうつらしてれば「居眠りすんな」と言い。

んで、今更病院？
じゃあ、今迄自分が「無呼吸症で…」って言ってたのは、「居眠りを正当化するための方便」とか思ってたの？

なんかな〜。

でも、病院行くのも自腹でしょ？
考えちゃうよね。

で、こういう事が有るとさ、会社ってホントに社員の事どう思ってんだろ？って思っちゃうんだよね。

今迄もさ、幾つかの会社にいたけども、その度に思うのはさ、
「社員がほんとに困ってる時に、会社は助けてくれない」
なんだよね。

ふぅ。
ヤレヤレ。

アプリがどんどんデカくなる〜♪

どもです。

Firefoxもデカくなって来てるね。
いまの26.0のパッケージサイズが約26MB。
24.0辺りから直接更新出来ずに、
　アンインスコ→インスコ
じゃ無いと対応出来なくなって来てる。(-_-;)

なんで、MozillaはFenneck（スペル違うかも）の開発止めちゃったんだろ？
Alphaの時だかにPCにインスコした事が有って、触った感じなかなか良さそうだったんだけとね。

元々Firefox自体、ブラウザに特化して軽量化を狙った筈なのに今じゃあ結構肥大化したソフトに成っちゃったよねぇ。

スマフォのアプリに関して言えば…って何度も書くけど、サイズに制限かけなきゃやって行けない状態になりつつある気がする。で、その「制限をかける」をユーザサイドでしなきゃいけないのが現状。
実際、Androidの構造の故らしいけど「内蔵」と「外部」と言うストレージ構造をどうにかしないと、その内「どのアプリもアプデ出来ない」なんて事にもなりはしないかと思ってる。

実際、もう既にGMail、Google+、Mapのアプデは諦めてる。けど、しゃーない入んないから。

ふぅ。

では〜。

小さく想い悩む。

いや、大したことじゃないんだけど。

半蔵門線と千代田線とで乗換がある時に、いつもどこで乗換えるのがいいのか…ちょっと考えたりする。

おそらく、乗換の時間も、目的地までの時間も、殆ど変わらないと思うんだけど、何となく…考えちゃって券売機前で一瞬固まるんだよね。

半蔵門線と千代田線て部分部分で直交していて駅として被んないからの悩み…なのよね。

今回は、大手町乗換。

だけど、既に「表参道の方が良かったかな」なんて思ってる。orz

スマフォってさあ…

でもです。

Google+にPostしようとして、そこそこ長くなったので、Blogにしました。

いやー、Android Firefoxも今回のVersionで25MBなんてサイズだし。
旧Virsion を一旦UnInstalせにゃ入れられんのよ。

Chromeは？って言われそうだけど、PreInstallのアプリってSDに移動できんからダメなのよ。
Chromeの最新Versionが27MB、PreInstallされてるVersion(18.0)が2.4MB。
最新VersionをInstallすると、単純計算で29.4MBの内部ストレージを消費する‥って何もできなくなる！orz
Google+とGMail は使用頻度高いしアプデした方が確実に使いやすのが分かってるからしてるけど、どっちもSDに追い出せなくって‥ねぇ。

因みに、Google+(Ver.4.12) は、アプリのサイズだけで23.13MB。
GMail(Ver.4.6)はアプリのサイズだけで6.8MB。
ホントは、Mapもアプデしたいんだけど現在（Ver.6.14.2)はアプリだけで5.43MB。最新Ver(7.3.0)は、Downloadサイズが6.9MB、PreInstallだから、これも6.8MB + 6.9MB で、13.7MB。

Root取ったら？って話もあるけど、今の自分の端末(Willcom DIGNO Dual(京セラ))ではRoot取れたって話は無いらしい、人柱になれる程金銭的に余裕もないのサ。

という訳で、チマチマやりくりしてる状況。

メーカーサイドでいろいろいれてくれるのは分かります。ユーザーが手にとってすぐ使えるようにって配慮。

でも、フィーチャフォンと違って、アプリはアプデするのが普通。しかもほとんどの場合、アプデする度にサイズは大きくなるのも普通。
そう考えたら、PreInstallのアプリに手を出せないって状況は、長い目で見ればユーザーの利便性に寄与していない事にならないんじゃないかと思う。
PreInstallのアプリは入れてもらってもいい、でも、ユーザーの自己責任でUnInstall出来るようにはしておいて欲しい。ましてや、アプデするのに更新とか言いながら実質旧Version を動かないようにして新Version をInstallするってやり方は誤っていると言ってもいいんじゃないかと思う。

でなきゃ、十分すぎるほどのサイズの内部ストレージを用意するか…だね。
少なくとも、 内部ストレージ 1GB ってのはもう、少ないと思う。せめて2GBは欲しいな。

という訳で、チマチマやるしかないんですわな。

でわ〜。

ABAP boolc( log_exp )

どもです。

久々の更新。

今回は、ABAP ネタを少し。


みなさんは BAPI 使ってますか？
最近は、Batch Input よりもBAPI を使って伝票作ったりすることも多いんじゃないかと思います。
というか、個人的にBatch Input は使う頻度を下げて行きたいと思ってます。

ま、それはそれとして。

伝票の生成を行う系統の BAPIを使っていて一番面倒なのが

 　使う項目について、別の構造体やテーブルにフラグを設定する必要がある。

という点。
まあ、これが予め決まっていて「それ以外無い」 なら決め打ちで 'X' しちゃえばいいんですけどユーザーのアクション（数値などの設定）によって使う/使わないが決まる場合、どうしてもこんな処理をしなきゃいけません。

IF L_GENERALDATA-DESCRIPT2 is initial.
     L_GENERALDATAX-DESCRIPT2  =  space.
ELSE.
     L_GENERALDATAX-DESCRIPT2  =  'X'.
ENDIF.

※わざと冗長に書いてます。

これは、固定資産のBAPIの一部です。
やってることは、 DESCRIPT2 に何か設定されていれば GENERALDATAX の DESCRIPT2 に ’X' を設定する。
と言うもの。

多かれ少なかれ、 BAPI で処理を記述するとこういった部分が出てくると思います。

自分も最近こういった記述をすることになって、「面倒だな〜」と思いながらものは試しにと

もっと簡単に記述できるんじゃないか

と思い Help を漁ってみました。例えば、Lines のような関数でもあれば…なんて。

そうしたらば、見慣れない関数が、

Boolc
Boolｘ

 これは、こんな風に記述します。

L_GENERALDATAX-DESCRIPT2 = Boolc( L_GENERALDATA-DESCRIPT2 is initial ).

おお！一行で書ける！

つまり、括弧内の論理式が 真の場合、左辺に ’X' を返し、偽の場合、左辺に空白を返します。

　　便利ーーーーー！

いままで、 IF でちまちまやってたのが嘘みたい！

まあ、どっかで出たんでしょうね要望が。
　「ちまちまやってられんゾ！ (#ﾟДﾟ)ｺﾞﾙｧ!!」

かどうかは、わかりませんが。

あ。因みに（大事なこと）、パッケージの状況によってはこれ（Boolc/Boolx）が使えない場合もあるのでご了承を。

と言う訳で、今日はこのへんで。

では〜。

生存確認

どもです。

生存確認です。
今度、もうチョッとまともに書きますね。

因みに、この投稿はBlogger App からの投稿です。

では～。

「ガッチャマン」の事（映画レビューじゃないよ）

どもです。
前回の更新から、約3ヶ月ぶり…。わはは。

で、「ガッチャマン」です。
往年のアニメ作品て言うかTV番組の実写映画化。

こちらの予告も観ました。


うん。まあ、悪くは無いんじゃない。

最初、この映画のスチール見たときは、「タイバニ」方向を向いているのかと思ったんだけどねぇ。

でもYouTubeのコメにも有るように、「なんか違う」感はありますね。
特に自分のようにリアルタイムで観ていたら尚更。

で、その 「なんか違う」感ってなんだろうと考えたら、やっぱりカン違いしてるんじゃないかと。

ガッチャマンって、端的に言えば「戦隊」なんですよね。

でも、予告見る限り映画は「戦隊ノリじゃない」んですよ。

いや、人間ドラマもあるし、派手なアクションもあるし、そういう部分では良いと思うんですけど目線が完全に「大人に観てもらう」事を意識してる。

でもねぇ。

今の大人（特に40代後半から５０代前半）はリアルタイムにオリジナルアニメを見てる層なんですよ。

全然、ガッチャマンなんて見たこと無い（年齢的にもっと上の）層なら、今回の映画でもいいと思うんだけど、リアルタイムに観た層以降について言えば、

「なんか違う」

と…。

うーーん。タツノコさん、いっそのこと次に御社のアニメ作品を実写化するなら、東映の戦隊スタッフにお願いしたらいいんじゃない？



てな、わけで「まだ、観てもいない映画に色々言う」でした。


では〜〜。

[SAP] eCATTのこと

どもです。

まさかの連投。大丈夫か > 自分


えと、今
「今後の作業で使うから」
と言う理由で　eCATT の勉強してます。

CATTと言うもの自体、話には聞いていたけど使った事が無かったのでいい機会だと思ってSAPのOnlie Helpを中心に調べてるんですが…イイなぁ…これ。

いや、何がいいってスクリプトとデータ用意すれば自動でやってくれるんですよ。

で、こう思うんです。
「なんでどこも使わないんだろう？」


答えは簡単。
「テスト結果にスクショが付かないから」

恐らくこれ。

いままで関わったプロジェクトでテスト（単体、結合問わず）と言えば　ー＞ スクリーンショット。
これ必須。

つまり、テストの結果として
「検証可能な資料」を残す、と言う意味で「スクショ必須」なんですね。

でも、eCATTの場合、テスト結果はLogの形で保存される。
んだけど、これ「見方が分からない」と検証できないんですね。

で、実はeCATTなんて誰もマトモに使って居ないから、テスト結果としての「Logの見方が分からない」んですね。
今回のeCATTの使用はあくまでも大量データ投入であってテストの為じゃないんですね。


ううーーーん。
ハッキリ言って、イチイチスクショ取る単体テスト。
その後、Excelにまとめるんだけど、その時間と労力って、投入しただけのものは有るんだろうか？
なんて思ったりするんですね。
SAP（と言うかABAPというか）にはカバレッジツールなんかも有るんです。ですが、これも有効活用されているとは言い難い状況。

テスト工数を削減するんなら、こういうツールを積極的に使って見ればいいのにねぇ。


 と言う訳で、まあ、お勉強はまだ続きます。


では〜。

「人類の歴史を変えた発明１００１」

どもです。

最近、図書館から借りてきて、「大当たり」だった本を紹介します。



人類の歴史を変えた発明1001

とにかく、一家に一冊あってもいい程の内容。

紀元前260万年頃の石器に始まって、最後は2008年の大型ハドロン衝突型加速器までが年代ごとにまとめられています。
ほぼ1ページ1項目なのでそれぞれの解説はそれほど詳しくは無いものの、ページをめくれば「ほ〜っ」「へぇ〜っ」ってなること請け合い。

で、最後が２００８年…なので当然知っているものも出てきます、iPhoneとかブルーレイとか初代マッキントッシュとかね。
あと、意外なものが意外な年代に出てきたり（例えば、エスカレーターが1891年に出てきたり）
意外なものが意外なところに出てきたり（これは…ひみつ…読んだらいいよ）

考えてみれば、今の50代から40代後半頃（までかな？）は家庭に百科事典が有ったんじゃないかと思います。（少なくともウチにはあった）
自分なんかは、学校の教科書見る時間よりも百科辞典見てた時間のほうが長いんじゃないかと思います。でも、今はネットで調べ物は済むし、少なくとも紙の書籍であったものよりもずっと最新情報だしで、出版社ももうどこも出してないですよね。
でも、いつでもPCが使えるわけじゃないウチの子供らにしてみれば書籍の形で手元にあると暇つぶしに手にとって拾い読みしてますが、それで十分だと思うんです。
そうする中で自分ながらに発見とかがあれば、そういうモノって結構忘れないものですからね。
ま、話のタネにはなるんじゃないかと思うんです。


あと、大人が読んでもおもしろいし、ワンボードマイコンの頃からの事を知ってる人なら、この本の中の例えばハードディスク・ドライブのページで「おーっ、このデカイハードディスク使ったこと有るぞ」とかそういう話を”誇らしげに”出来ますよん。


個人的には、これ借りてきて子供たちがこっちの思惑通りに喰い付いてくれたことが一番嬉しかったりするんですけどね。　　へへへぇ。



てなわけで。

では〜。

ABAP: Loop AT 〜 ［INTO ｜ ASSIGN］（改）

どもです。

前回、書いた「ABAP: Loop AT 〜 ［INTO ｜ ASSIGN］」なのですが……
ごめんなさい、間違ってましたぁ

と、言う訳で修正したやつをUpします。
間違った奴は、自戒を込めて残しときます。


久々のSAPネタ。
忘れないうちに書いときます。

Loop AT [内部テーブル] INTO [構造体].

  AT NEW [コンポーネント].

  ENDAT.

ENDLOOP.

とした場合、 [コンポーネント]に書けるのは、[構造体]内の項目になります。
しかも、この書き方の場合、 [構造体]がこんな
 ITEM001     TYPE    C LENGTH 10
 ITEM002     TYPE    C LENGTH 10
 ITEM003     TYPE    C LENGTH 10
内容だとして、[コンポーネント]が ITEM001 だとすると、
AT NEW でブレイクすると AT NEW 〜 ENDAT 内で参照できるのは、ITEM001だけで
ITEM002以降については文字項目の場合 '*' が詰められて参照できません。

これが最初分からなくって、随分ハマりましたし、恐らくABAPでAT NEW とか「使いにくい」って感じてる人はこれが原因じゃないかと思います。

ところが。
LOOP AT 〜 にはもうひとつの記法が有るのはご存知だと思います。
そう！

LOOP AT [内部テーブル] ASSIGN <フィールドシンボル>.

この書き方の場合でも、先程のAT NEW の書き方がチョット違ってきます同様の書き方になります。

LOOP AT [内部テーブル] ASSIGN <フィールドシンボル>.

  AT NEW [コンポーネント].

  ENDAT.

ENDLOOP.

2013/4/1記
　先の”AT NEW [コンポーネント]”の記述で分かる通り、INTOでもASSIGNでも基本は同じ動作になります。従って、これ以降については、まるまる意味のない記述になります。

誤った原因は、”AT NEW” に続けて書くのが[コンポーネント]で有ることを失念したところ。
自分でテストPG書いた時に何を勘違いしたのか、

AT NEW <フィールドシンボル>-[コンポーネント].

 なんて書いちゃった。当然コンパイラからはエラーメッセージ出されます。
そもそも、書くべきは[コンポーネント]のみで、[構造体]等で修飾する必要も無いもの。

という訳で、これ以降については、「なんぞおかしなこと言っとる」って事で無視して下さい。

多くの方に見に来ていただいてるのに、ホントにすみません。
以後、気を付けます。


INTO では、AT NEW に書けるのは<構造体>内の1項目でしたが、
ASSIGN の場合は、<フィールドシンボル> そのものを書きます。

じゃあこれでどうなるかって言うと、<フィールドシンボル> の参照元の内部テーブルの構造全体がキーとして認識されます。

「…え？じゃあ…どうなるの？」

極端なことをいえば、<内部テーブル>内の全レコードがAT NEWの対象になります。
つまり、”必ずAT NEW”を通ります。
それじゃあ、NEWの意味が無いんですが、重要な点が2つ。

1. INTOの場合、指定した項目（先の例で言えばITEM001）以降の項目の参照ができませんでしたが、ASSIGNの場合、全ての項目の参照が出来ます。
2. 任意の複数項目を一つのキーとして使用することができる。

と言う事になります。

例えば、こんなの。

TYPES:
  BEGIN OF TYP001,                    " 内部テーブル構造体１
    ITEM001     TYPE C LENGTH 10,
    ITEM002     TYPE C LENGTH 10,
    ITEM003     TYPE C LENGTH 10,
    ITEM004     TYPE C LENGTH 10,
  END OF TYP001.

TYPES:
  BEGIN OF TYP00A,                    " ブレイクキー構造体
    ITEM001     TYPE C LENGTH 10,
    ITEM002     TYPE C LENGTH 10,
  END OF TYP00A.

TYPES:
  BEGIN OF TYP002,                    " 内部テーブル構造体2
    ITEM00A     TYPE TYP00A,          " ブレイクキー項目
    ITEM003     TYPE C LENGTH 10,
    ITEM004     TYPE C LENGTH 10,
  END OF TYP002.

DATA:
  TB001      TYPE STANDARD TABLE  TYP001,  " 内部テーブル1
  TB002      TYPE STANDARD TABLE  TYP002,  " 内部テーブル2(キー構造有り)
  KEY        TYPE TYP00A.             " キー退避項目
 
FIELD-SYMBOLS:
         TYPE TYP002.             " フィールドシンボル

* 既に TB001 にはデータが入っていてSORTまでされているとします
* ブレイクキー項目の有る内部テーブルにコピー
  TB002[]  =  TB001[].

LOOP AT TB002 ASSIGN .

  AT NEW  .
    IF -ITEM00A <> KEY.
*** ここにブレイク時の処理を記述（今回はWRITEします）
      WRITE: /1(10)   -ITEM00A-ITEM001,
              13(10)  -ITEM00A-ITEM002.

      KEY = -ITEM00A. " KEY項目の更新（これをしないとブレイクしない）
    ELSE.
      NEW-LINE.       " ブレイクしない場合、ただ改行だけ
    ENDIF.
  ENDAT.

  WRITE: 26(10)  -ITEM003, " 非キー項目はそのままWRITE
         39(10)  -ITEM004.

ENDLOOP.

これを実行するとこんな感じに出力される（はず）。

aaaaa   aaaaa  xxxxx yyyyy
               xxxxx yyy00
               xxxxx yyy01
aaaaa   bbbbb  xxxxx yyyyy
               x00xx yyyyy
abbbb   bbbbb  xxxxx yyyyy

キー部分がブレイクした時だけ出力されて、非キー項目はレコード毎に出力されます。

ちょっと面倒な感じもあるし、比較項目を２つ用意してLOOPさせながらIFで比較するって言う旧来のやり方と殆ど変わらない気もするんですが、 フィールドシンボルの場合AT NEW 内で
「全項目へのアクセスができる」
って所が個人的には
すげーーーーー！Σ(･ω･;|||
って単純に思っちゃたんです。（＾＾；

まあ、覚えておいて…どっかで使うこと…あるかな？？？？


では〜。

ABAP: Loop AT 〜 ［INTO ｜ ASSIGN］

どもです。

久々のSAPネタ。
忘れないうちに書いときます。

Loop AT <内部テーブル> INTO <構造体>.

  AT NEW .

  ENDAT.

ENDLOOP.

とした場合、 に書けるのは、<構造体>内の項目になります。
しかも、この書き方の場合、 <構造体>がこんな
 ITEM001     TYPE    C LENGTH 10
 ITEM002     TYPE    C LENGTH 10
 ITEM003     TYPE    C LENGTH 10
内容だとして、が ITEM001 だとすると、
AT NEW でブレイクすると AT NEW 〜 ENDAT 内で参照できるのは、ITEM001だけで
ITEM002以降については文字項目の場合 '*' が詰められて参照できません。

これが最初分からなくって、随分ハマりましたし、恐らくABAPでAT NEW とか「使いにくい」って感じてる人はこれが原因じゃないかと思います。

ところが。
LOOP AT 〜 にはもうひとつの記法が有るのはご存知だと思います。
そう！

LOOP AT <内部テーブル> ASSIGN <フィールドシンボル>.

この書き方の場合、先程のAT NEW の書き方がチョット違ってきます。

LOOP AT <内部テーブル> ASSIGN <フィールドシンボル>.

  AT NEW <フィールドシンボル>.

  ENDAT.

ENDLOOP.

INTO では、AT NEW に書けるのは<構造体>内の1項目でしたが、
ASSIGN の場合は、<フィールドシンボル> そのものを書きます。

じゃあこれでどうなるかって言うと、<フィールドシンボル> の参照元の内部テーブルの構造全体がキーとして認識されます。

「…え？じゃあ…どうなるの？」

極端なことをいえば、<内部テーブル>内の全レコードがAT NEWの対象になります。
つまり、”必ずAT NEW”を通ります。
それじゃあ、NEWの意味が無いんですが、重要な点が2つ。

1. INTOの場合、指定した項目（先の例で言えばITEM001）以降の項目の参照ができませんでしたが、ASSIGNの場合、全ての項目の参照が出来ます。
2. 任意の複数項目を一つのキーとして使用することができる。

と言う事になります。

例えば、こんなの。

TYPES:
  BEGIN OF TYP001,                    " 内部テーブル構造体１
    ITEM001     TYPE C LENGTH 10,
    ITEM002     TYPE C LENGTH 10,
    ITEM003     TYPE C LENGTH 10,
    ITEM004     TYPE C LENGTH 10,
  END OF TYP001.

TYPES:
  BEGIN OF TYP00A,                    " ブレイクキー構造体
    ITEM001     TYPE C LENGTH 10,
    ITEM002     TYPE C LENGTH 10,
  END OF TYP00A.

TYPES:
  BEGIN OF TYP002,                    " 内部テーブル構造体2
    ITEM00A     TYPE TYP00A,          " ブレイクキー項目
    ITEM003     TYPE C LENGTH 10,
    ITEM004     TYPE C LENGTH 10,
  END OF TYP002.

DATA:
  TB001      TYPE STANDARD TABLE  TYP001,  " 内部テーブル1
  TB002      TYPE STANDARD TABLE  TYP002,  " 内部テーブル2(キー構造有り)
  KEY        TYPE TYP00A.             " キー退避項目
 
FIELD-SYMBOLS:
         TYPE TYP002.             " フィールドシンボル

* 既に TB001 にはデータが入っていてSORTまでされているとします
* ブレイクキー項目の有る内部テーブルにコピー
  TB002[]  =  TB001[].

LOOP AT TB002 ASSIGN .

  AT NEW  .
    IF -ITEM00A <> KEY.
*** ここにブレイク時の処理を記述（今回はWRITEします）
      WRITE: /1(10)   -ITEM00A-ITEM001,
              13(10)  -ITEM00A-ITEM002.

      KEY = -ITEM00A. " KEY項目の更新（これをしないとブレイクしない）
    ELSE.
      NEW-LINE.       " ブレイクしない場合、ただ改行だけ
    ENDIF.
  ENDAT.

  WRITE: 26(10)  -ITEM003, " 非キー項目はそのままWRITE
         39(10)  -ITEM004.

ENDLOOP.

これを実行するとこんな感じに出力される（はず）。

aaaaa   aaaaa  xxxxx yyyyy
               xxxxx yyy00
               xxxxx yyy01
aaaaa   bbbbb  xxxxx yyyyy
               x00xx yyyyy
abbbb   bbbbb  xxxxx yyyyy

キー部分がブレイクした時だけ出力されて、非キー項目はレコード毎に出力されます。

ちょっと面倒な感じもあるし、比較項目を２つ用意してLOOPさせながらIFで比較するって言う旧来のやり方と殆ど変わらない気もするんですが、 フィールドシンボルの場合AT NEW 内で
「全項目へのアクセスができる」
って所が個人的には
すげーーーーー！Σ(･ω･;|||
って単純に思っちゃたんです。（＾＾；

まあ、覚えておいて…どっかで使うこと…あるかな？？？？


では〜。