SAP NetWeaver 7.5のインストール完了！！
こんばんは、カズヤんです。
先週の木曜日(2月9日(木))にブログに投稿しましたが、SAP Net Weaver 7.5のインストールを実施しております。実は先週の土日もやってましたが、なかなかサーバインストールが進みませんでした。しかし、なんと今日正常にインストール完了し、GUIを操作することができるようになりました↓↓
見てくださいよ!! とうとう家でトランザクションが試せる
今回のインストールでは、下記ガイドをもとに作業実施しております。
Newbies Guide: Installing ABAP AS 751 SP02 on Linux | SAP Blogs
とてもわかりやすいのですが、この指示通りにやればインストールがうまくいくと過信するのは少し危ないです。今回のインストールについて少し共有できたらと思いますので、ご参照ください。
■ サーバ機として利用するマシン
とりあえず、今回インストールに用いるマシンは、Windows10搭載のThinkpadです。
一応、HDD 500GB、物理メモリ8GB積んでいるので、今回のインストール作業はギリギリ耐えてくれると信じています。
ちなみにこいつです↓↓
学生の時にJavaの学習をするために買った開発用PCです。
一応、サーバ機とするわけですが、通常のビジネス向けシステムじゃないので検証に使う時だけ、OSを起動するのでまあこいつで問題ないでしょう。まあ、普段の運用みたいにサーバ止まっちゃいけないなんてルールもないわけですしwww
ホストOS上でSAP GUI for Windows 740を利用し、ゲストOS上にSAP NW AS ABAP 7.5をインストールする構成にします。
アーキテクチャに関しては以下の図を参照ください。
システムアーキテクチャ図
今回はTrial版なので、DBはOracleでもDB2でもなく、SybaseのASEです。ちなみに私は使うの初めてです。まあ、使いながら慣れていけばいいと思います。
具体的に私が困ったのは、下記3点です。
・10個のrarファイルの解凍
・仮想環境上のAS(アプリケーションサーバ)のプロセスの停止・起動
1、10個のrarファイルの解凍
今回インストールするソフトはトライアル版ですが、圧縮ファイルのサイズが全部で14GBもあり、10個のファイルを解凍しなければならないのですが、この解凍にかなりの時間を要します。私のラップトップのメモリが8GBとかなり少ないのも要因ですが、10個のファイルを解凍するのに100分かかりました。ちなみに解凍するさいには、OS側のコマンドにて「unrar x ファイル名」とすることもできるのですが、これだとファイルの階層がめちゃめちゃになってインストールプログラムを起動した際にうまく終了しないため、ホストOS側でLhaplusを利用して解凍することをオススメします。
今回、インストール自体は3回行いましたが、いずれのインストールでもログにエラーが吐かれていて、その中でこの「gcc」というパッケージの欠落を指摘するものもありました。パッケージ「gcc」のインストールに関しては、1行のコマンドでどうにかなるのでググってください（すみません、ここはググって適当にやりました)。
３、仮想環境上のAS(アプリケーションサーバ)のプロセスの停止・起動
実は、インストール後も悩まされまして、SAP GUIからASにアクセスする際には、もちろんサーバ側のインスタンスが起動していないとできません。
通常、SAP NWのインストールが完了すると、インスタンスが起動した状態で終わるのですが、ラップトップのメモリが少ないため、SAP GUIのインストールのために、Oracle Virtual Boxを停止し、SAP GUIのインストール後に再度起動させました。そのため、インスタンスが停止してしまっていたらしく、GUIから接続できませんでした。
その場合、一旦「stopsap」にてASを停止し、「startsap」にて再度システムを起動させる必要があります。そうすれば、必要なプロセスが全部上がってくるので必ず行なってください。
■インストール完了
これらの課題を攻略し、とうとうインストールが完了し、GUIから接続確認できました。普段はGUI750を使っているので、GUI740に少し慣れていないですが、740のUIも結構かっこいいですね。
まだ、初期設定はしていませんが、下記トランザクションの実行確認行いました。
・SM21 シスログ参照
⇒普通に見れるう！！
・SM37 ジョブ参照
⇒すでにジョブが実行されていますね。ジョブのステップとかジョブログとかもしっかり見れます。
・SU01 ユーザ情報参照
⇒ユーザは3ユーザしかいませんが問題ないです。ユーザ管理もSAP管理者としては大切な箇所ですので、業務では何度もやっていますが、この辺もしっかり確認してみます。
インストールできた嬉しさから、意味もなく適当に実行したトランザクションのため、詳しくは見ていませんが、SM37に関しては、標準ジョブの登録もできそうなので基本的な作業はほとんど問題なくできる印象です。
まず1つ言えるのは、会社ではシステムに影響を与えることもあるため自分のペースでトランザクションを実行できないなんてことは普通にあると思うのですが、検証環境さえあれば、自由に操作できるので、現場での作業も円滑に実施できると思います。
個人的には、DB管理のところを重点的にやりたいのでASEでちとこまっていますが、探求してみようと思います。
今後はこの検証環境でいろんなことやっていきますので、引き続き読んでいただけたらと思います。では、今日はこれにて失礼します!!
SAP NetWeaver 7.5のTrial Versionを入手
こんばんは、カズヤんです。
以前から検証環境がず〜〜と欲しかった私ですが、SAP社によるCAL(Cloud Appliance Library)の利用はAWSやMicrosoft Azureの環境が前提であり、超コストがかかるためほぼ諦めていました。そんなところ、たまたま、行き着いたこのブログ、めっちゃインストールに関して詳しく書いておられます。
この方のブログに、下記URLよりTrialのダウンロードができるとあったので、ポチッと押して見たら、ダウンロードサイトに移りました。
https://store.sap.com/sap/cpa/ui/sid/0000000218
ここで、「NetWeaver」と入力したら、
こんな画面に遷移するので、この一番上の
SAP NetWeaver AS ABAP 7.51 SP02
をクリックします。
NetWeaver 7.5は一番新しいバージョンでS/4 HANAの基盤になります。ただ、DBがASE(Adaptive Server Enterprize)というSybase社のDBです。
そして、Sybase社は現在SAP社の参加に入っていることも有名な話ですww
私は、OracleとDB2しか触ったことがないので、ちょっとがっかりですが、トランザクションコードを試せるだけでもかなりありがたいですね。
ちなむと、OracleもDB2も、おそらく2、3年後にはS/4 Hanaで使えなくなるので、ASEは本当に意味ない。
とりあえず、10個のファイルダウンロードをしているのですが、ファイル5個ダウンロードするのに、20分もかかってるからインストール作業は土日ですね。
一応、インストールに際してのハードウェア要件は、以下の通り↓↓
x86_64 Processor based hardware
o 物理メモリ8GB ＋ スワップメモリ8GB
o サーバーインストール：ディスク100GB
o クライアントインストール：2GB
o OS: Linux
まあ、予備で所持している開発用のラップトップ(Lenovo Think Pad)があるのでそいつで事足りそうな感じはありますね。
今後も、SAP Basis作業を紹介するのでインストールうまくいったら記事書きますね!
では、今日はここまでで失礼します。
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アドレスを追加することを強くおすすめします。
では、今日はここで失礼します！！
