Apexを使った簡単なメール送信方法

セールスフォース

 SFDCからメールを送信する方法は色々とありますが、今回はApexを使った簡単なメール送信方法を紹介します。

 Apexコードを使用するとApexトリガーやApexスケジューラからメールを送信することができます。
 Apexからメール送信する方法には「単一メール送信」と「一括メール送信」があります。今回は「単一メール送信」を使った方法を説明します。
 さらにメール本体についてはApexの中でメール本体を作成する方法と「メールテンプレート」を使う方法がありますが、ここではメール本体をApexの中で作成します。

1.メールアドレス保存用カスタムオブジェクトの作成

 メール送信先を登録するための以下のようなカスタムオブジェクト(MailMember)を作成します。

カスタムオブジェクト(メールメンバー)
図1 カスタムオブジェクト(MailMember)

2.Apexでのメール作成と送信

 Apexでメールを作成し、送信する部分のコードは以下となります。

List<String>mailAdderList = new List<String>();

String mailMsg = '連絡事項';

List<MailMember__c>mailMember = [select id,Name,mailAddress__c from MailMember__c];
for(MailMember__c mM:mailMember){
  mailAdderList.add(mM.mailAddress__c);
  mailMsg += '\n';
  mailMsg += nM.name;
}
mailMsg += '\n';
mailMsg += 'メッセージを入力';

Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();

mail.setToAddresses(mailAdderList);
mail.setSubject('Test Mail Subject');
mail.setPlainTextBody(mailMessage);
mail.setUseSignature(false);
mail.setBccSender(false);
mail.setSenderDisplayName('メール送信者名入力');

List<Messaging.SendEmailResult> results = 
  Messaging.sendEmail(new List<Messaging.SingleEmailMessage>{mail},false);
for (Messaging.SendEmailResult result : results) {
    if (!result.isSuccess()) {
        System.debug(LoggingLevel.ERROR, result.getErrors()[0]);
    }
}

 コードの簡単な説明です。

 List<mailMember__c>mailMemberで送信先メールアドレスを保存します。

 new Messaging.SingleEmailMessage()により「単一メール送信」のインスタンスを作成します。

 mail.setToAddresses()にて送信先アドレスを設定します。設定できるアドレスは100件までです。

 mail.setSubject()にてメールサブジェクトを設定します。

 メール本体(メールのBody部)はmail.setPlainTextBody()にて作成します。

 メールの署名とBccは不要なので、setUseSignature()/setBccSender()にfalseを設定します。

 mail.setSenderDisplayName()でFrom行に表示される送信者表示名を設定します。   setOrgWideEmailAddressId()で組織の送信元のアドレスIDを設定した場合には設定できません。

 また、setOrgWideEmailAddressId()で添付ファイルをsetOrgWideEmailAddressId()で返信先メールアドレスを設定することができます。

 最後に、Messaging.sendEmail()でメールを送信します。2つ目の引数の指定は省略可能でデフォルトはtrueです。trueの場合、任意のsendEmailで失敗した場合、その他すべてのメッセージを送信しない、falseの場合は、メッセージを送信します。
 このメソッドはApex トランザクションごとに 10 回コールすることができます。

 Messaging.sendEmail()の結果はList<Messaging.SendEmailResult> resultsで受け取ることができます。配列で返却された結果に対してisSuccess()メソッドを実施することで結果を取得することができます。isSuccess()の結果がfalseの場合、getError()を使い、sendEmailErrorオブジェクトを取得することができます。エラーとなるのは送信時のエラーで、送信先に到達したか否かは関係ありません。

3.NO_MASS_MAIL_PERMISSIONエラー

 メール送信を実行した場合に「NO_MASS_MAIL_PERMISSION」というエラーが出る場合があります。これは「メールを送信するためのアクセス権」がない場合に発生します。設定により、権限を「すべてのメール」に変更します。

1.検索窓で「送信」を入力
2.メールメニューの「送信」を選択

図2 メールのアクセス権の設定(1)
【図2 メールのアクセス権の設定(1)】

3.アクセス権で「すべてのメール」を選択

図3 メールのアクセス権の設定(2)
【図3 メールのアクセス権の設定(2)】
【図4】メールのアクセス権の設定(3)
【図4】メールのアクセス権の設定(3)

社内 野の花画伯から その2

紫陽花。6月の梅雨にピッタリの花です。

