紫陽花。6月の梅雨にピッタリの花です。
万葉集にも詠まれている歴史の古い花。原産地は日本。
江戸～明治時代にヨーロッパに渡り、西洋アジサイとして
逆輸入されました。
従来は青系とピンク系が主流でしたが、現在は白のアジサイや
ピラミッド形のカシワバアジサイなどがあります。
ガクアジサイは額に囲まれているように見えるので、
ガクアジサイと呼ばれています。
社内 野の花画伯から その2
Salesforce 認定アドミニストレーター受験記
はじめに
こんにちは！株式会社オプトプランニングです。
先日、Salesforceの認定アドミニストレーターをオンラインで受験し、無事に合格できました！！
Salesforceでは登竜門的な位置づけとなる認定アドミニストレーター資格ですが、合格までに様々な先輩方の受験体験記を読ませてもらいました。
そこで私も、どんな勉強を行ったか、オンライン受験のあれこれ、受験日までの準備や受験当日のことなどを書いていきたいと思います。
今から資格取得を目指すどなたかの参考になれば幸いです。
試験対策
勉強したこと
まずは、みなさんお馴染みのTrailheadを行いました。
私は実務でSalesforceを扱う機会があるので、今まで関わってこなかった分野や理解が曖昧な部分をTrailheadで勉強しました。
また、Salesforce主催の無料ウェビナーも参加しました。
半日かけて試験の出題範囲に沿って主要ポイントをなぞっていくので、とても勉強になりましたよ。
また、参加者に試験の割引クーポンの案内もあり、至れり尽くせりでした。（もちろん、今回の受験でありがたく使わせていただきました！！）
割引クーポンは有効期限が設定されており（私の時は3か月弱でした）、いつまでに受けよう！！と気持ちを奮い立たせてくれるので、試験を受けようか悩んでいる方こそ受講してほしいです。
あとは、ひたすら練習・模擬問題を解きました。
問題については有志の方々が作成し、ブログなどで公開して下さっているものを使わせていただきました。（有志の先輩方、本当にありがとうございます！！！）
個人的な感想ですが、問題文が独特なのでとにかく問題の出題形式に慣れておく必要があると思います。（これはどんな資格試験にも共通することかもしれませんが…）
勉強の流れ
具体的な流れとしては
問題を解く → わからない用語はメモ → 答え合わせ → わからない用語や正答率が低かった分野についてTrailheadがあればやってみるor見返してみる → Trailheadがなければ自力で調べる → 問題を解く・・・
を繰り返しました。
何度か上記の流れを行うと苦手分野が分かってくるので、苦手分野の問題を繰り返し解いて復習も行いました。
Salesforceは一度も触ったことがない…という方は、まずはTrailheadから始めてみて、大体わかってきたな、というタイミングで問題を解き始めるといいかもしれません。
試験予約と環境
試験予約のための準備
Trailheadをやってみた事がある方はTrailheadのアカウントをお持ちだと思いますが、それとは別に試験を受けるためWebassessor （ウェブアセッサー）へ登録する必要があり、Webassessorのアカウント取得後、試験の予約ができます。
オンライン試験について
オンライン試験は基本的に24時間受けることができます！！
（システムメンテナンスなどで受験不可日もあるので、詳細はSalesforce 認定資格をご覧ください。）
とてもありがたいですが、予約の時はうっかり受験時間を間違えないように気を付けて下さい…
時間は24時間とAM・PMの12時間の両方で表記されています。（2022年5月時点）
受験可能な時間が早い順で表示されるため、一番早い時間だと0:00（12:00AM）から選択できます。
例えばお昼の1時（13:00PM）に試験を受けるつもりが1:00（1:00AM）に試験予約をしてしまった…ということのないようにしましょう。（私はうっかり予約しかけました…）
オンライン試験の環境について
私はノートパソコンで受験しましたが、PC内蔵のカメラとマイクのみで問題なく受験できました。
オンライン受験ができる環境かチェックもできるので、そちらで調べるのが一番だと思います。
インターネット接続についても診断できるので、あらかじめ当日受験予定の回線（部屋）で診断しておくといいと思いますよ。
試験前日までの流れ
前日までにやっておくこと
まずは、オンライン受験ガイドをしっかり読んでおきましょう。
必ず行っておくこととして「Sentinel（センチネル）」のインストールと「Biometric（バイオメトリック）」の登録の2点があります。（受験ガイドにも記載があります）
方法は受験ガイドに詳細が記載されていますので割愛します。
試験当日の流れ
本人確認について（オンライン試験の場合）
試験会場では本人確認のため身分証明書が必要のようですが、オンライン受験ではバイオメトリックの認証システムで本人確認を行っているので身分証明書は必要ありませんでした。（2022年5月時点）
また、受験ガイド記載の「セキュリティに対する推奨」設定は、試験開始直前だと慌てそうだったので、当日に受験ガイドを確認しながら行いました。
試験開始直前
試験時間の10分前に試験開始ボタンが出現します。
私はオンライン受験ガイドをしっかり読んだつもりでしたが、どこに記載されているかわからず…
30分前からスタンバって、15分前になっても試験開始のボタンが現れなかったので、オンライン試験ガイドや動画を見返して10分前に試験開始ボタンが出現することに気が付きました…(笑)
試験準備などに気を取られて見落としがちかもしれませんので、今から受験する方は10分前に試験開始のボタンが現れると覚えておいて下さい！！
試験開始ボタンを押すと、試験の注意事項などの最終確認の画面に遷移します。
動画の案内もあるので、それを見つつ準備ができたらセンチネルの起動ボタン（だったかな？この辺りはうろ覚えです…）を押します。
センチネルが起動しない・・・
はい、試験開始ボタンを押した後、センチネルが起動しないエラーが発生しました…(泣)
エラー後、再度試験開始ボタンとセンチネル起動ボタンを押しますが、エラー連発で刻々と予約時間に近づき、メチャメチャ焦りました…(号泣)
５回ほど試してダメだったので、チャット経由でサポートに連絡しました！！！
カスタマーサポートセンターへ連絡してみる
私が行った連絡方法としては、まずWebassessorログイン画面にあるオンライン受験のチャット問い合わせの「こちら」をクリックします。
すると、KryterionのHPが開くので、右下のポップアップをクリックします。
氏名やメールアドレスの記入フォームが立ち上がるのでそれぞれ記入し、問い合わせ内容として正しそうなものを選び、下にある「チャットを開始」をクリックします。
（全て英語の選択肢でしたが、私の場合「Online Exam Technical Help」が妥当そうだったのでこれを選んだと思います…焦っていたのでここもうろ覚え。）
チャットが起動して少し経つと、オペレーターの方が英語で連絡をくれました。（日本語に訳すと「何にお困りですか？」みたいな感じだったと思います）
しかし、私はすでにチャット入力欄に「センチネルが起動せず試験ができない」と日本語で入力していました。
焦りすぎていたので、一旦そのまま日本語で送り、翻訳サイトで英語に直してチャットに入力し直そうとしていたところ…
なんと、返答が日本語で返ってきました！！！
翻訳したような日本語だったので、オペレーターの方が英語を日本語に翻訳して対応してくれたみたいです。
念のため、日本語でもいいですか？と聞いたら、大丈夫との返信がありました。
私と同じように何かトラブルに遭遇した方は、チャットで英語が送られてきても日本語で送ってみてもいいかもしれません。
焦りすぎていたので、この対応は本当に感謝しかありません。
対応してくれたオペレーターの方、あの時はありがとうございました…！
そんなこんなでエラー状況を詳しく説明すると、一度センチネルをアンインストールし、指定のファイルをインストール後、センチネルを再インストールするよう指示があり、、、
無事にセンチネルを起動することができました！！！！
サポートでのやり取りでおそらく20分ほど経過していたと思いますが、無事に受験することができました。
試験開始～終了まで（眼鏡の人の場合）
センチネル起動後、事前に登録したバイオメトリックの顔認証も済ませ、いよいよ試験開始です！
しかし、私は眼鏡をかけています。
眼鏡の場合は、チェックを行うと受験ガイドにありましたが、いつやるんだろうなぁ～なんて思いながら問題を解いていると・・・
急に眼鏡を確認する旨の画面に変わりました！！！
３～４問目の問題文に目を通しているところだったと思うので、時間にすると開始から5分少々経過したころでしょうか？
音声での案内はなく、切り替わった画面に「Glasses」の文字とカメラに眼鏡を近づけて見せるようなアニメーション（？）があったと思います。
（ここもうろ覚えですが、英語が得意ではない私にもすぐ眼鏡の確認だ！とわかりました。）
確認ができたら自動で試験再開すると思っていましたが、「試験に戻る」ボタン（うろ覚えです）があったので、確認ができたかの有無は無いと判断し、眼鏡を外してPCのカメラに近づけた後、前後左右に眼鏡を動かして止める、というのを５秒間隔で念のため２回繰り返し、「試験に戻る」を押して試験を再開させました。
試験時間は比較的余裕があったので、後から見直すためにチェックをしておいた問題の見直しをしてから全体を再度見直し、時間ギリギリまで粘りました。
試験終了！！
なんとか合格…！！
ギリギリまで問題を解き、試験終了のボタンをクリックすると、正答率と合否が記載された画面に切り替わりました。
初めての試験だったのですぐに結果が出てビックリしました！と言いたいところなのですが、試験に集中し疲れていたためすぐには状況を呑み込めなかったです(笑)
少したってから合格メールなどが送られてきてやっと実感することができました～
センチネルの起動エラーなどがあり試験の開始が予定より大幅に遅れたものの、試験時間が短くなったりはありませんでした。（試験中は時計は見れませんが残り時間が表示されており、開始した時に105分だったのを確認しています。）
また、私の場合試験中に眼鏡の確認がありましたが、その間は試験時間が表示されていなかったため試験時間に影響はなかったと思います。（当たり前ではありますが…）
あとがき
なんとか一度目の試験で合格することができてほっとしています。
振り返ってみると、トラブルに遭遇した方の受験記などを事前に読んでいたため、チャットでサポートに連絡する行動へ移れたと思います。
トラブルが起こっても一旦落ち着いて冷静に、と思っていてもなかなかそうはいかないものですね～
年内にもう一つSFDCに関する資格を取りたいな～と思っているので、受験の合否に関わらず勉強方法などを書いていけたらと思います。
それでは、またお会いしましょう！！
消防訓練実務研修レポート
こんにちは！株式会社オプトプランニング、安全衛生・健康推進委員です。
職場の安全管理の一環として受講した「消防訓練実務研修」のレポートをします。
場所は、広島市総合防災センターで行われました。
http://www.bousai-c.city.hiroshima.jp/index.htm
研修の内容は主に、
1.防火管理について
2.避難訓練について
3.消防用設備について
でした。
実際の炎を前にしての消化訓練は、水用消火器ではなく、本物の消火器で消化を体験しました。
炎は、3～5メートル離れていても熱いです。緊張のせいか、消火器のピンが抜けずに焦りました。
そして、ホースでの水放出は、水の勢いに体がとられ、狙う位置に水が届きにくい。
消化は初期消火が大切とのこと。いざという時は、しっかり消さないといけません。
スプリンクラーの水量も見学しましたが、当然ですが水量が半端ないですね！
中でも、最も印象に残っているのは、煙の訓練でした。
照明のない暗闇で煙に巻かれると、本当に何も見えませんし、閉じ込められてパニックです。
こういう時に働く『正常性のバイアス』という心理は、
「自分にとって不都合なものを過小評価する傾向がある」
ことだそうです。
また、火災パニックの習性として、
・日常導線指向性：日常使いなれた通路を使う傾向
・帰巣性：入ってきた経路を戻ろうとする傾向
・向光性：暗闇で明るい方へ向かう傾向
・危険回避性：目前の危機のみを回避しようとする傾向
・追従性：多くの人が逃げる方向へ追従して逃げる傾向
があるとのこと。
自分は大丈夫と思っていても、いざという時は冷静さを保てるか。
日頃の訓練が重要と痛感しました。
「知っている」と「実際出来る」とでは、大きな違いがある、と講師の方も説明されていました。
今回受講させていただいた講座で、火災での危機管理、防災意識を高めることができました。
日頃から、全社で共有しておきたいと感じました！
社内 野の花画伯から
あなたは、どの花が好きですか？
初めて、花ではなく魚を描きました。
漢字「目張」と書き、飛び出しそうな大きな目が特長です。
黒メバルは、瀬戸内海「春告げ魚」の一つです。絵に加えて
‟人生限りなく楽し”の文字を追加しています。
どんなつらいことがあっても、何でもあきらめたらいかん。
いつかきっと春が来るぞ、という気持ちで描きました。
変更セットの上手な使いまわし術
はじめに
こんにちは！株式会社オプトプランニングです。
先日リリースについて書きましたが、その際書けなかったクローズ後の変更セットの私なりの使い方を忘備録も兼ねて書いていきたいと思います。
クローズした変更セットの利用方法その１
同じ変更セットを使いまわす
まずは、変更セットの再利用です。
- 同じ変更セットを複数の組織にリリースする必要がある
- 本番組織をベースに作成したSandbox環境でリリースの評価・テストを行い、問題なかったので同じ内容の変更セットを本番環境にリリースしたい
など、同一内容の変更セットを別組織にリリースしたい場面はあると思います。
クローズした変更セットは編集はできなくなりますが「アップロード」ボタンは残っています。
これを利用し、クローズした変更セットを別環境にアップロード・リリースすること（再利用）ができます。
（※クローズした変更セットに含まれるコンポーネントは、変更セット作成後に削除や修正をしていない場合に限ります。詳しくは後ほど説明します。）
アップロードする際、対象組織に対してリリース接続の設定を行うことが必要ですので、そこは忘れずに行いましょう。
１つの変更セットを再利用する良い点は、「変更セットアップロード履歴」が残ることです。
アップロードする度に残るので、後からどの組織にアップロードしたかの確認ができます。
Trailheadでは
送信変更セットを別の組織にアップロードした後で、異なる組織にアップロードすることはできません。
インテグレーション環境でのテストと変更のリリースhttps://trailhead.salesforce.com/ja/content/learn/modules/declarative-change-set-development/test-in-the-integration-environment-and-deploy-changes
とありますが、Developer SandboxからDeveloper Sandboxまたは本番組織に向けてのアップロードはできることを確認しています。
Sandboxの種類が違う場合などは検証しておりませんので、うまくいかない場合はTrailheadにあるように変更セットのコピーを行ってください。
クローズ後の変更セットのアップロード方法
変更セットのアップロードボタンは、送信変更セットの一覧や変更セットの詳細にあります。
クローズ後の変更セットをアップロードしようとすると図５のような画面になります。
変更セットをどの環境にもアップロードしていない図４の時と比べてみると、
この変更セットをアップロードすると、編集できなくなり、対象組織から取り消すこともできません。
というメッセージがクローズした変更セットに表示されていないことがわかります。
既にクローズしている変更セットはそもそも編集することができないため、注意書きが現れないようです。
使いまわす時の注意点その１
1つ目に注意したいのは、すでにアップロードした組織も選択できる点です。
同じ変更セットを複数回にわたって同一環境にアップロードしても特に問題は起きません。
逆を言えば、エラーも出ないということです。
アップロードは成功したのにアップロードしたはずの環境（対象組織）に受信変更セットがみつからない…？という時はアップロード先に間違いがないか確認しましょう。
アップロード先は、変更セットアップロード履歴やアップロード完了の通知メールで確認できます。
アップロード完了の通知メールには、送信変更セットのソース組織と対象組織が明記されています。
参考までに、「リリースしてみた＜アップロード編＞」で載せなかったアップロード完了の通知メールはこんな感じです。
システムメールとしてSalesforceから送られてきます。
使いまわす時の注意点その２
2つ目の注意点としては、１度にアップロードできる対象組織は１つだけという点です。
アップロード先を選択する画面はラジオボタンで構成されており、複数の組織を選択することは不可能となっています。
複数の組織に同じ変更セットをアップロードしたい場合はそれぞれアップロード手順を行う必要があります。
使いまわす時の注意点その３
３つ目の注意点としては、クローズした変更セットに含まれるコンポーネントは更新されないという点です。
例えば、前回のリリースしてみた＜変更セット作成編＞で追加した権限セット「MFA」について、変更セットアップロード後に修正を加えたとします。
アップロード後の変更セット（クローズした変更セット）はコンポーネントの更新が行われないので、権限セット「MFA」に行ったは反映されません。
変更セットに変更はないが、変更セットのコンポーネントの内容に変更がある場合は、「変更セットのコピー」を作成しないと修正内容を反映することはできません。
コンポーネントの更新という考え方が少し難しく感じますね…
クローズした変更セットの利用方法その２
変更セットのコピーを作成し編集する
クローズした変更セットは編集することはできませんが、コピーを作成することは可能です。
また、作成したコピーに対しては変更セットの編集ができます！！
このことを利用し、クローズした変更セットを編集したい時はコピーを作成するといいと思います。
- リリースでコンポーネント不備によるエラーが出た
- リリースでエラーも無く一安心した後に、リリース環境の確認を行っていて入れそびれたコンポーネントがあることに気づいてしまった
などなど、変更セットの作り直しが発生してしまうのはよくあることだと思います。（きっと私だけじゃない…はず 笑）
リリースしそびれたコンポーネントだけの変更セットを新しく作成してもいいのですが、
- エラーやコンポーネント不足の度に変更セットを作成すると、沢山の変更セットが作られてしまう
→どんな内容の変更セットをアップロード（リリース）したか履歴を確認する可能性があるため、リリース内容をなるべく１つの変更セットにまとめておきたかった - 「連動関係を参照/追加」を使用することで、変更セットに含めたい関連するコンポーネントが探し出しやすい
といった理由から、変更セットのコピーを作成しコンポーネントを追加（削除）する、ということを行いました。
変更セットのコピーの作り方
変更セットのコピーはとても簡単に作成できます。
対象の変更セットの「コピー」をクリックするだけです。
アップロードと同様、「コピー」は、送信変更セットの一覧や変更セットの詳細にあります。
コピーをクリックすると、「変更セットのコピー」に遷移し、ここで変更セットの名前や説明を変えることができます。
ベースの変更セットと混同しないためにも、名前や説明はコピーであることが分かりやすいものに変更しておいた方がいいと思います。
図１１ではすでに名前や説明を変更してありますが、「変更セットのコピー」の名前と説明にはデフォルトでベースの変更セットと同じ内容がそれぞれ入力されています。
変更セットのコピーを保存すると、ベースの変更セットのコンポーネントを引き継いだ「状況」がオープンの変更セットが出来上がります。
あとは、新規作成の時と同様にコンポーネントの追加を行ったり、不要なコンポーネントの削除を行いましょう。
あとがき
変更セットのコンポーネントの種類は、作成したことがある方ならわかると思いますがとても沢山あります。
以前どのぐらいあるか調べた時は約120種類ありました。（2021年12月ぐらいに調べました）
中には見たことのないコンポーネント種類名もあったりしたので、変更セットの作成は本当に大変な作業だと思います。
今回は、クローズ後の変更セットに焦点を当てて使い道について書いてみました。
クローズ後に限らず、良い使い道を思いついたら第二弾としてまとめられればと思います。
それでは、またお会いしましょう！！
体に『美味しい』スイーツ作りに挑戦！
こんにちは！株式会社オプトプランニングの健康推進委員です。
当社でのいろいろな健康経営の取り組みに刺激され、健康的なスイーツ作りに挑戦しました。
以前から料理は好きで、中でも特にスイーツは食べるもの、作るもの大好です。
家にある残りもので、何かできないかな・・と考え、作るのにはまっております。
今回は、お安くなっていた「麦芽コーヒー豆乳」が冷蔵庫に残っていたので、
『コーヒー豆乳ババロア』を作ってみました。
使用したのは市販の麦芽コーヒー豆乳（もちろんカロリー５０％OFF）と豆乳入りホイップクリーム、後はゼラチンと卵黄、グラニュー糖です。
作り方は普通のババロアと同じです。
今回はアレンジでチョコレートソースをのせて作ってみました。
お味は・・なかなか美味しくできたと思います（自画自賛）！
豆乳に含まれる栄養素と言えば、代表的な大豆イソフラボンをはじめ、たんぱく質、サポニンに
ビタミンＥなど健康に良いものがいっぱい！
飲むのには、少しくせがありますが、このようにスイーツにすると美味しく食べられます。
ざっくり栄養計算していみると・・1個当り約１６０Ｋｃａｌ・・
一日のうち間食にあてることができるカロリーは２００Ｋｃａｌ。
できればもう少しカロリーを落としたいですね。
チョコレートソースのカロリーが高いので、コーヒーソースにしたり、使用する砂糖を
ノンカロリーの砂糖にしたり、まだまだ試行錯誤の余地はありそうです。
目標のカロリーは１２０Ｋｃａｌ。美味しさはそのままで体に健康的なスイーツに
なるようにもう少し試作してみます。
納得のいくレシピができたら、ぜひ皆さんにも紹介したいと思います！
AWS CLIで情報を出力しようRDS編(Linux版-その2)
RDSってどんな製品（エンジン）が利用できるのだろうか。一覧とかだして、確認
することができたらいいな。AWSコンソールから操作すると、もし、何かミスをし
て、他のシステムに影響があったら困るし、課金されても困る。どんなエンジンが
あるかどうかさえ分かれば、いいのに。こんな時には、AWS CLIを使いましょう。
1.現在利用中のRDSの情報を出力しよう！
利用中のRDS一覧を出力する場合は、以下のコマンドを実行します。
aws rds describe-db-instances
json形式で沢山出力されます。
2.現在利用中のRDSで出力する情報を絞り込んでみよう！
オプションのqueryを使用することで絞り込みができます。
以下の例は、ClassとId,Engine,Endpointのアドレスに絞った例です。
トップレベルがDBInstanceで（画像C 階層と項目）DBInstanceIdentifer,
DBInstanceClass,Engineをdict{}に配置し、{EndPoint.Address}を分けて配置
させます。DBinstanceIdentiferと同列に書くと縦長に配置されて出力されます。
aws rds describe-db-instances \
--query "DBInstances[].[{ID:DBInstanceIdentifier,Class:DBInstanceClass,\
Engine:Engine},{Endpoint:Endpoint.Address}]" \
--out table
3.利用可能なRDSのEngineとVersion情報を出力しよう！
利用中のリージョンで、利用可能なRDS一覧を見たい場合に以下のコマンドを実行します。
aws rds describe-db-engine-versions
json形式でどばーっと出力されます
4 出力する情報を絞り込んでみよう！
オプションのqueryを使用することで絞り込みができます。
以下の例はDBParameterGroupFamilyとEngineversionのみに絞ったものです。
DBParameterGroupFamilyが、このDBパラメータグループファミリー互換性のある名前で
EngineVersion が、このエンジンのバージョンです。
aws rds describe-db-engine-versions \
--query "DBEngineVersions[*].[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]" \
--out table
queryオプションの設定は以下のようになります 結果は、Json形式で出力されます。
これを踏まえて絞り込む内容を記述します。
トップレベルが、DBEngineVersions[*]. (画像F 階層と項目)
DBEngineVersions[*] .[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]
下の階層(画像C 階層と項目)DBParameterGroupFamily項目)の値と、EngineVersion項目の値を
{key1:value,key2:value}のdict形式でフォーマットして、項目名を出力するようにする
5 RDSのエンジンを指定してそのエンジン情報のみ出力しよう！
5.1 エンジンにaurora-mysqlを指定
aurora-mysqlのみ出力したい場合は、engineにaurora-mysqlを指定します。
更にFamiryNameとVesionのみを出力するようにします。
aws rds describe-db-engine-versions --engine aurora-mysql \
--query "DBEngineVersions[*].[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]"\
--out table
5.2 エンジンにoracle-eeを指定
oracleの場合は、oracle-eeとoracle-seが利用可能です。–engineオプション にoracle-ee
まで指定する必要があります。
aws ds describe-db-engine-versions --engine oracle-ee \
--query "DBEngineVersions[*].[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]"\
--out table
6 VersionUp可能なエンジンを表示しよう！
6.1 MariaDB 10.2.37からバージョンアップ可能なRDS一覧
RDSを利用していると、現在利用しているエンジンのバージョンアップを要求される
ことがあります。どのバージョンにアップしたら良いのか（可能なのか）が
AWS CLIコマンドで確認できます。以下の例はmariadb 10.2.37からバージョンアップ
可能なエンジンの一覧を出力するものです。
echo 'mariadb 10.2.37 up'
aws rds describe-db-engine-versions \
--engine mariadb --engine-version 10.2.37 \
--query "DBEngineVersions[].ValidUpgradeTarget[].[{Des:Description,Auto:AutoUp
grade,Major:IsMajorVersionUpgrade,UpVersion:EngineVersion}]" \
--out table
queryオプションの指定はトップレベルが(画像K 階層と項目)DBEngineVersions 一つ下の
レベルがValidUpgradeTargetそこを全て見るのでDBEngineVersions[*].ValidUpgradeTarget[*]
その下の項目(画像L 指定項目)、Description,AutoUpgrade,IsMajorverVersion,EngineVersion
をDict形式で指定する
6.2 Oracle-ee 12.1.0.2.v2からバージョンアップ可能なRDS
以下の例はoracle-ee 12.1.0.2.v2からバージョンアップ可能なエンジンの一覧を出力するものです。
echo 'oracle-ee 12.1.0.2.v2 up'
aws rds describe-db-engine-versions \
--engine oracle-ee --engine-version 12.1.0.2.v2 \
--query "DBEngineVersions[].ValidUpgradeTarget[].[{Version:EngineVersion,Auto:
AutoUpgrade,Major:IsMajorVersionUpgrade}]" \
--out table
7.感想
RDSの情報でニーズがありそうな項目を出力するコマンドを実行してみました。
今利用のバージョンからバージョンアップ可能な物は何があるかは、良く問い合わせがあります。
何かのお役に立てば何よりです。
Linux版その１ EC2の情報出力 https://opt-p.co.jp/blog/aws/post-1633/
Linux版その３ VPCの情報出力 https://opt-p.co.jp/blog/aws/post-2080/
Linux版その４ 色々な情報出力 https://opt-p.co.jp/blog/aws/post-2421/
ストレリチア（極楽鳥花）の新葉がでました！
こんにちは！株式会社オプトプランニングです。
あっという間に桜も終わり、本日は穀雨の雨で少し肌寒く感じますね。
さて、当社の玄関入り口にあるストレリチア（極楽鳥花）という植物に、大きな新葉がつきました！
葉の色が明るくて、まだまだ柔らかいです。植物も春を感じているのでしょうか？！越冬したブルーベリーにも小さな新葉がついています。
ストレリチアは、極楽鳥花という名の通り、極楽鳥のようなオレンジ色の鮮やかな花をつけるそうです。南国風ですね。花を咲かせてくれることを信じて楽しみに待とうと思います！
リリースしてみた＜リリース編＞
はじめに
こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。
今回は、リリースをやってみようと思います！！
前回までのおさらいと気づき
今までのやってみたこと
前々回 は変更セットの作成を行いました。
そして 前回 は変更セットのアップロードを行い、送信変更セットのアップロード前後の違いを確認しました。
使用環境やリリースの内容については 利用環境と内容 を見てください。
前回のブログアップ後に気づいたこと
今回の本題であるリリースを行う前に、前回のブログアップ後に気づいたことを書いていきたいと思います。
前回、変更セットのアップロード前後の比較・確認を行うために画像を載せていました。
この部分に、前回は全く気づかなかったちょっとした違いがありました。
どこかわかりますか…？？
なんと、変更セットコンポーネントの「名前」が違うのです…！！！！！
リリース作業は実務でも行いましたが、アップロード後にコンポーネントの名前が変わることは気づいていませんでした…！！
なので、全てのコンポーネントの名前が変わるのか、特定の種別のコンポーネントだけなのかなどについても不明です…
今回に関しては、アップロード前はAPI参照名が表示されており、アップロード後は表示ラベルが表示されているようです。
（ちなみに、受信変更セットでは表示ラベルが表示されているようです。）
どうしてこのような動作になるか不明ですが、今まで一貫して以下の権限セット１つをコンポーネントに追加して作成した変更セットを使用しています。
この件については、なぜこのようなことが起こるのか・他の種類のコンポーネントの時はどうなるのかなど、詳細がわかり次第ブログでご紹介できるように調査を続けていきたいと思います。
（もしかしたら、プロファイル関係の変更セットだったからかな…？と思ったり…）
今回のブログでもコンポーネント名が入った画像が出てきますが、名前が違っても間違いなく同じ変更セットを使用していますので、特に注意書きなどありませんがそのように読み進めていただければと思います。
受信変更セットを確認してみた
初っ端から脱線してしまいましたが、話を戻してリリース作業を再開していきます！！
開発環境で作成した「送信変更セット」はアップロードすることによりリリース環境で「受信変更セット」として受け入れているはずです。
前回は送信変更セットのアップロード完了までの確認を行いましたので、まずはリリース環境の方で受信変更セットの確認から行っていこうと思います！
最初に、リリース環境である「T2Sandbox」にログインし、設定の検索ボックスに「変更セット」と入力して「受信変更セット」を開きます。
受信変更セットを開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。
受信変更セットの一覧が表示されます。
「リリース待ちの変更セット」に前回アップロードした変更セットを確認することができます！！
これで、リリース環境に変更セットのアップロードが無事に行われていることの確認ができました。
変更セット名の部分がリンクになっているので、クリックしてしてみましょう。
すると、変更セットの詳細画面が表示されます。
送信変更セットと違う点として、「ソース組織」があります。
（先ほどの受信変更セット一覧の画面でも確認することができます）
ここでどの環境からアップロードされた変更セットなのかを確認することができます。
また、「有効期限」もあります。
受信変更セットには有効期限が設けられています。
有効期限はアップロード後６か月です。
変更セットをアップロードして半年後にリリースを行うことはないと思いますが…
有効期限が切れると、変更セットは永久に削除されます。
引用：送信変更セットのアップロード（Salesforceヘルプより）
と書かれていますので、後から内容を確認したい時に確認ができない…！ということにならないように気を付ける必要はありそうです。
リリースしてみた
受信変更セットを使用してのリリース
受信変更セットの確認も終わりましたので、遂にリリースを行います…！！
ここまで長かった…！！
リリースは受信変更セットから行います。
受信変更セットの一覧を表示させ、先ほど確認した「リリース待ちの変更セット」のアクション欄にある「リリース」をクリックします。
すると、「変更セットのリリース」画面に移動します。
「テストオプションの選択」にいくつか選択できる項目がありますが、今回は「デフォルト」を選択し、「リリース」をクリックします。
このようなポップアップが立ち上がるので、「OK」をクリックします。
リリースが開始され、画面はリリースを行った変更セットの詳細画面に移ります。
変更セットの詳細の上部にさっきまで無かった「開始されたリリース」という強調表示があります。
この表示が、対象の変更セットが現在リリース中であることを表しています。
強調表示部分の「リリース状況」と書かれた部分はリンクになっており、リンク先では対象の変更セットの詳しいリリース状況を確認することができます。
クリックしてみるとリリース状況の画面に移動しました。
今回は変更セットのコンポーネントが少ないため、リリース状況をみるとすでに「成功」の一覧に表示されていました。
これでリリースは無事に完了です！！！
もしここでなんらかの理由でリリースができなかった場合、「失敗」の一覧に変更セット名が表示され、アクション欄の「詳細を表示」でエラー内容を確認することができます。
また、コンポーネントの数が多かったりApexやVFPがたくさん入っていると検証に時間がかかりますので、その時は気長に待ってみましょう。
リリースの確認
では、今回行ったリリースがちゃんと反映されているか確認してみます。
コンポーネントとして含めた権限セットを確認するため、設定の検索ボックスに「権限セット」と入力して「権限セット」を開きます。
表示される権限セットの一覧に、今回コンポーネントとして含めた「ユーザのMFA認証」が追加されていることが確認でき、ちゃんと変更セットでのリリースができていることがわかりました！！
リリース後の受信変更セットを確認してみた
受信変更セット一覧
リリースは無事に終わりましたが、リリース後の受信変更セットについても確認しておこうと思います。
まずは受信変更セット一覧の画面です。
リリースが成功すると、対象の変更セットは「リリース済みの変更セット」の欄に移動します。
また、「アップロード日」ではなく「リリース日」が表示されるようになります。
受信変更セット詳細画面
次に、リリース後の受信変更セットの詳細画面を確認してみます。
リリース中にあった強調表示がなくなる代わりに、「リリース履歴」が追加されています。
この部分、エラーでリリースが失敗した場合も履歴として追加されていきます。
エラーの場合、「アクション」の「詳細を表示」でエラー内容の詳細を確認することができます。
また、今回は行っていませんが「検証」を行った場合もこの履歴が追加されていきます。
「リリース待ちの変更セット」欄に表示されている変更セットで、この「リリース履歴」にエラーがある場合はリリースを行う前に内容を確認しておく方がいいでしょう。
リリース履歴には開始時刻と終了時刻が表示されているので、どのぐらいの時間でリリースが完了したか確認することもできます。
（今回のリリースは全く時間がかかっていないことが分かります。）
あとがき
リリースはあっけなく終わってしまいましたが、これで無事に変更セットを使用したリリースを完了することができました。
確認作業は別として、実際のリリースも変更セットの作成が一番比重の大きい作業だと思います。
今回は１つのコンポーネントでしたが、リリースするコンポーネントが増えるにつれエラーも起きやすいので、リリースでエラーがでたら変更セットの作り直し＆アップロードの繰り返し…を行っていくことになると思います。
変更セットの作り直しやアップロードのやり直し、使いまわしについて、実際にやってみてこのような使い方をすれば効率がいいかも…？と感じたことがいくつかあるので、近いうちにまとめをブログでアップできればと思います。
では、またお会いしましょう！！
リリースしてみた＜アップロード編＞
はじめに
こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。
今回は、リリースに向けて変更セットのアップロードをやってみようと思います！！
前回までのおさらい
前回 は送信変更セットを作成しました。
無事に作成できたのでアップロードを行おうとしたところ、このような画面が出てしまいました。
リリースするためには変更セットを作成するだけではできない…！！
ということに気づいたのが前回の変更セット作成編でした。
アップロードの準備をやってみた
アップロードに必要な設定とは
変更セットをアップロードするには、アップロード先の環境（変更セットを受け取る環境）でリリース接続の設定を行う必要があります。
デフォルトの状態では、本番組織・Sandbox問わず全環境で変更セットのアップロードを受け付けていない状態となっています。
そこで、どの環境からの変更セットを受け付けるか受け取る側の環境で設定する必要があります。
変更セットの作成はアップロード先の環境があってもなくてもできますし、リリース接続の設定は変更セットを作成する前に行っても後に行っても問題ありません。
リリース接続の設定を行う
今回は先に変更セットの作成を行ったので、次にアップロード先の「T2Sandbox」でリリース接続の設定を行います。（使用環境などは 前回の使用環境と内容 を参照）
変更セットの作成は「TSandbox」で行っていたので、現在のログインしている環境は「TSandbox」です。
まずは「T2Sandbox」に環境を変えるためログインし直します。
ログイン出来たら、設定の検索ボックスに「リリース」と入力して「リリース設定」を開きます。
リリース設定を開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。
リリース設定を開くとリリース接続先として組織の一覧が表示されます。
この一覧から、どの環境に対しての変更セットを受け付けるか個別に設定していくことになります。
「TSandbox」からの接続を許可したいので、「TSandbox」の左横にある「編集」をクリックします。
「リリース接続の詳細」画面が開くので、「アップロード認識方向」内の「変更着信を許可」にチェックをつけて「保存」をクリックします。
「保存」をクリックすると「リリース設定」の画面に戻ります。
リリース設定画面を見ると、先ほど設定を行った「TSandbox」の右端にある「アップロード認証方向」が変わっていることがわかります。
このような表示になっていれば、リリース接続の設定は完了です。
これで「TSandbox」から「T2Sandbox」へ変更セットをアップロードできるようになりました！！
送信側のリリースの設定を確認
アップロードを行う前に、送信側の「TSandbox」のリリース設定を確認してみたいと思います。
「TSandbox」にログイン後、先ほどと同様の手順でリリース設定を開くと、「TSandbox」から「T2Sandbox」に向けて矢印がついていることが確認できます。
アップロード認証方向は現在ログインしている環境を基準に表示されるので、「TSandbox」と「T2Sandbox」で表示のされ方が違いますが認証方向に違いはありません。
次に、組織一覧の中の「T2Sandbox」横の「編集」をクリックして詳細を開いてみます。
詳細を開くと、すでに「変更送信を受け入れる」にチェックがついていることが確認できます。
こちら、画像では分かりにくいですが「変更送信を受け入れる」のチェックボックスは操作することができないようになっています。
このチェックボックスは対象組織の「変更着信を許可」と連動しているようです。
他組織の受け入れ設定を変更することはできないので、リリース接続の変更を行うときは先ほど「T2Sandbox」を設定したように設定変更したい組織にログインする必要があります。
ちょっと脱線：相互で変更着信を許可してみた
「TSandbox」のリリース設定の確認ができたところで、相互に「変更着信を許可」するとどうなるかやってみます。
保存をしてリリース設定画面に戻ってくると、「アップロード認証方向」の矢印が両方向に変わっていました。
それぞれ設定すれば相互にアップロードを許可できることがわかりました。（実際に設定するかは別として）
変更着信の設定は対象組織にログインすれば簡単なので、想定と違う組織にアップロードすることを防ぐためにもどの組織でどのように変更を許可しているかの管理は行わなければならないでしょう。
変更セットのアップロード再挑戦してみた
変更セットのアップロード：二回目
少し寄り道してしまいましたが、変更セットのアップロードに再挑戦します。
前回 と同様に「アップロード」をクリックすると、対象組織として「T2Sandbox」が表示されるようになりました。
「T2Sandbox」が選ばれていることを確認して、「アップロード」をクリックします。
今回は無事にアップロードができました！！
アップロードを行うのに少し時間がかかる場合がありますが、完了のメールも送られてきますよ。
アップロード前後の変更セットの違い
アップロード前後で何が変わるのか詳細画面を見比べてみました。
アップロード前後で変わることとして
- 状況の変化
- 「編集」ボタンの有無
- 変更セットアップロード履歴の有無
- 変更セットコンポーネントのアクションの変化
が挙げられます。
状況の変化としては、アップロード前が「オープン」アップロード後が「クローズ」に変化します。
また、アップロードするまではコンポーネントの追加及び削除といった編集を行うことができますが、アップロード後はそれらができなくなり、コンポーネントのアクションが「削除」から「ソースを表示」に変わります。
一番の違いは変更セットアップロード履歴の有無です。
アップロード後はどの組織にいつ誰がアップロードを行ったかという情報が追加されます。
あとがき
リリース接続を行うことで無事にアップロードができました。
後はリリースするだけ…となりましたが、変更セットのアップロードについて掘り下げていたら長くなってしまったので、リリースについては次回に持ち越したいと思います。
また、アップロード関連についてはまだ書き足りないことがあるので近いうちに別で紹介しようと思います。
リリースはあと少しで完了しそうですが、何事もなく進むといいな…
では、またお会いしましょう！！