クライアント移送作業を経験!!
こんばんは、カズヤんです。
最近はかなり仕事が充実しており、色々な経験をさせていただいています。
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の仕事をしたいので、そこらの国の認証があってほしかったなあ..シンがポール認証は気になります..
と思った今日この頃です…
では、ここで失礼します..
saposcolについて
こんばんは、カズヤんです。
今日は、新年初出勤でしたが、年末年始も出ていたので、仕事モードであまり憂鬱な感じはしませんでした。なので、一発目から書いて行きます。
今回は、SAPの重要な機能の1つであるsaposcolについて説明します。
saposcolは名前の通りsapのリソース情報をOSから収集するための機能です。
私は、運用のチームに所属しているので月次報告書を作成する際に、CPU利用率やメモリ利用率を集計する必要があり、このsaposcolが収集したデータを閲覧します。
このsaposcolはSAPシステムとは別で存在し、os上で「ps -ef | grep sapos」みたいな感じで見るとsaposcol.exeみたいな名前のプロセスが存在するので、それがあったら、saposcolのプロセスが起動しているということです。
ちなみに、SAP GUI上にこのリソース情報を得るためには、Trcd:ST06を利用すると情報を確認できます。
saposcolの起動方法はosにより様々らしいですね。私のとこでは、HPUXとかWindows Serverとかなのであまり意識してなかったですが、おそらく運用やってるところなら、SAP停止・起動の手順書が存在すると思うのでそちらを確認して見ることをお勧めします。
てか、全部下記サイトに載ってるっぽいっすww
まあでも、SAPの仕組みを理解する上では重要なのでSAP Basis担当の方はぜひ覚えましょう。
今日は、ここで失礼します!!
明日は今週ラスト、頑張りましょう!!
国内SAPベンダー勢力図
こんばんは、カズやんです。
今日で、大晦日と元日のシステム変更作業終わりましたww
てか、大晦日の電車の空き具合がやばかったww
今日は、技術よりのことよりも、日本国内のSAPベンダーの競争力について見てみます。
今って、SAPバブルみたいなところがあってどこの会社も基幹システムとしてSAPを導入しているため、その過剰需要に応えるために多くの企業がSAP事業に参入しているのは言うまでもないことです。
SAPに関して、どこのベンダーが最も競争力が高いのかとか、指標がなかったのでイメージしづらかったのですが、どうやらガートナー社によって、国内のSAPベンダーランキングが発表されているようです。
2017年2月にリリースされたものなので、1年前の指標ですが参考になると思います。
下記をご覧ください ↓↓ 筆者の会社も入っていたのでテンション上がります ↑↑
引用）https://www.gartner.com/doc/reprints?id=1-3V872QJ&ct=170309&st=sb
この図はすごくわかりやすくて、水平軸に「Completeness of Vision(ビジョンの完全性)」、垂直軸に「Ability to Execute(実行力)」となっています。
お分かりかと思いますが、第1象限から第4象限まであり、以下のような位置付けが定義されています。なんかすごい経営学のフレームワークみたいですww
間違いなく、1番強いのは、Leadersの企業群です。一番悪いのは、Niche Playersの企業群です。残り2つ(Challengers、Visionaries)については、人によって、変わりますが、個人的には、リソース大きい方が有利な業界だと思うので、Challengersが強いのかなとか思ったりもします。
アビーム、アクセンチュアが第1象限に位置しているのは納得ですね。
JSUGの広告とかでもこの辺のベンダーはよくみますし、SAP Hanaの導入等も他のベンダーの先をいっているイメージがあります。アビーム以外は、規模の大きなベンダーなのでスケールメリットってとこだと思います。
第2象限は、SCSK、TCS、TISがありますね。TISはわかりませんが、商社系のSIerがいる傾向がありますね。SCSKに関しては、SAP以外にも、プロアクティブっていうERP製品を持っているので、SAPとの相性も良いような気もします。TCSは、三菱商事系の資本を背景に強い顧客基盤を持っています。GlobalのTCSがSAPの売上高半端ないと聞きます。
第3象限は、みてわかる通り、コンサルティング系ベンダーが顔を並べています。まあ、第1に技術者が少ないイメージがあります。コンサルティングのサービスはシステム戦略、要件定義やBPRがメインになるイメージがあります。Basis等のインフラ部分は弱い気がします。ただ、PwCに関しては、かなり熱心に採用活動をしているので、今後強そうな気がします。
第4象限は、謎にWiproが入ってますね。Wipro Japanはインド🇮🇳IT企業群SWITCHの一画で技術力は申し分ないと思います。ただ、SAPのランキングで国内でそこまで有名なイメージはなかったので以外です。個人的には、外資系の少数精鋭のベンダーは好きなので、Basisの技術者の方なんていたら会ってみたいですね。おそらくですが、TCS同様に、インドオフショアできるのがアドバンテージだと思うので、今後伸びるのでは？
このランキングを見て思うのが、ガートナーは海外の会社なので、グローバル企業を主に評価しているイメージがあります。実際、SAPを日本でやっていると、他にも有名で勢いのあるベンダーは実は結構あります。JSOLとか入っていないの意外でしたwwwあと、個人的に気になっているのがBeeXですね。クラウド移行に強みを持つベンダーで超勢いあります。私もめっちゃ移りたいwww
ただ、どうやらガートナーもこのことには触れていて、ランキングを出す時の定義を細かく載せているのでそこは確認してください。まあ、こういうランキングって完璧じゃないので、目安ぐらいな感じで捉える感じでいいと思います。
そんなこんなで自分のファームも載ってたのでテンション上がりましたが、今後もっと個人でも戦えるように力をつけていきたいと思います。
年末に書いたブログ記事の内容を今年度の抱負としてまた1年頑張っていこうと思います。
では、今日はここで失礼します