万葉集にも詠まれている歴史の古い花。原産地は日本。
江戸~明治時代にヨーロッパに渡り、西洋アジサイとして
逆輸入されました。

従来は青系とピンク系が主流でしたが、現在は白のアジサイや
ピラミッド形のカシワバアジサイなどがあります。
ガクアジサイは額に囲まれているように見えるので、
ガクアジサイと呼ばれています。

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分前に試験開始のボタンが現れると覚えておいて下さい!!

試験開始ボタンを押すと、試験の注意事項などの最終確認の画面に遷移します。

動画の案内もあるので、それを見つつ準備ができたらセンチネルの起動ボタン(だったかな?この辺りはうろ覚えです…)を押します。

センチネルが起動しない・・・

はい、試験開始ボタンを押した後、センチネルが起動しないエラーが発生しました…(泣)
エラー後、再度試験開始ボタンとセンチネル起動ボタンを押しますが、エラー連発で刻々と予約時間に近づき、メチャメチャ焦りました…(号泣)

5回ほど試してダメだったので、チャット経由でサポートに連絡しました!!!

カスタマーサポートセンターへ連絡してみる

私が行った連絡方法としては、まずWebassessorログイン画面にあるオンライン受験のチャット問い合わせの「こちら」をクリックします。

Webassessorログイン画面にあるチャットへのリンク
Webassessorログイン画面にあるチャットへのリンク

すると、KryterionのHPが開くので、右下のポップアップをクリックします。

リンク先のKryterionホームページ
リンク先のKryterionホームページ

氏名やメールアドレスの記入フォームが立ち上がるのでそれぞれ記入し、問い合わせ内容として正しそうなものを選び、下にある「チャットを開始」をクリックします。
(全て英語の選択肢でしたが、私の場合「Online Exam Technical Help」が妥当そうだったのでこれを選んだと思います…焦っていたのでここもうろ覚え。)

チャットの記入フォーム
チャットの記入フォーム

チャットが起動して少し経つと、オペレーターの方が英語で連絡をくれました。(日本語に訳すと「何にお困りですか?」みたいな感じだったと思います)
しかし、私はすでにチャット入力欄に「センチネルが起動せず試験ができない」と日本語で入力していました。
焦りすぎていたので、一旦そのまま日本語で送り、翻訳サイトで英語に直してチャットに入力し直そうとしていたところ…

なんと、返答が日本語で返ってきました!!!

翻訳したような日本語だったので、オペレーターの方が英語を日本語に翻訳して対応してくれたみたいです。
念のため、日本語でもいいですか?と聞いたら、大丈夫との返信がありました。
私と同じように何かトラブルに遭遇した方は、チャットで英語が送られてきても日本語で送ってみてもいいかもしれません。
焦りすぎていたので、この対応は本当に感謝しかありません。
対応してくれたオペレーターの方、あの時はありがとうございました…!

そんなこんなでエラー状況を詳しく説明すると、一度センチネルをアンインストールし、指定のファイルをインストール後、センチネルを再インストールするよう指示があり、、、

無事にセンチネルを起動することができました!!!!

サポートでのやり取りでおそらく20分ほど経過していたと思いますが、無事に受験することができました。

試験開始~終了まで(眼鏡の人の場合)

センチネル起動後、事前に登録したバイオメトリックの顔認証も済ませ、いよいよ試験開始です!

しかし、私は眼鏡をかけています。
眼鏡の場合は、チェックを行うと受験ガイドにありましたが、いつやるんだろうなぁ~なんて思いながら問題を解いていると・・・

急に眼鏡を確認する旨の画面に変わりました!!!

3~4問目の問題文に目を通しているところだったと思うので、時間にすると開始から5分少々経過したころでしょうか?
音声での案内はなく、切り替わった画面に「Glasses」の文字とカメラに眼鏡を近づけて見せるようなアニメーション(?)があったと思います。
(ここもうろ覚えですが、英語が得意ではない私にもすぐ眼鏡の確認だ!とわかりました。)

確認ができたら自動で試験再開すると思っていましたが、「試験に戻る」ボタン(うろ覚えです)があったので、確認ができたかの有無は無いと判断し、眼鏡を外してPCのカメラに近づけた後、前後左右に眼鏡を動かして止める、というのを5秒間隔で念のため2回繰り返し、「試験に戻る」を押して試験を再開させました。

