広島で(1)AI活用講座（経営者様向け、社内推進者様向け、活用基礎等）、(2)クラウドサービス（AWS・Azure・GCP）の提供、(3)Webシステム・スマホアプリ開発をおこなう、オプトプランニングのブログです。
こんにちは！株式会社オプトプランニングです。
あっという間に桜も終わり、本日は穀雨の雨で少し肌寒く感じますね。
さて、当社の玄関入り口にあるストレリチア（極楽鳥花）という植物に、大きな新葉がつきました！
葉の色が明るくて、まだまだ柔らかいです。植物も春を感じているのでしょうか？！越冬したブルーベリーにも小さな新葉がついています。
ストレリチアは、極楽鳥花という名の通り、極楽鳥のようなオレンジ色の鮮やかな花をつけるそうです。南国風ですね。花を咲かせてくれることを信じて楽しみに待とうと思います！
こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員が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」が選ばれていることを確認して、「アップロード」をクリックします。
今回は無事にアップロードができました！！
アップロードを行うのに少し時間がかかる場合がありますが、完了のメールも送られてきますよ。
アップロード前後で何が変わるのか詳細画面を見比べてみました。
アップロード前後で変わることとして
が挙げられます。
状況の変化としては、アップロード前が「オープン」アップロード後が「クローズ」に変化します。
また、アップロードするまではコンポーネントの追加及び削除といった編集を行うことができますが、アップロード後はそれらができなくなり、コンポーネントのアクションが「削除」から「ソースを表示」に変わります。
一番の違いは変更セットアップロード履歴の有無です。
アップロード後はどの組織にいつ誰がアップロードを行ったかという情報が追加されます。
リリース接続を行うことで無事にアップロードができました。
後はリリースするだけ…となりましたが、変更セットのアップロードについて掘り下げていたら長くなってしまったので、リリースについては次回に持ち越したいと思います。
また、アップロード関連についてはまだ書き足りないことがあるので近いうちに別で紹介しようと思います。
リリースはあと少しで完了しそうですが、何事もなく進むといいな…
では、またお会いしましょう！！
AWS EC2をコンソールから作成し、管理するサーバが多くなったら、一覧が欲しいですよね。
コンソールでは、分かり難いし、一覧を管理したい。そこで、AWS CLIコマンドを利用すると
EC2のリソース情報を取得し、且つ、必要な情報に絞って出力するように出来ます。
今回はEC2の情報を出力してみます。
Linuxのコンソール画面で以下のコマンドを実行してインストールします
$curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o "awscliv2.zip"
$unzip awscliv2.zip
$sudo ./aws/install
aws --version
aws-cli/2.4.15 Python/3.8.8
最新でなかった場合はバージョンアップしましょう
バージョンアップ方法は以下です
curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install --update
aws --version
aws-cli/2.4.29 Python/3.8.8
2022/03/28時点で最新バージョンです
詳しくは、以下を参照 AWS CLI 最新バージョンをインストールまたは更新する https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html
利用中のリージョンに存在するEC2インスタンスのすべての情報を出力するには以下のように記述します SQLの select * from ec2 みたいなものです
aws ec2 describe-instances
Json形式で どばーっと出力されます
上記コマンドでは沢山の情報が出力されるのでqueryオプションを使用して情報を絞り込みます
Sqlの select name,OS from EC2 みたいなものです。EC2名とOSに絞り込みます
aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value}]" \
--out table
queryオプションの設定は以下のようになります
Json形式で出力されるので、これを踏まえて絞り込む内容を記述します
まず、Reservations[*].Instances[*] (画像C 階層) トップレベルがReservations
一つ下の階層がInstances これがリスト[]になっているので、
すべてを対象にする為に、Reservations[*].Instances[*] と指定します
更に下の階層(画像D PlatformDetails項目)の値と、
同じ階層にある(画像E Name項目)Tags:[0]リストの最初の項目Value値 を指定します
.[{OS:PlatformDetails,Name:Tags[0].Value}]
{key1:value,key2:value}のdict形式にフォーマットして、項目名と値を出力するようにする --out table テーブル形式にすることで見た目が分かり易すくなります
aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]" \
--out table
追加したqueryオプションの設定は以下のようになります [{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]" 下の階層の (画像G Instancetype項目) の値を追加して、出力するようにする。
aws ec2 describe-instances \
--query "Reservations[*].Instances[*].[{OS:PlatformDetails,Name:Tags[0].Value,Type:InstanceType}]" \
--out text
Text形式で出力して、情報を加工し易くすることが可能になります
利用可能なインスタンスタイプ、アーキテクチャ、仮想化、プロセッサー、Hypervisorを
出力しよう。インスタンスタイプの変更可否（互換性）を確認したい場合に重宝します。
aws ec2 describe-instance-types \
--query "InstanceTypes[*].[{InstanceType:InstanceType,Hypervisor:Hypervisor, \
CPU:ProcessorInfo.SupportedArchitectures[0], \
Clock_Ghz:ProcessorInfo.SustainedClockSpeedInGhz}]" \
--out table
query を利用することで、必要な項目を絞ることができました。 jqを利用しても可能ですが、こちらを利用しても、同様のことができそうです。最初は書き方に悩みましたが、pythonのlist[],dict{}を連想すると、分かり易いです。次回はRDSの情報出力についてです。
参考URL AWS CLI の query による絞り込み
https://qiita.com/draco/items/fa09ae0c2f51de9de449
Linux版その２ RDSの情報出力 https://opt-p.co.jp/blog/aws/post-1718/
Linux版その３ VPCの情報出力 https://opt-p.co.jp/blog/aws/post-2080/
Linux版その４ 色々な情報出力 https://opt-p.co.jp/blog/aws/post-2421/
こんにちは！株式会社オプトプランニングです。
2022年3月11日金曜日、協会けんぽ広島支部様主催、令和3年度の健康保険委員の研修会があり、
当社も委員全員が受講しました。
コロナ禍ということもあり、2年ぶりの開催で、オンラインでの講座となりました。
オンライン会議は、どこでも、もうすっかりおなじみですね。
さて内容は、
①実務研修
②運動講座「かんたん美姿勢YOGA教室」
③メンタルヘルス講座「睡眠のチカラ」
の三部構成で全部で2時間の内容でした。
実務研修の中で筆者の印象に残ったことは、広島県の女性の健康寿命が低く、全国の47都道府県の中で44位で、かなり低いということです。
健康寿命を延ばすには、運動、栄養、早めの受診が必須とのことですが、
何かないと受診をしない県民性が反映しているとのこと。
まずは、個人からですが、何か不調があれば早めの受診を心がけようと感じました。
軽い症状のうちに受診したほうが、治療期間も短く、結果、医療費も抑えられることに繋がるとのことです。
運動講座のヨガ教室では、簡単にできる姿勢に挑戦！
思った以上に体が硬い！先生のポーズには驚きの連続でした！
最後に、メンタルヘルスですが、良質な睡眠は摂取する栄養にも関連するとのこと。
栄養、運動、メンタル、すべてが健康維持に重要な要素ですね。
今回受講した内容は社内報に掲載し、情報を共有し、
健康な会社人としての毎日につなげていきたいと思います！
こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。
今回は、リリースをやってみようと思います！！
今回の使用環境は、先日作成した
以上２つのSandbox環境です。
これらを使用して、Sandbox to Sandbox のリリースを行います。
Salesforceでリリースを行うにはいくつか方法がありますが、今回は変更セットを使用したリリースを行います。
イメージとしてはこんな感じです。
内容は、１つの権限セットをリリースするものとなっており、プロファイルは含めません。
変更セットには「送信変更セット」と「受信変更セット」の２種類があります。
「送信変更セット」に開発した内容を詰め込んで、リリース組織にアップロードすると、リリース組織上には「受信変更セット」として変更セットがアップロードされます。
少しややこしいですが、送信側と受信側で「変更セット」の名称が変わるのだな、と覚えておけばいいと思います。
早速変更セットを作成していきます。
TSandbox（開発環境）にログインし、設定の検索ボックスに「変更セット」と入力し、「送信変更セット」をクリックします。
下図のような「リソースの理解」という画面になった場合は下にスクロールして「次へ」をクリックします。
送信変更セットの画面が表示されました。
新規作成したいので「新規」をクリックします。
「新規変更セット」が立ち上がるので、ここに変更セットの名前と説明を入力していきます。
（図は2022年2月から必須になった多要素認証（MFA）に関する権限セットをリリースした時のもので、名前や説明欄にはその時の内容を入力しています。）
全て入力ができたら「保存」をクリックします。
次は、変更セットにコンポーネントや関係するプロファイルを追加していきます。
名前と説明の保存後、作成した変更セットの詳細画面が表示されるので、「変更セットコンポーネント」にある「追加」をクリックします。
コンポーネント選択画面に移動するので、追加したいコンポーネントの種類を選択します。
今回は権限セットを追加したいので、「コンポーネントの種類」の横にあるボックスをクリックして表示されるリストから「権限セット」を選びます。
コンポーネントの種類を選択すると、選択した種類のコンポーネント一覧が表示されます。
先ほど権限セットを選択したので、権限セットのコンポーネント一覧が表示されています。
一覧からリリースしたいコンポーネント名の左にあるボックスにチェックを付けて「変更セットに追加」をクリックします。
これで選択したコンポーネントは追加され、変更セットの詳細画面に戻ります。
ここで戻らない場合（たまに詳細画面に戻らない時がありました）は、左のリストにある「送信変更セット」をクリックしてみて下さい。
変更セットの詳細画面では、無事にコンポーネントが追加されていることが確認できます。
今回のコンポーネントはこの一つだけで関係するプロファイルも無いので、これで変更セットの作成は完了です！！
無事に変更セットが作成できたところで、私なりのコンポーネント追加時に注意したい点をいくつか挙げていこうと思います。
まず、コンポーネントは複数選択することができますが、一覧が複数ページで構成されていると、別ページに遷移した時点で選択していたコンポーネントは全て選択が解除されます。
コンポーネント一覧が１つのページ内に収まっていれば気にしなくていいです。
しかし、複数ページにまたがっている時は、ページごとに「変更セットに追加」を行う必要があることに注意して下さい。
また、チェックを付けた後にコンポーネントの種類を変更した場合も同様ですので、変更セットの追加はチェックを付けたページごとに行うよう心掛けた方がいいと思います。
もしも間違ったコンポーネントを追加した場合は、アクションにある「削除」でコンポーネントを削除することができますよ。
少し脱線してしまいましたが、変更セット詳細画面にある「アップロード」をクリックしてアップロードをやってみます。
アップロードをクリックした後、このような画面が出てしまいました。
「アップロード」ボタンはグレーアウトしており、
この組織は、他の組織に変更セットをアップロードする権限がありません。承認については、変更をアップロードする組織のリリース接続管理者にお問い合わせください。
というエラーが表示されています。
そうです、リリースは変更セットを作成するだけではできないのです…！
送信変更セットを作成することはできましたが、それだけではリリースのためのアップロードができないということがわかりました。
このままではリリースができないため、次回はリリースのための準備を行います…！
（勘のいい方はタイトルで気づかれたかもしれませんね）
それでは、またお会いしましょう！！
こんにちは！株式会社オプトプランニングです。
突然ですが、皆さんは「認知症サポーター」をご存知でしょうか？
先日、当社はこの養成講座を受講しました。
取り組んでいる健康経営の一環として、またシニア採用戦略における予備知識として、
「健康で働ける時間を長く維持したい」、「若年性認知症について正しい認識を持ちたい」という経緯での受講となりました。
コロナ禍ということもあり、オンライン開催となりましたが、当社には大型画面があります。おかげで大変快適な環境で受講することができましたよ。
はじめに、実際の現場でホームヘルパーとして働かれている講師の方から「認知症とは？」というお話から始まり、「認知症」と「物忘れ」の違いや具体的な症状、そして、認知症の人への対応方法について教えていただきました。
認知症の人への対応で大事なことは、『３つの”ない”』ということでした。
①驚かせない
②急がせない
③自尊心を傷つけない
これは認知症の人だけでなく、子供やお年寄りの方へ接する時にも大変効果的なことだそうです。
普段から心掛けたいですね。
後半は、広島市幟町地域包括支援センターの職員の方から、広島市の認知症ガイドブックをもとにお話を伺いました。
実際、家族が認知症になったらどこに相談していいのか、どのような支援があるのか、など具体的なお話を伺うことができ、いざという時に大変役立つものだと感じました。
高齢化社会の中で、長く健康で、生き生きと働くために、自身の努力はもちろんですが、周りのサポートがあればさらにすばらしいですね。社内にとどまらず、家庭や地域の中でも助け合い、重要なことだと思います。
この度は、正しい知識を専門家の皆様から学ぶことができました。
お互いを思いやる気持ち、社内から広げていきたいです！
こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。
今回はSalesforce本番組織の開発者コンソールは何ができるのかやってみたいと思います。
開発者コンソールとは、Salesforceが提供する一連のツールを備えた総合開発環境です。
Webベースの開発環境なのでインストールなどの事前準備が不要で、Salesforce組織のアプリケーションの作成やデバッグ、テストなど様々な事が行えます。
そんな開発者コンソールですが、基本的には開発環境であるSandbox上で使用していると思います。
ですが、本番組織でも開発者コンソールを開くことができます。
本番組織とSandboxでできる事の違いがあるのか、違いがあればどんなところかを実際にやってみたいと思います。
本番組織とSandboxで開発者コンソールの開き方に違いはありません。
「⚙」アイコンをクリックすると表示されるポップアップ内にある「開発者コンソール」をクリックすると開発者コンソールは開きます。
ここで「開発者コンソール」が表示されない場合は必要な権限設定が行われていないからかもしれません。
必要権限としては、システム権限の内
の二つです。
この２つが有効になっていないユーザで操作している場合、開発者コンソールの表示はされないので注意してください。
早速、本番組織で開発者コンソールを開いてみましたが、Sandboxで開いた時と違いはありませんでした。
Salesforceにログインした時、Sandboxだと画面上部にSandbox名が表示されますが、そういったものもありません。
違いがなさ過ぎて、同時に開くとどっちがどっちかわからなくなってしまいそうです。
開発者コンソールは別ブラウザで開くので、別組織のものは同時に開かない方がよさそうですね。
開発者コンソールを無事に開けたので、次は本番組織内にあるApexのファイルを開いて編集してみようと思います。
この時、システム権限として
が有効になっているユーザで操作しています。
そもそもApexのファイルを開けるかですが、こちらは問題なく開けました。
編集もできるか試してみます。
赤枠部分をコメントアウトしてみました。
赤枠部分のコメントアウトをすることができました。
次に、編集した内容をSaveしてみますが…
このようなエラーが出てしまいました…
Deployment Failed
Can’t alter metadata in an active org
何度か「Save」を試してみたところ、最初は「Save」をクリックした後エラーが出ていましたが、「Save」をクリックする前から表示されるようになってしまいました。
本番組織ではApexの編集を保存することはできません。
Apexクラスを変更したい時、Salesforce上だけで完結させるためには、Sandbox環境で編集を行い、本番環境に向けて変更セットをアップロード＆リリースするしかなさそうです。
ちょっとした変更も例外なく変更セットを使用しなければならない点は要注意です。
Apexの保存はできませんでしたが、開発者コンソールを開けるということは何かできるはず…
ということで、次はクエリエディタでSOQLクエリの実行を試してみます。
取引先のIDとNameを検索してみましたが、問題なく実行することができました！
本番組織上のデータの検索を行うことはできそうです。
今回は本番環境の開発者コンソールでApexの編集とクエリエディタの使用をやってみました。
開発者コンソールは基本的にSandboxで使用するものという位置づけのようなので、本番環境からの使用はあまり期待しないほうがよさそうです。
他の機能についても、今後やってみたで検証できればと思います。
では、またお会いしましょう！！
こんにちは！株式会社オプトプランニングです。
Salesforceでいろいろやってみた中での「ちょっとした気づき」を書いていこうと思います。
Salesforceの削除は、基本的に物理削除ではなく論理削除です。
このことについては多くの先輩方が詳しく説明して下さっているので私からの説明は割愛させていただきます。
論理削除ということで、レコード・カスタム項目・カスタムオブジェクトについて削除した後のデータについて気づいたことを書いていこうと思います。
また、普段Lightning Experienceを利用している場合の内容です。
レコードの削除後、削除したレコードはどこにいくか知っていますか？？
削除したレコードは一定期間「ごみ箱」にいます。
間違って削除した！！という時は「ごみ箱」を見てみましょう。
ごみ箱はアプリケーションランチャー内にあります。
左上にあるカラフルな９つの「・」をクリックすると表示されるポップアップの一番下にある「すべて表示」をクリックします。
アプリケーションランチャーが開くので、「すべての項目」を見てみましょう。
「ごみ箱」を見つけることができました。
削除したレコードはすべてこの「ごみ箱」の中に一定期間保管されています。
間違って削除したレコードはここから復元することができますし、完全に削除することもできます。
カスタム項目の削除後、削除したカスタム項目はどこに行くか知っていますか？？
削除したカスタム項目は一定期間「削除済みの項目」にいます。
間違って削除した！！という時は「削除済みの項目」を見てみましょう。
削除済みの項目は各オブジェクトの「項目とリレーション」の右上にあります。
削除したカスタム項目は、カスタム項目を作成したオブジェクト詳細の「削除済みの項目」からでしか見ることができないことに注意してください。
レコードとは違い、削除後一か所に集約されているわけではありません。
間違って削除したカスタム項目はここから復元することができますし、完全に削除することもできます。
カスタムオブジェクトの削除後、削除したカスタムオブジェクトはどこに行くか知っていますか？？
削除したカスタムオブジェクトは一定期間「削除済みオブジェクトリスト」にいます。
間違って削除した！！という時は「削除済みオブジェクトリスト」を見てみましょう。
この「削除済みオブジェクトリスト」ですが、レコードやカスタム項目と違いLightning Experienceでは表示することができません。
ではどうすれば表示できるかというと…
Salesforce Classicだと表示できます！！！
まず、Salesforce Classicに切り替えましょう。
切り替えはプロファイルを参照すると表示される「オプション」内にある「Salesforce Classicに切り替え」をクリックするとできます。
Salesforce Classicに切り替えるとホーム画面が表示されます。
画面上部にある「設定」をクリックすると、
次のような設定画面に変わります。
この画面を下にスクロールしていくと左の赤枠部分に「ビルド」が出てくるので、その中の「作成」内に「オブジェクト」があるのでクリックします。
カスタムオブジェクトの一覧が表示され、最下部に「削除済みオブジェクト」というのが確認できます。
この「削除済みオブジェクト」ですが、削除したカスタムオブジェクトがない場合、表示されません。
こちらが探していた「削除済みオブジェクトリスト」です。
やっと見つかりました…！
削除したカスタムオブジェクトはすべてこの「削除済みオブジェクトリスト」の中に一定期間保管されています。
間違って削除したカスタムオブジェクトはここから復元することができますし、完全に削除することもできます。
カスタム項目やカスタムオブジェクトを削除する前、注意事項がかかれたポップアップが出現すると思います。
以下はカスタム項目を削除する前に表示されるものです。
15日を過ぎると、自動的に項目とそのすべてのデータが完全に削除されます。
とありますが…
15日経過後も残っていました～
2021年12月1日に削除した項目が、2022年2月7日の時点で残っていることが確認できます。
約二か月経過していますね！
「15日を過ぎると」とありますが、「15日後」ではないのです。
もちろん、15日経過後はいつまでデータが残っているかはわかりませんので、あくまで「こんな事例もあったよ」という参考までに。
もし、15日以上経過後に削除したものを復元したい場合は念のため削除後の各データ保存場所を確認してみたほうがいいかもしれません。
また、15日以上経過していても完全削除されているとは限らない、という点は留意しておいたほうがいいと思います。
念のため復元できるか試したところ、復元できました！！
今回きっかけとなったのは、削除したものの復元のためではなく、削除したものの完全削除のためでした。
データが残っている状態だと作業が進まず、完全削除を行おうにも「削除済みオブジェクトリスト」がみつからなかったのです。
私がSalesforceに携わった時には既にLightning Experienceが存在したので、Classicはあまりなじみがないのも原因ですぐに見つけることができませんでした。
プロファイルの設定を行っても一部権限が付与されている場合はSalesforce Classicに切り替えるスイッチャを非表示にできません。
今まで何故だろう？と思っていましたが、まだLightning Experienceで使用できない機能があるからなのだと身をもって体験でき、いい勉強になりました。
カスタムオブジェクトやカスタム項目の作成は近いうちに「やってみた」で書いていこうと思います。
それではまた会いましょう！！
こんにちは！株式会社オプトプランニングです。
他業種から転職し、右も左もわからない新人社員がSalesforceを使ってあれこれしてみる様子を書いていこうと思います。
前回はSalesforceの開発環境であるSandboxを作成しました。今回も引き続きSandboxを作成していきます！！
はい。冒頭から混乱しそうなタイトルですみません。
SalesforceのSandboxは本番組織から作成するだけでなく開発環境であるSandboxを元にして作成することもできます。
Sandboxのコピーを作成できるということは、開発やカスタマイズを行ったSandboxを元にテストや検証専用のSandboxをそれぞれ作ることができる、ということです。
開発・テスト・検証などの環境を個別に用意できるので、それぞれ並行しての作業もできそうです。
これから作成する機会も多そうなので、今回は前回作成したSandboxを元にSandboxを作成したいと思います！！
ログイン中の「TSandbox」の設定で 前回の設定から「Sandbox」へを行ったところ、設定の「Sandbox」が表示されませんでした。
Sandboxの作成は本番組織からしかできないようです。
Sandboxを作成する際は、現在ログイン中の環境がどこかを意識しないといけないですね。
本番組織にログインし直して、再度Sandboxの作成に挑戦です。
先ほどと同じように「設定」から「Sandbox」へ移動し「新規Sandbox」をクリックします。
「Sandboxの作成」画面で、作成元をクリックするとすべてのSandbox名が表示されるので、作成元にしたいSandbox名を選択します。
今回は先ほど作成した「TSandbox」を選択します。
作成元にSandboxを選択すると、「Sandboxライセンス」が１つだけに変わります。
今回はDeveloperで作成したSandboxを作成元に選択したため、Developerだけが選択できるように変わりました。
SandboxからSandboxを作成する場合は、元となるSandboxライセンスと同じライセンス種別でしか作成できないようです。
作成元のライセンスとSandboxライセンスの残数によっては作成できないことがあるかもしれません。
「新規Sandbox」をクリックする前に「選択可能なSandboxライセンス」の残数も確認した方がいいですね。
「次へ」をクリックしてからは本番組織からSandboxを作成した時と変わりはなく、同様の手順を踏むことでSandboxのSandboxも無事に作成することができました。
しかし、今回のSandbox作成では「待機中」から「完了」まで30分程度時間がかかりました。
作成元のデータ量やライセンスの種類は前回と同じはずですが、それ以外にも作成時間に影響するものがあるのかもしれません。
いずれにせよ、「作成」ボタンを押したあとは気長に待つのが一番です～
「T2Sandbox」が出来上がるまでの間に、気になっていた「ある」部分を確認してみました。
「TSandbox」の左端にある「コピー」の部分です。
この部分をクリックするとSandboxのコピーができそうだなぁと思っていましたが、どうなるのか気になっていたのでやってみました。
クリックすると、「Sandboxの作成」画面に変わりました。
「新規Sandbox」ボタンを押した後との違いは「作成元」の部分です。
作成元はすでに「TSandbox」が選ばれており、Sandboxライセンスも1つのみになっていました。
Sandbox情報を入れればあとはこれまでと同じやり方でSandboxを作ることができそうです。
作成元にするSandboxが決まっている場合は「コピー」から作成してもいいかもしれません。
どちらからでも作成できることができるので、好きな方法で作成すればよさそうです。
前回と今回で作成した2つのSandboxをよく見てみると、「T2Sandbox」の右端には「コピー元」の情報として「TSandbox」と書かれていることが確認できます。
「TSandbox」は空白でした。
このことから、何を元に作成したSandboxかわからない時はコピー元を見るとよさそうです。
・「コピー元」が空白 ＝ 本番組織を元に作成されたSandbox
・「コピー元」がサンドボックス名 ＝ 記載のSandbox名を元に作成されたSandbox
前回に引き続いて今回もSandboxの作成でしたが、微妙な違いがあったりで新たな発見がありました。
次回はこれらのSandboxを使用していろいろやってみた様子をお伝えできたらと思いますが、もしかしたら全く違う内容になるかも…？（予定は未定）
では、またお会いしましょう！！