SAP公式テキストの紹介
こんばんは、カズヤんです。
今日は、SAPの公式テキストについて紹介します(決してSAP社の回し者ではありませんが、SAPシステムは大好きです。)
以前に下記のSAP NetWeaverのテキストを紹介しましたが...今回のはもっとすごい。
これです↓↓
Sap Netweaver As Abap?system Administration
- 作者: Frank Foese,Sigrid Hagemann,Liane Will
- 出版社/メーカー: Sap Pr America
- 発売日: 2011/11/30
- メディア: ハードカバー
- この商品を含むブログを見る
今回は公式テキストなので、もっと詳細な情報が掲載されています(750ページwww)。
最初のテキストをほぼコンプリートしたので、残りの細かいところをつめたいと思い、
購入しました。以下のSAP公式サイトからの購入が可能です。
私は、PDF版を購入しました。
下記3つのタイプから選択可能です。
PDF版・・・69.99$
ハードカバー版・・・79.95$
バンドル版・・・89.99$
ちなみにPDF版が断然オススメです。
ラップトップでブラウズできるし、スマホに入れとけばスマホでも見れます。
ごめんなさい。著作権上この先は見せられません...
ここにも著作権のこと書いてあります。
なんと驚くことなかれ、1冊69.99ドルという謎の高さwww
ただ、少し読んだところ、予想通りで以前読んでいた書籍よりも内容が詳しいっぽいです。トランザクションコードもBasisコンサルタントが知るべきほぼ全てのトランザクションコードが載っています。なので、100万円もかかるSAP社の公式トレーニングを受講するよりもはるかに安価でSAP Basisのインプットができます。
私の場合は、新卒でSAP Basisを7ヶ月目なので、基本的なトランザクションコードとメジャーな変更作業(クライアント移送、移送適用、ユーザ管理、ジョブ管理)は理解しているので、ほかのRFCとかシステムコピーとか、その辺を理解する上では有用なツールかと思います。
しかもありがたいのが、めちゃめちゃ練習問題がついています。SAPコンサル受験希望者にとってはこういったアウトプット可能な書籍はかなり助かると思います。
ただ〜し、毎度おなじみで申し訳ないですが、これも英語で書かれている電子書籍です。まあ、英語が苦手な方はハードカバーではなく、必ずPDF版の購入をお勧めします。著作権があるので、他人への譲渡はもちろん禁止ですが、本テキストを印刷したり、Google翻訳をかけながら読み進めることは十分にできるので、頑張って欲しいです。
SAP社の公式ページには、現在リリースされているほぼ全ての製品の公式テキストが市販されているので、ほとんどが１冊7000円ほどですが、絶対買った方がいいです。私は、この書籍コンプリートの後、SAP HANA Certificateの書籍を購入したいと思っています。
今後は、SAP BasisもSAP S/4 Hana向けのNet Weaver 7.5に向けた学習の必要性から、今回紹介したNet Weaver AS(Application Server)は完璧に理解して、SAP HANA DBの方の理解を深めないとSAP S/4 Hanaの認定コンサルタント取得は難しいと思われます。
今後もこのような学習素材をたくさん紹介していきます。
今日は、ここで失礼します。
CODE_INSPECTOR_DELETIONの対応
こんにちは、カズヤんです。
今日は、SAPシステムにて以前にポピュラーだったジョブである
CODE_INSPECTOR_DELETIONについて共有します。
結論として、不要なジョブなので削除作業を実施しました。
なお、SAPにおけるジョブ削除はTrcd:SM37にて実行可能です。
今回の作業では、
「CODE_INSPECTOR_DELETION」というジョブ削除作業を実施しました。
このジョブの特徴としては、CODE_INSPECTORという名前通り、ABAPコードの精査をするジョブが実行される時に同じジョブ実行ユーザにより日次実行で自動登録されるようです。
「CODE_INSPECTOR_DELETION」はCODE_INSPECTORを実行したことにより出力したデータを削除しデータの肥大化を防止するために実行されるようです。
このジョブの詳細は下記サイト参照しています ↓↓
そして、問題なのが、このジョブって、システム構築の時になんらかのタイミングによりジョブをスケジュールすることがあるようで、ジョブスケジュールの際に登録されていた実行ユーザがシステムから削除されると(担当者離任なのか、どういうわけか??)、ジョブ実行ユーザがシステムに存在しないためジョブが実行できない旨をジョブログが吐き出し、ジョブは毎日異常終了してしまします。
このジョブをシステムに残すことにより、データ肥大化以外デメリットはないので問題は無いと認識しておりますが、SAP Basis担当者からしたら、日次でSM21、SM37を叩いているわけで、これらの異常終了ジョブがあるだけで、ちょっと無駄に通知しなければならないという無駄工数消費につながります。
こういった状況を打破するために、ジョブ実行を行いました。
通常、ジョブを削除する時には、ジョブを削除する前に必ず削除対象ジョブをコピーして、ジョブ設定変更後の影響がでないようするフォールバックプランを作成します。
ジョブ削除の前に、ジョブのコピーを取ろうとしたら、
エラーが出て、ジョブのコピーができませんでした。SM21にてシスログを確認したところ、「無効データが入力されています」的な出力がありました。どうやら、私も知らなかったのですが、ジョブ実行ユーザが存在しないジョブのコピーはできないようです。どうやら削除はできる模様....
ということで、今回は、ジョブをコピーするのではなく、
ジョブステータスを変更し、ジョブを退避することで対応しました。
すごい基本的なことですが、僕は、普通にコピーできると思っていたわけで、計画の脆弱性を指摘されました。
もし、Basis初心者でジョブ削除する時は、実行ユーザを気にかけながらやってみることを強くお勧めします。
Trcd:SM37 ⇨ ジョブ検索 ⇨ 任意ジョブのダブルクリック ⇨ ステップ
にて実行ユーザは確認できます。
そんでもって、
Trcd:SU01 ⇨ 見つけたユーザ名入力 ⇨ 参照
で、ユーザの詳細情報も確認できます。
是非試してみてください!! では、今日はここで失礼します!!
クライアント移送作業を経験!!
こんばんは、カズヤんです。
最近はかなり仕事が充実しており、色々な経験をさせていただいています。
2月より、新たなプロジェクトにアサインされ、担当するシステムの規模が一気にバカでかくなり、やりたいバッグエンドの作業を担当させてもらっています。
今日は、かねてより切望していた「クライアント移送作業」を昨日より2日間かけて経験させてもらいました。
「クライアント移送」は、SAP Basisをやっている人間としては、バックエンドでは経験しておきたい作業の1つです。もうこれで、今年のTODOは1つ消化した感はあります。
ちなみにクライアント移送とは、
SAPシステムにおけるオブジェクトの「移送」という機能を利用して、SAPの3ランドスケープである開発機(DEV)、検証機(TES)、本番機(PRD)の各システム間にてデータを転送し、別システムに変更を反映する手法です。
基本的には、システムのコード修正をした時などに、開発機にてコード修正し、検証機に移送し、本番機に移送するという感じで移送を適用していくわけです。
今回移送したのは、クライアントというオブジェクトです。
SAPシステムにおけるクライアントとは、SAPのシステムを最小構成するユニットのようなもので、ユーザ企業はクライアントごとに異なる役割を割り当てます。
例) クライアント500 ⇨ 経営連結システム
クライアント700 ⇨ 営業システム ...
なお、1つのSAPシステムには、1000個(クライアント000〜クライアント999)のクライアントを保持できます。これは、SAPコンサル試験で結構出るっぽいですwww
ちなみに今回行った作業では、本番機のクライアントを検証機と開発機にコピーするというものでした。コード修正の際に行う移送作業とは異なり、クライアント移送はクライアントをコピーするために行います。なぜなら、本番機でクライアントを利用しているとデータの更新などで本番機のシステムデータと検証機、開発機のシステムデータと差異が生じ、今後の開発のために差異をなくすために2ヶ月、もしくは1ヶ月に一度クライアントコピーを行います。
クライアント移送では、コピー元システムからクライアントデータをエクスポートし、コピー先システムにインポートする作業となりますが、このエクスポートがかなり長時間となっており、システムによりけりですが、大抵1日では終わりません。
私は、初めてこの作業を実施したのですが、この作業のおかげでクライアントの構成、移送システムについての理解がかなり深まりました。
次回の記事にて、クライアント移送について説明したいのですが、その前に今回紹介した内容は、下記のテキストにも記載がありますので、SAP Basisやられている人は必ず確認した方がいいです。何度も言いますが、SAPの公式トレーニングでもらえるトレーニングブックよりもこの本の内容の方が1億倍わかりやすいです。
SAP Basis Administration Handbook, NetWeaver Edition
- 作者: Ranjit Mereddy
- 出版社/メーカー: McGraw-Hill Education
- 発売日: 2011/11/05
- メディア: Kindle版
- この商品を含むブログを見る
書籍に乗っているSAP GUI画面は少し古いようで今のSAP GUI750の画面と基本的には変わりませんので安心してください。
では、今日はここで失礼します。
BW 実ホスト名以外のホスト名が使えない説
こんばんは、カズヤんです。
今日は、名前解決について話そうと思います。
僕は、新人研修の時に、DNSサーバを構築したのですが、いまいちこのhostsファイルとDNSサーバのことをよくわかっていませんでした。
大規模なウェブサービスなどの場合には、DNSサーバが必要になるのですが、小・中規模のシステムの場合には、hostsファイルを用いてIPアドレスとサーバホスト名の名前解決をする認識だったのですが、これで間違っていないでしょうかね？？
ちなみに、どうやらSAPシステムでも色々と問題があるようで、SAPログオンの際には、ローカル端末のhostsファイルにて名前解決をすることでIPアドレスでなくホスト名を入力することでシステムにログオンが可能なのですが、BWシステムのBExアナライザを起動する時にはどうやら実際のサーバホスト名以外を利用するとBExが起動しないということがわかりました。
起動しない理由はまだ定かではないのですが、個人的には利用文字の制限があるのか？
もしくは、SAPのシステム内にてサーバ側の情報を読み取っており、サーバ側と端末側での不整合のため起動できないのかなとか考えを巡らせてはいます。
SAPシステムにて、Trcd:RZ11を叩くと、パラメータ参照が可能です。
「host」でソートかけると、実際のシステム内にて、
メッセージサーバを定義するパラメータやら、実サーバホスト名を登録するパラメータがいくつか出て来たので、システム内にてホスト名を照合する処理が走っている可能性があります。
おそらく、SAP社の推奨で別ホスト名以外のホスト名を登録することはやめたほうがいいですが、SAP Logonにてシステムにログオンすること自体は問題ないのでなんとも言えない状況です。
別ホスト名の利用は推奨ではありませんって言われる気がする....
まぁ、そんな感じで謎の問い合わせ...
共有までに晒します。ではまたww
AIによるSAP運用の自動化
こんにちは、カズヤんです。
今日は、AIを用いたSAP運用の自動化について書きます。
SAPに関しては、現在多くの技術者がいますが、システムのライフサイクル的には必ず運用フェイズがあるはず。
運用に関しては、ある程度規則性のある作業が多く、その作業をわざわざ上流の技術者が担当する必要はなく、ほとんどを外部委託(アウトソーシング)することが多いです。以前の記事に記載しましたが、運用に関しては、社外の専門業者もしくは、社内のオフショア部隊に定型作業を委託するのが一般的になっています。
最近、面白い記事を見つけたのですが、インドのタタグループのIT部門であるTCS(Tata Consultancy Services)が運用に特化したAIであるIgnio for SAPを市場に投入することが発表され、私も情報を見たのですが、SAPシステムの運用で行なっている定型作業のほとんどはIgnioが自動でやってくれるそうです。IBMのWatsonとの違いはよくわかりませんが、SAPシステム専用の運用ツールって多分世界初なんじゃないかと思います。
下記がプレスリリース(2017年9月のニュースで恐縮ですが) ↓↓
TCS Resources: : 日本TCS、AIを搭載したIT運用ソリューション「ignio」を展開
TCSの社内ベンチャーのdigitateという会社がIgnioのソリューションを提供しているようです↓↓
SAPシステムの運用に関しては、結構いろんなことをやりますが、
SAPシステムの運用業務では下記タスクの自動化を行えるようです。
・ユーザ管理
・ジョブ管理
・移送管理
・Note管理
・IDoc(システム連携の話、筆者はあまりわからない..すみません..)
・ABAPダンプ管理
・ダイアログレスポンス管理
一部まだわからないものもありますが、
今ってどこのSAPシステム運用会社でも、上の管理業務には手順書を用いて対応していると思います。
多分ユーザ管理とかに関しては、依頼をもらって、作業して作業報告までの時間で1時間くらいかかるはずですが、Ignio使うと5分くらいで終わるんじゃないですかねwww
多分、意思決定の部分だけエンジニアが担当する的な感じになるのかな..?
これらが自動化すると定型作業を実施しているエンジニアの需要は一発で無くなります。
まだ、導入がそこまで浸透していませんが、これがどんどん浸透した時に、
運用エンジニアの超過供給になり、現在この業務に従事している人の仕事はなくなると思います。
個人的には、3年は様子を見たいですが、SAP Basisに従事している方はなる早で構築業務に行くか、BPR案件で新しい価値の創出を試みることをお勧めします。
フェイルオーバ時のGUI接続先設定
こんばんは、カズヤンです。
今日は、クラスタ構成と負荷分散について書きたいと思います。
以前、ハードウェア障害でサーバがフェールオーバしたことを書きましたね。
インシデントが発生した際に、サーバへの接続確認をteratermとSAP GUIにて行うこと
がありますが、どうやら仮想ホストIPアドレスをSAP GUIの接続先設定として登録して居なかったため、インシデントが起きてから、仮想ホストIPアドレスを登録することになったのです。前回のインシデントに対しての問題管理としてGUI設定の是正をしている感じです。
現状は、こんな感じでサーバ構成されており、
SAP GUIでは、主系サーバと従系サーバの物理IPアドレスのみが振られているため、
主系サーバが従系サーバにフェールオーバした際に、サーバ毎に接続確認するのが面倒臭い状況が起こり得ます。どう言うことか以下で説明します。
サーバ構成は下記のようになっています。
なお、ここでのクラスタ構成は、負荷分散クラスタではなく、高可用性(HA)クラスタを想定しています。そのため、SAP GUIにて、仮想ホストIPにログオンした際には、必ず主系サーバにログオンする設定とします。
もし、これが負荷分散クラスタ構成となっていたら、仮想ホストIPにログオンした段階でトランザクションの処理に利用されるリソースが余っているホストにログオンすることになります。繰り返しですが、今回想定するのは、高可用性(HA)クラスタです。
主系サーバおよび従系サーバが正常稼働している際には、ステータスは以下のようになります。
Ping:
仮想ホストIP(172.35.30.11) 疎通可
主系サーバ(172.35.30.12) 疎通可
従系サーバ(172.35.30.13) 疎通可
SAP GUI:
仮想ホストIP(172.35.30.11) ログオン可
主系サーバ(172.35.30.12) ログオン可
従系サーバ(172.35.30.13) ログオン可
なお、以下が主系サーバがなんらかのトリガーにより、従系サーバにフェールオーバした後のサーバ構成です。フェールオーバのトリガーに関しては、クラスタ構成ソフトを販売しているベンダーのHPにて確認ください。このあたりもある程度は設定ができるっぽいです。大抵はネットワーク障害やハードウェア障害がトリガーとなりますが...
主系サーバがフェールオーバすると、まず、クラスタ構成にて事前に設定していたパッケージが従系サーバに移動することになります。SAPの場合、主系サーバで稼働していたセントラルインスタンスが従系サーバ上で稼働することになり、従系サーバで稼働してたダイアログインスタンスが停止することになります。
サーバのステータスは以下のようになります。
Ping:
仮想ホストIP(172.35.30.11) 疎通可
主系サーバ(172.35.30.12) 疎通不可
従系サーバ(172.35.30.13) 疎通可
SAP GUI:
仮想ホストIP(172.35.30.11) ログオン可
主系サーバ(172.35.30.12) ログオン不可
従系サーバ(172.35.30.13) ログオン不可
となります。
主系サーバが落ちているのでもちろんPingもSAP GUIもアクセスはできないです。
クラスタ構成をとっているので、SAP GUI上では従系サーバにもアクセスできません。
ユーザ側では、本番機サーバにただアクセスができる環境であればどこにアクセスできても同じことなので、仮想ホストIPをGUIで設定しておけば、何も問題はありませんが、我々のようなシステム管理者はこのGUI設定を常にどのサーバにも迅速にログオンできる設定にしておく必要があります。
現状：
主系IPアドレス
従系IPアドレス
是正策(1)：
主系IPアドレス
従系IPアドレス
仮想ホストIPアドレス
是正策(2)：
仮想ホストIPアドレス
従系IPアドレス
と考えています。
ここで、大切な要素となるのが、どこでシステムの負荷分散をしているのか？と言う点です。
負荷分散をSAPシステムのユーザログイングループ設定をしている場合で、サーバ側で負荷分散クラスタを設定していない場合には、仮想IPにログオンした場合には、確実に主系サーバにログオンできる証左があるので、どちらの是正策でも問題ないと思っています。
ただし、
サーバのクラスタ構成で、負荷分散クラスタ設定を行なっている時には、仮想ホストIPにログオンした時に、主系サーバにログオンするのか、従系サーバにログオンするかはワークロード次第のため、不確実です。よってこの場合には、是正策(1)を検討して確実に入れるシステムを確定しておく必要があると考えています。
今話しているのは、システム管理者のGUI設定の話ですが、ユーザ側はただ本番機にログオンできればそれで問題ないので、システムの構成などどうでもよく、仮想IPで常にログオンしてもらうということで問題ないと思います。
ながながと語りましたが、結論として、
SAPシステムのサーバ構成でクラスタ構成をしている時には、必ずGUI設定を意識した方がいいです。
「どのシステムにいつでも入れるようにしておく」ために、GUIの接続先設定は全IPアドレスを追加することを強くおすすめします。
では、今日はここで失礼します！！
Note2449757(同じシステムの認証済RFCに置ける追加の認証チェック)を読み解く
こんばんは、カズヤんです。
最近、ブログを書く頻度を抑えてますが、書くときはしっかり書きます。
今日は、タイトルにもあるように12月度リリースのセキュリティNoteについて説明します。
ちなみにSAPはこういう技術情報を月次でリリースしているので、世界のSAPユーザはリリースと同時に確認し、自社システムにおいてどのような影響が出てしまうのかをその都度確認しています。私もお客さんに毎月重要Noteのリストを提出し、月次報告会にて説明するのがルールになっています。
今回は、Note2449757についてで、
同じシステムの認証済RFCに置ける追加の認証チェック
と言う題です。このままでは、意味がわからんすwww
現象をみると、
トランザクションSMT1で同じシステムへの明示的な認証済/認証関係は定義されていないにもかかわらず、認証済RFC接続を同じシステムの異なるクライアントまたは異なるユーザに確立することができます。(SAP Support Launchpadから引用)
と記載があります。
SAP Basisやって来て、頻繁にRFC接続と言う単語を聞きます。
RFCに関しては、下記を参照して欲しいですが、
RFC(Remote Fucntion Callの略)が、SAPシステム間の通信用インターフェースということを押さえておけば取り分け問題ないっす。
ちなみに、SAP GUI上では、Trcd:SMT1にて各システム(SID)において認証されているその他SAPシステムの詳細を確認および新規登録できるっぽいです。
で話それましたが、
Noteによると、
このTrcd:SMT1をわざわざ実行しなくても、同じシステム上なら自動で認証される設定になっている
らしいのです。
SAPは、クライアントというデータ構造をとっているので、各クライアント依存のデータがあったり、ユーザも使い分けられるので、同じシステム内でもクライアントとユーザ固有データが存在します。なので、デフォルトの設定で、同じシステム内でも、別クライアント、別ユーザを利用する際には、わざわざ認証がいらないということです。
これって、何が問題なのかと言いますと、
例えば、あるSAP開発機があり、クライアント500で、ユーザkazuyanという実行ユーザで特定ジョブを実行した際に、他のクライアント001とか005とかでもユーザkazuyanを実行ユーザとしてジョブが実行できてしまうため、セキュリティ的によろしくないということです。
これを回避するために、このNote2449757上に記載のあるカーネルパッチを適用することで、この認証のデフォルト設定を変更できるそうです。
ただ、カーネルパッチ当てたりしてシステムのグレードあげると、システムの別機能で不整合が起きてめっちゃ不具合起きるらしいので、カーネル関連の変更ってかなり避けたい作業らしいので、ほとんどの場合、無視した方がいいのかなと個人的に思います。
あと、今回の自動認証機能が問題になるのは、システムを「集中ユーザ管理」設定しているシステムにおいての話なので、そうじゃない場合はあまり気にしなくてもいいのかなと思います。集中ユーザ管理は、権限などをシステム内で一意にまとめてしまうため、今回の事例が問題になります。
まあ、著作権というか、重要な情報っぽいので、詳しくはSAP Support PortalにてSユーザログインし、確認いただけたらと思いますが、SAP経験者でもこのNote解読するの大変かと思いますので、理解の助けになれば幸いです。
私も今回のとこでRFCに関しては、見直しました。
今日は、ここまでにしますが、今回説明したNoteの解釈間違ってたりしたらぜひコメントください。
IPA試験の海外認証について
こんばんは、カズヤんです。
今日から、３連休ですね。
わたしは、今日も資格試驗に向けがり勉していますww
私自身が海外でエンジニアとして業務をしたいという願望があるので、
たまたま気になったのですが、IPAが認定している情報処理試驗って海外でも認証されていることってご存知でしたか！！？
あと、私のブログはSAP経験者の方々だけでなく、海外移住を目指しておられる方も多いため、東南アジアに興味ある方には有益な情報かと思います。
以前ブログにも書きましたが、日本人が海外でエンジニアをしたいってなったら、Engineering 関連の学位を持っていないとengineerとしての資質を評価していただけないようです。
下記の国々では、日本で取得した情報処理試験でエンジニアとしての能力を各国の指標で評価して貰えるようです。下記リンクをご覧下さい ↓↓
現状では、ASEAN中心の12カ国で認証を受けられるようです。
インド、シンガポールは優秀なエンジニアが多数在籍してしている方イメージが湧きますが、
韓国、中国とかはどうなのかww?
ベトナム、ミャンマーもインドに次ぐオフショア地域として勢いがあるので、ここでの認証も日本のSIerとしてはでかいですね(てか、そもそもSIerがオフショア候補先を東南アジアに寄せていったのを背景に日本政府が認証取りにいった感はありますが..)。
欧米の国々の認証が受けられないのはかなりいたいですね。
個人的には、先進国でSAPの仕事をしたいので、そこらの国の認証があってほしかったなあ..シンがポール認証は気になります..
と思った今日この頃です…
では、ここで失礼します..