試験時間は比較的余裕があったので、後から見直すためにチェックをしておいた問題の見直しをしてから全体を再度見直し、時間ギリギリまで粘りました。

試験終了!!

なんとか合格…!!

ギリギリまで問題を解き、試験終了のボタンをクリックすると、正答率と合否が記載された画面に切り替わりました。

初めての試験だったのですぐに結果が出てビックリしました!と言いたいところなのですが、試験に集中し疲れていたためすぐには状況を呑み込めなかったです(笑)

少したってから合格メールなどが送られてきてやっと実感することができました~

センチネルの起動エラーなどがあり試験の開始が予定より大幅に遅れたものの、試験時間が短くなったりはありませんでした。(試験中は時計は見れませんが残り時間が表示されており、開始した時に105分だったのを確認しています。)

また、私の場合試験中に眼鏡の確認がありましたが、その間は試験時間が表示されていなかったため試験時間に影響はなかったと思います。(当たり前ではありますが…)

あとがき

なんとか一度目の試験で合格することができてほっとしています。

振り返ってみると、トラブルに遭遇した方の受験記などを事前に読んでいたため、チャットでサポートに連絡する行動へ移れたと思います。
トラブルが起こっても一旦落ち着いて冷静に、と思っていてもなかなかそうはいかないものですね~

年内にもう一つSFDCに関する資格を取りたいな~と思っているので、受験の合否に関わらず勉強方法などを書いていけたらと思います。

それでは、またお会いしましょう!!

消防訓練実務研修レポート

こんにちは!株式会社オプトプランニング、安全衛生・健康推進委員です。
職場の安全管理の一環として受講した「消防訓練実務研修」のレポートをします。

場所は、広島市総合防災センターで行われました。
http://www.bousai-c.city.hiroshima.jp/index.htm

研修の内容は主に、
 1.防火管理について
 2.避難訓練について
 3.消防用設備について

でした。

実際の炎を前にしての消化訓練は、水用消火器ではなく、本物の消火器で消化を体験しました。
炎は、3~5メートル離れていても熱いです。緊張のせいか、消火器のピンが抜けずに焦りました。

そして、ホースでの水放出は、水の勢いに体がとられ、狙う位置に水が届きにくい。
消化は初期消火が大切とのこと。いざという時は、しっかり消さないといけません。

スプリンクラーの水量も見学しましたが、当然ですが水量が半端ないですね!

中でも、最も印象に残っているのは、煙の訓練でした。
照明のない暗闇で煙に巻かれると、本当に何も見えませんし、閉じ込められてパニックです。


こういう時に働く『正常性のバイアス』という心理は、
「自分にとって不都合なものを過小評価する傾向がある」
ことだそうです。

また、火災パニックの習性として、
 ・日常導線指向性:日常使いなれた通路を使う傾向
 ・帰巣性:入ってきた経路を戻ろうとする傾向
 ・向光性:暗闇で明るい方へ向かう傾向
 ・危険回避性:目前の危機のみを回避しようとする傾向
 ・追従性:多くの人が逃げる方向へ追従して逃げる傾向
があるとのこと。


自分は大丈夫と思っていても、いざという時は冷静さを保てるか。
日頃の訓練が重要と痛感しました。
「知っている」と「実際出来る」とでは、大きな違いがある、と講師の方も説明されていました。

今回受講させていただいた講座で、火災での危機管理、防災意識を高めることができました。
日頃から、全社で共有しておきたいと感じました!

社内 野の花画伯から

あなたは、どの花が好きですか?

初めて、花ではなく魚を描きました。

漢字「目張」と書き、飛び出しそうな大きな目が特長です。


黒メバルは、瀬戸内海「春告げ魚」の一つです。絵に加えて
‟人生限りなく楽し”の文字を追加しています。

どんなつらいことがあっても、何でもあきらめたらいかん。
いつかきっと春が来るぞ、という気持ちで描きました。

変更セットの上手な使いまわし術

気づき

はじめに

こんにちは!株式会社オプトプランニングです。

先日リリースについて書きましたが、その際書けなかったクローズ後の変更セットの私なりの使い方を忘備録も兼ねて書いていきたいと思います。

クローズした変更セットの利用方法その1

同じ変更セットを使いまわす

まずは、変更セットの再利用です。

  • 同じ変更セットを複数の組織にリリースする必要がある
  • 本番組織をベースに作成したSandbox環境でリリースの評価・テストを行い、問題なかったので同じ内容の変更セットを本番環境にリリースしたい

など、同一内容の変更セットを別組織にリリースしたい場面はあると思います。

クローズした変更セットは編集はできなくなりますが「アップロード」ボタンは残っています。
これを利用し、クローズした変更セットを別環境にアップロード・リリースすること(再利用)ができます。
(※クローズした変更セットに含まれるコンポーネントは、変更セット作成後に削除や修正をしていない場合に限ります。詳しくは後ほど説明します。)

アップロードする際、対象組織に対してリリース接続の設定を行うことが必要ですので、そこは忘れずに行いましょう。

1つの変更セットを再利用する良い点は、「変更セットアップロード履歴」が残ることです。
アップロードする度に残るので、後からどの組織にアップロードしたかの確認ができます。

図1 2つの組織にアップロードした後の変更セットアップロード履歴
図1 2つの組織にアップロードした後の変更セットアップロード履歴

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にあるように変更セットのコピーを行ってください。

クローズ後の変更セットのアップロード方法

変更セットのアップロードボタンは、送信変更セットの一覧や変更セットの詳細にあります。

図2 送信変更セット一覧画面
図3 送信変更セットの詳細画面
図3 送信変更セットの詳細画面

クローズ後の変更セットをアップロードしようとすると図5のような画面になります。
変更セットをどの環境にもアップロードしていない図4の時と比べてみると、

この変更セットをアップロードすると、編集できなくなり、対象組織から取り消すこともできません。

というメッセージがクローズした変更セットに表示されていないことがわかります。

既にクローズしている変更セットはそもそも編集することができないため、注意書きが現れないようです。

図4 オープンの変更セットアップロード時のアップロード詳細
図4 オープンの変更セットアップロード時のアップロード詳細
図5 クローズの変更セットアップロード時のアップロード詳細

使いまわす時の注意点その1

1つ目に注意したいのは、すでにアップロードした組織も選択できる点です。

同じ変更セットを複数回にわたって同一環境にアップロードしても特に問題は起きません。
逆を言えば、エラーも出ないということです。

アップロードは成功したのにアップロードしたはずの環境(対象組織)に受信変更セットがみつからない…?という時はアップロード先に間違いがないか確認しましょう。

アップロード先は、変更セットアップロード履歴やアップロード完了の通知メールで確認できます。
アップロード完了の通知メールには、送信変更セットのソース組織と対象組織が明記されています。

参考までに、「リリースしてみた<アップロード編>」で載せなかったアップロード完了の通知メールはこんな感じです。
システムメールとしてSalesforceから送られてきます。

図6 アップロード完了のシステムメール
図6 アップロード完了のシステムメール

使いまわす時の注意点その2

2つ目の注意点としては、1度にアップロードできる対象組織は1つだけという点です。
アップロード先を選択する画面はラジオボタンで構成されており、複数の組織を選択することは不可能となっています。

図7 アップロード時の対象組織の選択画面
図7 アップロード時の対象組織の選択画面

複数の組織に同じ変更セットをアップロードしたい場合はそれぞれアップロード手順を行う必要があります。

使いまわす時の注意点その3

3つ目の注意点としては、クローズした変更セットに含まれるコンポーネントは更新されないという点です。

例えば、前回のリリースしてみた<変更セット作成編>で追加した権限セット「MFA」について、変更セットアップロード後に修正を加えたとします。
アップロード後の変更セット(クローズした変更セット)はコンポーネントの更新が行われないので、権限セット「MFA」に行ったは反映されません。

変更セットに変更はないが、変更セットのコンポーネントの内容に変更がある場合は、「変更セットのコピー」を作成しないと修正内容を反映することはできません。

コンポーネントの更新という考え方が少し難しく感じますね…

図8 送信変更セット詳細に書かれている内容
図8 送信変更セット詳細に書かれている内容

クローズした変更セットの利用方法その2

変更セットのコピーを作成し編集する

クローズした変更セットは編集することはできませんが、コピーを作成することは可能です。
また、作成したコピーに対しては変更セットの編集ができます!!

このことを利用し、クローズした変更セットを編集したい時はコピーを作成するといいと思います。

  • リリースでコンポーネント不備によるエラーが出た
  • リリースでエラーも無く一安心した後に、リリース環境の確認を行っていて入れそびれたコンポーネントがあることに気づいてしまった

などなど、変更セットの作り直しが発生してしまうのはよくあることだと思います。(きっと私だけじゃない…はず 笑)

リリースしそびれたコンポーネントだけの変更セットを新しく作成してもいいのですが、

  • エラーやコンポーネント不足の度に変更セットを作成すると、沢山の変更セットが作られてしまう
    →どんな内容の変更セットをアップロード(リリース)したか履歴を確認する可能性があるため、リリース内容をなるべく1つの変更セットにまとめておきたかった
  • 「連動関係を参照/追加」を使用することで、変更セットに含めたい関連するコンポーネントが探し出しやすい

といった理由から、変更セットのコピーを作成しコンポーネントを追加(削除)する、ということを行いました。

変更セットのコピーの作り方

変更セットのコピーはとても簡単に作成できます。
対象の変更セットの「コピー」をクリックするだけです。

アップロードと同様、「コピー」は、送信変更セットの一覧や変更セットの詳細にあります。

図9 送信変更セット一覧画面
図10 送信変更セットの詳細画面
図10 送信変更セットの詳細画面

コピーをクリックすると、「変更セットのコピー」に遷移し、ここで変更セットの名前や説明を変えることができます。

ベースの変更セットと混同しないためにも、名前や説明はコピーであることが分かりやすいものに変更しておいた方がいいと思います。

図11ではすでに名前や説明を変更してありますが、「変更セットのコピー」の名前と説明にはデフォルトでベースの変更セットと同じ内容がそれぞれ入力されています。

図11 変更セットのコピー作成時の入力画面
図11 変更セットのコピー作成時の入力画面

変更セットのコピーを保存すると、ベースの変更セットのコンポーネントを引き継いだ「状況」がオープンの変更セットが出来上がります。

あとは、新規作成の時と同様にコンポーネントの追加を行ったり、不要なコンポーネントの削除を行いましょう。

あとがき

変更セットのコンポーネントの種類は、作成したことがある方ならわかると思いますがとても沢山あります。
以前どのぐらいあるか調べた時は約120種類ありました。(2021年12月ぐらいに調べました)

中には見たことのないコンポーネント種類名もあったりしたので、変更セットの作成は本当に大変な作業だと思います。

今回は、クローズ後の変更セットに焦点を当てて使い道について書いてみました。
クローズ後に限らず、良い使い道を思いついたら第二弾としてまとめられればと思います。

それでは、またお会いしましょう!!

関連記事
リリースしてみた<変更セット作成編>
リリースしてみた<アップロード編>

体に『美味しい』スイーツ作りに挑戦!

こんにちは!株式会社オプトプランニングの健康推進委員です。

当社でのいろいろな健康経営の取り組みに刺激され、健康的なスイーツ作りに挑戦しました。
以前から料理は好きで、中でも特にスイーツは食べるもの、作るもの大好です。
家にある残りもので、何かできないかな・・と考え、作るのにはまっております。


今回は、お安くなっていた「麦芽コーヒー豆乳」が冷蔵庫に残っていたので、
『コーヒー豆乳ババロア』を作ってみました。

使用したのは市販の麦芽コーヒー豆乳(もちろんカロリー50%OFF)と豆乳入りホイップクリーム、後はゼラチンと卵黄、グラニュー糖です。

作り方は普通のババロアと同じです。
今回はアレンジでチョコレートソースをのせて作ってみました。
お味は・・なかなか美味しくできたと思います(自画自賛)!

豆乳に含まれる栄養素と言えば、代表的な大豆イソフラボンをはじめ、たんぱく質、サポニンに
ビタミンEなど健康に良いものがいっぱい!
飲むのには、少しくせがありますが、このようにスイーツにすると美味しく食べられます。

ざっくり栄養計算していみると・・1個当り約160Kcal・・
一日のうち間食にあてることができるカロリーは200Kcal。
できればもう少しカロリーを落としたいですね。
チョコレートソースのカロリーが高いので、コーヒーソースにしたり、使用する砂糖を
ノンカロリーの砂糖にしたり、まだまだ試行錯誤の余地はありそうです。

目標のカロリーは120Kcal。美味しさはそのままで体に健康的なスイーツに
なるようにもう少し試作してみます。
納得のいくレシピができたら、ぜひ皆さんにも紹介したいと思います!

AWS CLIで情報を出力しようRDS編(Linux版-その2)

 RDSってどんな製品(エンジン)が利用できるのだろうか。一覧とかだして、確認
することができたらいいな。AWSコンソールから操作すると、もし、何かミスをし
て、他のシステムに影響があったら困るし、課金されても困る。どんなエンジンが
あるかどうかさえ分かれば、いいのに。こんな時には、AWS CLIを使いましょう。

1.現在利用中のRDSの情報を出力しよう!

利用中のRDS一覧を出力する場合は、以下のコマンドを実行します。

aws rds describe-db-instances

画像A RDSの情報
                画像A RDSの情報

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

画像B 項目を絞って出力
               画像B 項目を絞って出力
              画像C 項目と階層

3.利用可能なRDSのEngineとVersion情報を出力しよう!

利用中のリージョンで、利用可能なRDS一覧を見たい場合に以下のコマンドを実行します。

aws rds describe-db-engine-versions

画像D 出力結果
                画像D 出力結果

json形式でどばーっと出力されます

4 出力する情報を絞り込んでみよう!

オプションのqueryを使用することで絞り込みができます。
以下の例はDBParameterGroupFamilyとEngineversionのみに絞ったものです。
DBParameterGroupFamilyが、このDBパラメータグループファミリー互換性のある名前で
EngineVersion が、このエンジンのバージョンです。

aws rds describe-db-engine-versions \
--query "DBEngineVersions[*].[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]" \
--out table

画像E FamiryNameとVersion出力
            画像E FamiryNameとVersion出力

queryオプションの設定は以下のようになります 結果は、Json形式で出力されます。
これを踏まえて絞り込む内容を記述します。
トップレベルが、DBEngineVersions[*]. (画像F 階層と項目)
DBEngineVersions[*] .[{FamiryName:DBParameterGroupFamily,Vesion:EngineVersion}]
下の階層(画像C 階層と項目)DBParameterGroupFamily項目)の値と、EngineVersion項目の値を
{key1:value,key2:value}のdict形式でフォーマットして、項目名を出力するようにする

画像F 階層と項目
               画像F 階層と項目

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

画像G RDS aurora-mysql
              画像G RDS aurora-mysql

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

画像H oracle-ee
                画像H oracle-ee

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

画像J marriadb 10.2.37からバージョンアップ可能なRDS
     画像J marriadb 10.2.37からバージョンアップ可能なRDS

queryオプションの指定はトップレベルが(画像K 階層と項目)DBEngineVersions 一つ下の
レベルがValidUpgradeTargetそこを全て見るのでDBEngineVersions[*].ValidUpgradeTarget[*]
その下の項目(画像L 指定項目)、Description,AutoUpgrade,IsMajorverVersion,EngineVersion
をDict形式で指定する

画像K 階層と項目
                 画像K 階層と項目
画像L 指定項目
                 画像L 指定項目

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

画像M oracle12.0.1.2V2からバージョンアップ可能なRDS一覧
画像M oracle12.0.1.2.V2からバージョンアップ可能なRDS一覧 (画像を一部加工してます)

7.感想

RDSの情報でニーズがありそうな項目を出力するコマンドを実行してみました。
今利用のバージョンからバージョンアップ可能な物は何があるかは、良く問い合わせがあります。
何かのお役に立てば何よりです。

Linux版その1 EC2の情報出力 https://opt-p.co.jp/blog/aws/post-1633/

Linux版その3 VPCの情報出力 https://opt-p.co.jp/blog/aws/post-2080/

Linux版その4 色々な情報出力 https://opt-p.co.jp/blog/aws/post-2421/

ストレリチア(極楽鳥花)の新葉がでました!

こんにちは!株式会社オプトプランニングです。

あっという間に桜も終わり、本日は穀雨の雨で少し肌寒く感じますね。

さて、当社の玄関入り口にあるストレリチア(極楽鳥花)という植物に、大きな新葉がつきました!

葉の色が明るくて、まだまだ柔らかいです。植物も春を感じているのでしょうか?!越冬したブルーベリーにも小さな新葉がついています。

ストレリチアは、極楽鳥花という名の通り、極楽鳥のようなオレンジ色の鮮やかな花をつけるそうです。南国風ですね。花を咲かせてくれることを信じて楽しみに待とうと思います!

リリースしてみた<リリース編>

Salesforceでやってみた

はじめに

こんにちは!株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。

今回は、リリースをやってみようと思います!!

前回までのおさらいと気づき

今までのやってみたこと

前々回 は変更セットの作成を行いました。

そして 前回 は変更セットのアップロードを行い、送信変更セットのアップロード前後の違いを確認しました。

使用環境やリリースの内容については 利用環境と内容 を見てください。

前回のブログアップ後に気づいたこと

今回の本題であるリリースを行う前に、前回のブログアップ後に気づいたことを書いていきたいと思います。

前回、変更セットのアップロード前後の比較・確認を行うために画像を載せていました。
この部分に、前回は全く気づかなかったちょっとした違いがありました。

どこかわかりますか…??

なんと、変更セットコンポーネントの「名前」が違うのです…!!!!!

図1 送信変更セットアップロード前
図1 送信変更セットアップロード前
図2 送信変更セットアップロード後
図2 送信変更セットアップロード後

リリース作業は実務でも行いましたが、アップロード後にコンポーネントの名前が変わることは気づいていませんでした…!!

なので、全てのコンポーネントの名前が変わるのか、特定の種別のコンポーネントだけなのかなどについても不明です…

今回に関しては、アップロード前はAPI参照名が表示されており、アップロード後は表示ラベルが表示されているようです。
(ちなみに、受信変更セットでは表示ラベルが表示されているようです。)

どうしてこのような動作になるか不明ですが、今まで一貫して以下の権限セット1つをコンポーネントに追加して作成した変更セットを使用しています。

図3 権限セット:ユーザのMFA認証
図3 権限セット:ユーザのMFA認証

この件については、なぜこのようなことが起こるのか・他の種類のコンポーネントの時はどうなるのかなど、詳細がわかり次第ブログでご紹介できるように調査を続けていきたいと思います。
(もしかしたら、プロファイル関係の変更セットだったからかな…?と思ったり…)

今回のブログでもコンポーネント名が入った画像が出てきますが、名前が違っても間違いなく同じ変更セットを使用していますので、特に注意書きなどありませんがそのように読み進めていただければと思います。

受信変更セットを確認してみた

初っ端から脱線してしまいましたが、話を戻してリリース作業を再開していきます!!

開発環境で作成した「送信変更セット」はアップロードすることによりリリース環境で「受信変更セット」として受け入れているはずです。

前回は送信変更セットのアップロード完了までの確認を行いましたので、まずはリリース環境の方で受信変更セットの確認から行っていこうと思います!

最初に、リリース環境である「T2Sandbox」にログインし、設定の検索ボックスに「変更セット」と入力して「受信変更セット」を開きます。

受信変更セットを開いた時、「リリースの情報」という画面に変わった場合は、下へスクロールして最下部にある「次へ」をクリックしましょう。

図4 受信変更セット:リソースの理解1
図4 受信変更セット:リソースの理解1
図5 受信変更セット:リソースの理解2
図5 受信変更セット:リソースの理解2

受信変更セットの一覧が表示されます。

「リリース待ちの変更セット」に前回アップロードした変更セットを確認することができます!!

これで、リリース環境に変更セットのアップロードが無事に行われていることの確認ができました。

変更セット名の部分がリンクになっているので、クリックしてしてみましょう。

図6 受信変更セットの一覧
図6 受信変更セットの一覧

すると、変更セットの詳細画面が表示されます。

送信変更セットと違う点として、「ソース組織」があります。
(先ほどの受信変更セット一覧の画面でも確認することができます)
ここでどの環境からアップロードされた変更セットなのかを確認することができます。

また、「有効期限」もあります。
受信変更セットには有効期限が設けられています。
有効期限はアップロード後6か月です。

変更セットをアップロードして半年後にリリースを行うことはないと思いますが…

有効期限が切れると、変更セットは永久に削除されます。

引用:送信変更セットのアップロード(Salesforceヘルプより)

と書かれていますので、後から内容を確認したい時に確認ができない…!ということにならないように気を付ける必要はありそうです。

図7 受信変更セットの詳細画面
図7 受信変更セットの詳細画面

リリースしてみた

受信変更セットを使用してのリリース

受信変更セットの確認も終わりましたので、遂にリリースを行います…!!
ここまで長かった…!!

リリースは受信変更セットから行います。

受信変更セットの一覧を表示させ、先ほど確認した「リリース待ちの変更セット」のアクション欄にある「リリース」をクリックします。

図8 受信変更セットの一覧
図8 受信変更セットの一覧

すると、「変更セットのリリース」画面に移動します。

「テストオプションの選択」にいくつか選択できる項目がありますが、今回は「デフォルト」を選択し、「リリース」をクリックします。

図9 変更セットのリリース
図9 変更セットのリリース

このようなポップアップが立ち上がるので、「OK」をクリックします。

図10 「リリース」クリック後のポップアップ
図10 「リリース」クリック後のポップアップ

リリースが開始され、画面はリリースを行った変更セットの詳細画面に移ります。

変更セットの詳細の上部にさっきまで無かった「開始されたリリース」という強調表示があります。
この表示が、対象の変更セットが現在リリース中であることを表しています。

強調表示部分の「リリース状況」と書かれた部分はリンクになっており、リンク先では対象の変更セットの詳しいリリース状況を確認することができます。

図11 リリース中の受信変更セット詳細画面
図11 リリース中の受信変更セット詳細画面

クリックしてみるとリリース状況の画面に移動しました。

今回は変更セットのコンポーネントが少ないため、リリース状況をみるとすでに「成功」の一覧に表示されていました。

これでリリースは無事に完了です!!!

もしここでなんらかの理由でリリースができなかった場合、「失敗」の一覧に変更セット名が表示され、アクション欄の「詳細を表示」でエラー内容を確認することができます。

また、コンポーネントの数が多かったりApexやVFPがたくさん入っていると検証に時間がかかりますので、その時は気長に待ってみましょう。

図12 リリース状況:成功
図12 リリース状況:成功

リリースの確認

では、今回行ったリリースがちゃんと反映されているか確認してみます。

コンポーネントとして含めた権限セットを確認するため、設定の検索ボックスに「権限セット」と入力して「権限セット」を開きます。

表示される権限セットの一覧に、今回コンポーネントとして含めた「ユーザのMFA認証」が追加されていることが確認でき、ちゃんと変更セットでのリリースができていることがわかりました!!

図13 権限セット一覧
図13 権限セット一覧

リリース後の受信変更セットを確認してみた

受信変更セット一覧

リリースは無事に終わりましたが、リリース後の受信変更セットについても確認しておこうと思います。

まずは受信変更セット一覧の画面です。

リリースが成功すると、対象の変更セットは「リリース済みの変更セット」の欄に移動します。
また、「アップロード日」ではなく「リリース日」が表示されるようになります。

図14 受信変更セット一覧:リリース済みの変更セット
図14 受信変更セット一覧:リリース済みの変更セット

受信変更セット詳細画面

次に、リリース後の受信変更セットの詳細画面を確認してみます。

リリース中にあった強調表示がなくなる代わりに、「リリース履歴」が追加されています。

図15 受信変更セット詳細画面:リソース履歴
図15 受信変更セット詳細画面:リソース履歴

この部分、エラーでリリースが失敗した場合も履歴として追加されていきます。
エラーの場合、「アクション」の「詳細を表示」でエラー内容の詳細を確認することができます。

また、今回は行っていませんが「検証」を行った場合もこの履歴が追加されていきます。

「リリース待ちの変更セット」欄に表示されている変更セットで、この「リリース履歴」にエラーがある場合はリリースを行う前に内容を確認しておく方がいいでしょう。

図16 リリース履歴:失敗あり
図16 リリース履歴:失敗あり
図17 リリース履歴:リリースと検証成功
図17 リリース履歴:リリースと検証成功

リリース履歴には開始時刻と終了時刻が表示されているので、どのぐらいの時間でリリースが完了したか確認することもできます。
(今回のリリースは全く時間がかかっていないことが分かります。)

あとがき

リリースはあっけなく終わってしまいましたが、これで無事に変更セットを使用したリリースを完了することができました。

確認作業は別として、実際のリリースも変更セットの作成が一番比重の大きい作業だと思います。

今回は1つのコンポーネントでしたが、リリースするコンポーネントが増えるにつれエラーも起きやすいので、リリースでエラーがでたら変更セットの作り直し&アップロードの繰り返し…を行っていくことになると思います。

変更セットの作り直しやアップロードのやり直し、使いまわしについて、実際にやってみてこのような使い方をすれば効率がいいかも…?と感じたことがいくつかあるので、近いうちにまとめをブログでアップできればと思います。

では、またお会いしましょう!!

関連記事
リリースしてみた<変更セット作成編>
リリースしてみた<アップロード編>