ゲオログ by リバネスCIO 吉田丈治 @geeorgey

plogで有料記事を作ってみよう

吉田丈治 — Fri, 30 Oct 2020 08:01:01 +0000

各種ブログプラットフォームに投げ銭機能がついている物があると思うのですが、それを任意のHTML上で実現してしまおうというサービスです。

https://qiita.com/yoshinori_hisakawa/items/1359c8f541cc6b7252e4

こちらに詳細書いてあります。サービスページはこちら

https://plog.bubbleapps.io/

ものは試しということで試してみましょう。

設定画面

シンプルですね。値段を決めて、文字を入れ込みます。次へボタンを押すとこんな感じで埋め込み用のiframeが現れます。

で、実際に埋め込んだのが以下の部分。

どうでしょう、簡単ですね。表示が新聞メディア系サイトっぽくなります。

現在はプレーンテキストのみの対応なので、テキストを読ませるサイトでしか使いみちがなさそうですが、コードブロックや画像なんかが貼り付けられるようになると使い勝手が良さそうですね。

Apex,Visualforce 動的にカスタム項目を取得する

吉田丈治 — Thu, 18 Jul 2019 02:51:17 +0000

いつも忘れてしまうので書いとく。

参考：sobjectを利用したカスタムオブジェクト項目取得サンプル

やりたいこと

Visualforceページ等では、URLパラメータに連動して、様々なデータの取得を行うことが多いのですが、その際に動的に取得したいデータを変えたいことがあります。それもこれも、過去のデータ構造のせいではあるのですがそこは致し方ないので、それを乗り越えるための実装を考えることになる。(ちなみにその過去の遺産を作ったのも自分であり、十字架を背負って生きている)

例えば、弊社のある項目では、特定期間の売上金額を

2019_01__c
2019_02__c

みたいなカスタム項目にまとめており、これをURLが

/apex/myVisualforcePage?yearmonth=2019_01

の時に取得するようなことを検討することになる。

まずはオブジェクトリストを取得する

ここはそんなに難しくない。

	public String getAllFieldNames(String sobjName){
		String strFieldKeys='';
		Schema.SObjectType sobjType = Schema.getGlobalDescribe().get(sobjName);
		Map fmap = sobjType.getDescribe().fields.getMap();
		for (String fieldKey : fmap.keySet()) {
			Schema.SObjectField f = fmap.get(fieldKey);
			if(strFieldKeys == ''){
				strFieldKeys = fieldKey;
			}else{
				strFieldKeys +=  ',' + fieldKey;
			}
		}
		return strFieldKeys;
	}

こんな感じの関数を用意して、

String soql = 'SELECT ' + getAllFieldNames('Opportunity') + 'FROM Opportunity WHERE 条件';
LIST opps = new LIST();
opps = Database.query(soql);

としてやれば取得できる。

この中に以下のような項目があったとして、URLで取得したいのだ。
2019_01__c
2019_02__c

参考：sobjectを利用したカスタムオブジェクト項目取得サンプル

これをするには、オブジェクトを指定したリストでは不可能ぽい。なので

LIST opps = new LIST();
としたところを
LISTopps = new LIST();

としてsObject型でリストを作成する。

こうすると、明示的に型を指定して、項目を取得する必要があるので、2019_01__cを取得する場合は

Integer Int_201901;
for(sObject op : opps){
 Int_201901= (Integer)op.get('2019_01__c');
}

という形で取り出せる。

2019_01__cの部分はテキストなので、URLパラメータを取得したものを適当な変数にいれて持ち込んでも良い。

Salesforceのフローでは大文字小文字が正確に判定される

吉田丈治 — Wed, 03 Jul 2019 07:23:12 +0000

Apexでは、英字の大文字小文字は無視されるという仕様になっているので、全体的にそういうものだと勝手に思っていたのですが、実は違います。

Salesforceのプロセスビルダーとフローを使って、データの有無を判定する仕組みを作っていたのですが、メールアドレスの合致判定でコケました。

例えば、メールアドレスがtest@geeorgey.com というリードがあったとして、TEST@geeorgey.com というメールで、レコードを検索するとひっかからないのです。jsで判定してるんでしょうか。

これがわかってから、メールアドレスを含む項目をオブジェクトに含める場合は、必ず小文字化するような数式項目を作り、そこを参照するように変えました。

数式項目を作り、 LOWER(Email) とするだけです。

Salesforceで多対多のコネクションを張るには

吉田丈治 — Wed, 20 Mar 2019 04:42:46 +0000

なんで俺は今までこれを知らなかったのかと後悔したやり方なので、Salesforceの管理者を担う人はぜひ覚えておいてほしい。

通常Salesforceでは、あるオブジェクトにぶら下げた子オブジェクトを配置するということをよくやる。例示すると、例えば毎週週報を書くとすると

Userオブジェクト：自分のレコード
┗週報オブジェクト

という形で、週報オブジェクト側から主従関係で自分のレコードに紐付けるみたいな形にします。これは簡単、よくやる。

多対多のコネクションとは

上述のやり方だと、作るレコードから見て主となるレコードは一つのみである。Salesforceでは、主レコードを複数持つような構造は許されていない。そのために、こういう構造は作れないのだ。

例えば、イベントのチケットを取得する事を考えよう。チケットAは50枚上限だとする。Userオブジェクトにこれまでに取得したチケットをぶら下げたい。一方で、チケットAを取得した人のリストをチケットオブジェクト側にぶら下げたい。みたいなものだ。

Userオブジェクト：ユーザーA
　┣チケットA
　┣チケットB
　┗チケットC
Userオブジェクト：ユーザーB
　┣チケットA
　┗チケットC

チケットオブジェクト：チケットA
　┣ユーザーA
　┗ユーザーB
チケットオブジェクト：チケットB
　┗ユーザーA
チケットオブジェクト：チケットC
　┣ユーザーA
　┗ユーザーB

チケットオブジェクト側で主従関係を設定してユーザと紐づけてしまうとこういう設定はできない。で、どうするかというとこうなる。

多対多リレーションの作成

参考：https://help.salesforce.com/articleView?id=relationships_manytomany.htm&language=ja&r=https%3A%2F%2Fwww.google.com%2F&type=5

要は、多対多リレーションを作成したいオブジェクトの中間に、ダミーのオブジェクトを配置せよという事だ。

ユーザー←接続用オブジェクト→チケット

という形で主従関係で双方をつなぐのである。

運用としては、まずチケットオブジェクトにチケットA,B,Cを登録する。

次に、ユーザオブジェクトからダミーオブジェクトのレコードを作成し、チケットを選択して保存する。

チケット側には関連リストとしてユーザリストを表示するようにできるし、逆にユーザ側には取得したチケットリストを表示することができるようになる。ついでにいうと、中間オブジェクトにチケットの有効無効といったステータスや、支払い済みフラグみたいなものを設ける事もできる。実体となるような対象は接続先の終端のオブジェクトとして作り、そのステータス情報みたいなものを中間オブジェクト側にもつような形にする。

何だよまじかよこんな形で実現するんかーいと肩を落としたのが僕でしたとさ。めたくそ便利なのでぜひ頭の片隅に入れておいてくれると良いと思います。

リバネスの会員サービスをHeroku,AWS,Salesforce,Einstein Analyticsで構築しました

吉田丈治 — Mon, 04 Mar 2019 01:41:24 +0000

先程Twitter見てたらテラスカイさんのリリースが流れてきました。

フォトハウスMemorisの会員サイトをマルチクラウドで構築

は！ここで書かれてることと同じことを弊社リバネスも2019/3/1付でリリースしたのです。先を越されてしまった(笑

リバネスの会員サイトリバネスID：https://id.lne.st

構成はほぼ同じです。

リバネスID構築環境

そもそもなぜこんなことしてるのか

リバネスでは、リバネス研究費、TECH PLANTER、サイエンスキャッスル研究費、マリンチャレンジプログラム、超異分野学会、キャリアディスカバリーフォーラムなど、参加型の企画が多数展開しています。これまではそれぞれ別サービスでIDを作ってもらい情報登録をしてもらっていたのですが、流石に煩雑であろうと。加えて、管理側からみると、IDが分散しているので、いま現時点で一番アクティブな人ってだれなんだろう？と思ったら全データ引っ張り出して突き合わせないとできませんでした。動きが遅くなりますし、遅くなるというかそんなこともあり分析がやれていません。もったいないですね。情報がほしいであろう人に適切に届ける体制が作れていないのは由々しき問題であろうということでリバネスIDというサービスによって1人に1つのIDを提供し、その上で様々な活動に参加してもらおうということに決めました。

加えて、これらの会員機能は昨年まではSalesforceのCommunity Cloudを使っていたのですが、ライセンス費用がかなりかさみます。弊社に存在するIDの総数は5万超という感じでしたので、これをCommunityCloud上で構築するとコストが合わないなという感じだったことも構築の理由です。何しろ日常的につかうというよりは、申請テーマが合致した場合にログインして情報を登録するという使い方なので、アクティブな時期に山があるんですよね。

やってみてどうだったか

Heroku connectがかなり良い

Heroku上ではPostgresによってデータベースが構築されており、これを使ってWebサービスを展開しています。Heroku Connectを使うことで、このPostgresの情報をSalesforceの特定のオブジェクトに同期できます。

これを構築するに当たり、Salesforce側のデータ構造も見直し、リバネスIDというオブジェクトに全てが紐づく形へと移行しました。これはなれた人なら大した作業では無いと思います。

今まで成り行きで作っていた項目も見直し、グローバル選択リストを共通で利用するようにして管理工数の削減も同時に実現しています。サービスのリプレースを行うことで内部のデータがスッキリしました。素晴らしい。

開発者の切り分けが可能

私自身はSalesforceの内側の開発を主に担当しています。Heroku ConnectによってデータはSalesforce側に同期する訳ですから、実はHeroku側に管理画面がありません。フロントエンドを担うエンジニアには、フロント側のみの開発に専念してもらうことができました。もちろんSalesforceのオブジェクト側で選択リスト項目を使っている場合はHeroku側でも、同じValueを与えないとエラーになるのでそこだけは合わせる必要がありますが、開発担当領域の切り分けが可能なのは非常に良かったです。

分析はEinstein Analyticsで

会員データの分析ダッシュボードもHeroku上には持っていません。こちらはSalesforceに同期したデータをEinstein AnalyticsというBIツールを使って出力しています。構築作業が一瞬で終わります。これは神機能。

Einstein Analyticsによるデータ出力

帳票出力はVisualforceで

入力されたデータは、研究費の申請データだったり、審査が必要なものが多いので、テーマごとにデータを集約した審査用ファイルを作る必要があります。これはVisualfoce Pageを使って出力。PDFにして閲覧したり、お客様に納品をしたりといったことが可能になっています。基本的には出力のみなのでVisualforceページの開発コストは大したこと無いです。これまでに作ったものを応用して2時間程度といった所でしょうか。こんな感じになっています↓

AWSにアップした画像もこちらから参照して出力するようになっています。

リバネス研究費申請書の出力用ページ

以上です

運用は始まったばかりですので、これからなにか出てくるのかもしれませんが、今の所は満足度の高い構築ができました。これを土台にしてより良いサービスへと進化させたいと思います。

Einstein Analyticsを使って一ヶ月。良い点悪い点。Visualforce,Apexとの比較

吉田丈治 — Wed, 13 Feb 2019 01:32:13 +0000

2019年明けてからEinstein Analyticsを契約しました。

散々自作ダッシュボードをvisualforceで作りまくっていた私ではありますが、公式に提供されているものを使うことでやりたいことの実装速度があがるならそのほうがいいだろうということでお試し2ライセンス。

圧倒的に良い点

Einstein AnalyticsはSalesforceにあるデータ(その他のデータソースも利用可能)を、定期的なスケジュールでEinsitein Analytics側のストレージにコピーしてくるという仕様になっています。これが意味することはなにか。

上述したようにVisualforce上でApexを使ってグラフを書いたりしたいと思うと制限が多いです。例えば、SOQLでデータを取得する時にGROUP BYでグループ化したものを使いたい場合を考えると、GROUP BYは数式項目が使えません。それなので、一度その数式項目をコピーするようなテキスト項目を追加し、データローダー等でデータをコピーする必要があります。それをやると何が起こるかというと、最終更新者と最終更新日時が一括で変更されます。微妙じゃないですか？

Einstein Analyticsは、グラフ化したりテーブル表示したりする場合は、そもそも使うデータがコピーしてきたテキストデータですから、どんな項目でもグループ化できます。これだけでもうめちゃ良いですね。

こんな感じのダッシュボードが慣れれば10分程度で作れます

イマイチな点

リストをテーブル表示する際に表示のリミットが少なすぎる。

100 (異なる値を設定するには、SAQL の limit ステートメントを使用)

https://help.salesforce.com/articleView?id=bi_limits.htm&type=5

おそらく変えられると思うのでここは問題ないかもしれない。

イマイチな点２

毎度のことですが、スタート時のサポートが薄い！！新規契約なんだから契約スタート時に最初にやることは？とかTrailheadの案内とかメールでくれれば良いのにねぇ。ってめっちゃ思ってます。送ってくるサービスもあるんだけどなー、ばらつきがあるよね。

イマイチな点3

ライセンスが高い。グラフやダッシュボードを見るだけライセンスをもう少しお安くしていただくことはできないのか！！ダッシュボードを作るのは正直ちょっと難しさもあるので全員にはいらないよなと思うのですが、SalesCloudの画面に貼り付けてみんなに見せたいっていうときに閲覧ライセンスもそれなりのお値段がする。もう少し下げてほしい！現在は仕方がないので、共有用に画像生成してシェアしてます。それでも良いインサイトを提供できるっちゃできる。

総評

機能的な側面については実はそんなに不満がありませんでした。使いこなせるようになってきて良さが分かるようになってきました。あとはレシピを理解できれば、かなり色々なことが処理できると思う。Einstein Analytics良いぞ。

続 slackからチームスピリットの打刻を行うには -botkit express mongodbでの実装-

吉田丈治 — Tue, 11 Dec 2018 07:01:25 +0000

前回のpostはこちら：https://geeorgey.com/archives/3569

前回までの機能では、Salesforceのセッションが切れた場合、再度OAuth用のリンクを踏んでセッション情報を取得する必要がありました。チームスピリットの打刻は出勤日に使うので、毎朝セッションが切れていると不便で仕方がありません。

そこで、SalesforceAPIにはセッションが切れた場合に、新しくアクセストークンを取得する仕組みがあるので、そちらの実装を行ったのが今回のアップデートです。

Salesforceのセッション情報はmongoDB上に保管され、時間が経ちセッションが切れると、その情報を使って新しいアクセストークンを取得、そちらのデータでmongoDB上のデータを置き換えます。そうすることで、一度Salesforceとの接続処理を行っておけば、再度セッション情報を取得する必要がなくなります。この実装をしないと実用に耐えません。

使い方

設定等については前回の投稿を参照してください。 https://geeorgey.com/archives/3569

mongoDBに sfusers という名前のコレクションを加えてください。その中にデータが保存されます。

GitHub

https://github.com/geeorgey/ts-dakoku-node-express

slackからチームスピリットの打刻を行うには -botkit express mongodbでの実装-

吉田丈治 — Wed, 05 Dec 2018 04:46:10 +0000

# ts-dakoku-node-express

コードはGithub

ベース： Slackforce https://github.com/ccoenraets/slackforce

実現されること

– slackのスラッシュコマンドからチームスピリットの打刻を行うことができる

– スラッシュコマンドを使ったslackアプリの拡張性を考慮してあります。

環境

– node.js

– botkit

– express //webサーバ

– mongodb //slackの認証情報の保存

node.js上で動きます。私の環境ではheroku上で可動しています。

チームスピリットの打刻用Apexについて

ngs/ts-dakoku をそのまま使わせてもらっています(ngsさんに感謝)

https://github.com/ngs/ts-dakoku/tree/master/apex/src/classes

こちらの２つのクラスを本番環境にデプロイして使ってください

– TSTimeTableAPIController.cls

– TSTimeTableAPIControllerTest.cls

設定等についてはこちらを参照：https://ja.ngs.io/2018/02/14/ts-dakoku/

Salesforceで接続アプリケーションを作る

– アプリ名: 任意

– API Name: 任意

– Contact Email: 管理者のEmail

– OAuth 設定: チェックを入れてください

– コールバック URL: https://myapp.herokuapp.com/oauthcallback (これは後でherokuアプリを立ち上げたあとに書き換えます)

Selected OAuth Scopes: Full Access (full)

– 保存する

herokuアプリを作る

heroku CLIをインストール

$ heroku login

// メアドとパス・二段階認証でログイン

$ heroku create appName

//appNameは任意

//ここまでやるとアプリURLが発行されるので先程作ったSalesforceアプリのコールバックURL(https://myapp.herokuapp.com)部分を置き換えてください

ここからはGUI。 https://dashboard.heroku.com にログインして先程作ったアプリの設定画面を開く

Resources画面に行き、add-onにmLab MongoDBを追加

Settings画面に行き、Reveal config varsボタンを押して環境変数を設定します

slackアプリを作る

https://api.slack.com/apps

Create new appする

Basic Informationにある[Client ID][Client Secret][Verification Token]を以下で使います

Interactive Componentsに移動してRequest URLに

先程herokuで作ったアプリのURL/slack/receive を設定する

スラッシュコマンドを作る

slackアプリのスラッシュコマンドページへ行き、Create New Commandを押す

コマンド名： /ts

Request URL: herokuアプリのURL/ts

Short Description: チームスピリット打刻コマンド

herokuの環境変数

– MONGODB_URI herokuのadd onで mLab MongoDB :: Mongodb をインストールすると自動的に入ります

– SF_CLIENT_ID //先程Salesforceで作ったアプリのID

– SF_CLIENT_SECRET //先程Salesforceで作ったアプリのsecret

– SF_LOGIN_URL //自分のSalesforceのURL。https://[任意の文字列].my.salesforce.com

– SF_USER_NAME //管理者のメアド

– SF_PASSWORD //管理者のパス

– SLACK_ID // Slackアプリの[Client ID]

– SLACK_REDIRECT // herokuで作成したアプリのURL

– SLACK_SECRET // Slackアプリの[Client Secret]

– VERIFICATION_TOKEN // slackアプリの[Verification Token]

以下についてはslackforceで設定されているものなのですが、VERIFICATION_TOKENと同じものです。追加するのが面倒な場合は、modules/**.js内部の変数名をVERIFICATION_TOKENに変更してしまうことで一つですみます

– SLACK_WHOAMI_TOKEN

– SLACK_ACCOUNT_TOKEN

– SLACK_CASE_TOKEN

– SLACK_CONTACT_TOKEN

– SLACK_OPPORTUNITY_TOKEN

使い方

https://任意のアプリ名.herokuapp.com/oauthcallback

こちらにアクセスして、アプリを組織にインストールします。

インストール後は、slackで /ts と打つとslashコマンドが起動します

最初はSalesforceへのログイン認証が必要なので、表示されるURLをクリックしてログイン情報を登録します

(注意：こちらのデータもmongodbに入れるべきなのですが未実装です)

ログインしたら再度 /ts と打つと、出勤/退勤/キャンセルボタンが表示されますのでボタンを押して打刻してください

ボタンを押した時間が出退勤時間となります。

ボタンを押すと打刻完了状態へ

打刻が完了済みの場合や、休暇申請がされている場合はその旨表示されます

botkitについて

botkit.jsでbotkitの基本的な機能の実装が可能です

interactive_message_callbackについてはここで受けることが出来ません。

エンドポイントは、 modules/receive.js で作成してあるのでそちらで定義してください

server.jsについて

スラッシュコマンドを追加する場合はserver.jsに定義し、 mobules/ にファイルを設置しています。

debugについて

設定が完了している場合、作ったbotに向けてDMで hello と入れると、コメントが返ってくるはずです。

herokuアプリについて

無料プランで使うとdynoがスリープしてしまうので、そのあたりのケアもしましょう。ぐぐると出てくると思います。

[salesforce]承認プロセス終了のタイミングでプロセスは呼び出せないのでトリガーを使うという話

吉田丈治 — Wed, 21 Nov 2018 03:09:50 +0000

Salesforceの主要機能である商談管理。弊社リバネスではこれに経費データをぶら下げて、商談から稟議承認プロセスを回していました。

四年前であれば、それでもまぁ行けたのですが、ここ数年、事業のスピードが早くなってきたこともあり、承認申請プロセスの最中だと商談がロックされて手が出せないこともあり、関連するデータの更新が滞るという事が度々起こりました。

対策

対策はシンプルに、承認プロセスは対象オブジェクトに対して行うという形にしようというものです。

今までこれをやらなかった理由は、商談ページ上で完結できなかったためです。つまり、経費オブジェクト上で承認プロセスを回したいなら経費オブジェクトを開いた上でやらなくてはなりません。Salesforce経験が浅いタイミングでこれをやるのは混乱の下だと判断しました。

今回、この実装に踏み切ろうと考えたのは、承認申請ボタンをVisualforce等を介して商談ページ上に表示ができるからです。今回はそこには触れませんが、一応そのような形で実装しています。

実装方法１：だめだったパターン

経費オブジェクトには経費明細オブジェクトが主従関係でぶら下がっていまして、その中に経費の細かい情報が入ります。

例えば、出張経費という経費オブジェクトを作り、その中に経費明細オブジェクトとして、「飛行機代」「電車代」「宿泊費」「その他経費」…という形で、経費明細を作っていきます。

経費上で稟議の承認プロセスを回し、承認されたら項目自動更新で経費オブジェクトに作成した承認フラグ(チェックボックス型)をTrueにします。

プロセスビルダーから経費オブジェクトに対してプロセスを作成し、承認フラグが更新された＝Trueと承認フラグがTrueという条件でプロセスを開始します。

プロセスからはフローを呼び出し、経費オブジェクトIDにぶら下がっている経費明細オブジェクトの承認フラグをTRUEに変更する、という処理です。

何がだめだったか

承認フローの完了タイミングで発生する項目自動更新からはプロセスが起動しないようです。

参考：項目自動更新アクションの考慮事項
「承認時のアクションとして実行される項目自動更新は、ワークフロールールやエンタイトルメントプロセスをトリガしません。」

ということで諦めました。

成功パターン：トリガー書く

ちょっと面倒ですが、トリガー書きましょう。

after updateで、経費IDから経費明細引っ張ってきて、承認フラグをTrueに変えてupdateかければ良いだけです。シンプル。。。

ということで、仕様が分からずにちょっとハマったよという報告です。

共有・意識喚起のslackと、実行催促のsalesforce chatterという使い分け

吉田丈治 — Mon, 12 Nov 2018 05:59:36 +0000

前回こんな事を書きました

Lightning Component開発でいろんなオブジェクトを作って設置してみたらSalesforceの便利度が激増したという話

Qiitaには実際のコード付きでこんなことも書きました
Lightning componentでteamspiritの勤怠打刻を行う

今回は、Lightning Componentを作っていて、slackとchatterの使い分けがわかりやすくなってきたなと感じたのでそのまとめです。

これまでの使い方

これをSalesforceの方に言うと、あんまりいい顔されないのですが(そりゃそうだとはおもう）社内チャットツールはslackを使っていて、chatterは使ってなかったんですね。

slackはやはりその強力なインテグレーション機能が便利で、slack上では日常的なスタッフのやり取りのみではなく、バッチ処理の結果を流したり、
休暇を取っているスタッフにslackでmentionしたときに教えてくれるbotを作った

こんな事をやったりと、便利に使っていた訳です。

一方でchatterには、直接的な商談上のやり取り等の、その対象レコードについてのやり取りが成されているという感じです。

日常的に使うのはslackで、異常値などについての指摘が入るのがchatterというイメージ。それゆえに、Salesforce自体は必要な時にしか使わず、なんとなくの情報収集からがっつりとした指示出しみたいなものまで、基本的にはslackが使われています。アプリケーションの使用頻度が全く違うと思う。

これからの使い方として気づいた点

ヒントは社員からのニーズだったのですが、先のリンクに書いたように、チームスピリットの打刻機能を実装したのですが、そもそもとして打刻忘れを通知してほしいというのです。

人間ですから、忘れることは当然ありますので、なるほどなるほどと、実装をしようかなと考えていたのですが

slackでも通知だけならできます。打刻してない人のリストを作って、slackに通知すればよいのですから。

だが、一点課題になるのは、アクションを促すには一歩遠いなと。

例えば、slackに勤怠打刻用のLightning ComponentのURLを投げたとして、そのURLをクリックするとブラウザが開きます。ログインしてなければ、ログインする必要が出てきてしまう。ここで離脱する人は多そうですよね。自分も離脱するとおもう。

そこで、アクションを促すならchatterで通知したほうが良いだろうと思い至った訳です。

chatterで通知してあげれば、アラートがモバイル端末にも上がります。リンクをクリックすれば該当のLightning Componentが表示され、アクションがしやすい。

共有・意識喚起のslackと、実行催促のsalesforce chatterという使い分け

というわけで、そこになにかのデータがありますよという通知や、チームメンバー内での共有にはslackが強く、実際に該当者に向けてアクションを促しアクションにつなげたいと強く願う場合はchatterへの通知を使うのが良いのかなというものでした。

より強い実行に向けて何をすべきか

チームスピリットの打刻の部分で参考にしたプログラムでは、slack上からボタンを押すことでSalesforce内のデータをアップデートしています。

一定のトリガーが引かれたら、何をすべきかがslack上で通知され、ボタンを押すやら、何かを入力してEnterを押すことで情報のupdateができてしまう。

そこまでできれば、chatter使わなくてもslack上で完結してしまうんですけどね。まだ技術力不足で完成しておりません。

Lightning Component開発でいろんなオブジェクトを作って設置してみたらSalesforceの便利度が激増したという話

吉田丈治 — Wed, 24 Oct 2018 10:09:32 +0000

Salesforceユーザの皆様こんばんは。巷ではLightning Experience、略してLEXの利用が推奨されて久しいですが皆さんの環境はいかがでしょうか。

弊社リバネスでは、Salescloud Einstein導入時にLEXへ移行してみたのですが、如何せん使いづらいこともあって行ったり来たりしていました。

しかし、LEXが圧倒的に便利だなと言う感覚が分かってきたので共有したいと思います。

恐らく肝はLightning Component

Lightning Componentっていうのは、機能が詰まったモジュールという感じで、いろんな場所に配置することが出来ます。

最初はこれ、何に使うんだよと思っていたのですが、使い所がやっとこ分かってきました。

トップページへの配置

リバネスのSalesforceトップ画面はこんな感じ

左上にあるニュースなんかはSalesforceのデフォルトのコンポーネントです。

オレンジ部分が、作ったコンポーネント。こんな感じでトップページにモジュールをホイホイ足して行くことが出来ます。

凝った開発なんぞしなくてもレポートで作ったグラフを表示させることも出来ますし、ビューを適切に作っておいてそれを表示させるなんてことも出来ます。

ぱっとひと目見た時に入ってくる情報がコントロール出来るのが良いのではないでしょうか

モバイルアプリの活用方法が見えてきた

Lightning ComponentはLightningアプリビルダーを使って配置すればモバイルアプリに簡単に設定が可能です。

モバイルアプリにも同じコンポーネントを配置する

そう、再利用が簡単ですね。

そうはいってもLightning Componentを開発したい

先程、別に凝った開発をしなくてもレポートやビューのリストを表示することは出来ますとは書いたのですが、それだとやっぱり少し足りない。

例えば、リバネスでは情報の蓄積を大事にしています(報告・連絡・相談）ではなく、情報は蓄積・開示を主眼において、必要な人が情報を取りに行くようにしています。

これまではGoogleカレンダーからSalesforceに同期した予定(Eventオブジェクトに同期)に、営業報告を編集保存するとSlackに流れるというフローになっていて、そこは変わらないのですが、Lightning Componentで営業報告が必要なEventのリストを出すようにしてみたところ、ワンタップでアクセスが可能になります。

当然、全部終わってる人には営業報告が必要なデータリストは表示したくありませんので、なくなればその領域は消去します。

ビューのリストをコンポーネントとして表示する場合は、消す事が出来ません。イマイチな感じがします。

データが無ければこうしたい。データがあったらこうしたいという諸条件は色々なレコードについて回るでしょう。それをちょっとした開発で組み込む事が出来ます。

現在までの実装状況

先程も書きましたが営業報告用のEventリスト

これで営業報告の蓄積率が上がると良いなと期待しています

自分が持っている商談リスト

レポートで持ってたりもするのですが、こちらも開発してみました。

商談がなければ「提案に行こうぜ」と促したり

商談初期・商談確度高・契約済み請求前・請求済み、みたいな感じのパイプライン設定がしてあるので、それぞれの商談をどの程度持っているのかを見せる事もできます。

バランスが悪ければアラートを出すようにも当然できます(そこまでやってませんが)

事業計画の達成度・毎週の進捗グラフ

これもアプリ開いて一発で把握できれば良いですよね。

コンポーネント内で自分の所属部門を割り出し、そこに関する情報を表示するように設定しています。

個人にフィーチャーしたダッシュボード

Lightning Componentを使うことで、全員が同じ情報を見るのではなく、各個人が必要なものを選んで設置ができるようになります。

コンポーネントも色々なものを用意しておいて、自分でページ設定変えてくれっていうことも可能でしょう。

一応組織のデフォルト設定というものは展開しますが、それ以上のことも出来るようになるはずです。

コンポーネント内で、個々人のロールによって見せるデータを変化させることも可能です。

今後は、そんな感じで個々人が必要なものが手元に届くようになっていくのかなと感じましたというお話でした。

Dreamforce18に行ってきました #DF18

吉田丈治 — Wed, 03 Oct 2018 02:41:18 +0000

昨年の記録はこちら

【dreamforce初参加】2017行ってきました #DF17

9月末のサンフランシスコの気候はどうなんだ？

2018年は、昨年の自分の記録を見て服装を選んだつもりが結構寒かったです。
長袖シャツ＆薄手のジャケットという格好だと少し冷えるかなという感じでした。
日向と日陰の寒暖差が凄いので寒がりな人は気をつけましょう。夜は羽織るものがあったほうが良いですね。

どうやって参加したか

昨年はパスだけオンライン登録して、フライトと宿は別でとったのですが、これがかなり厳しかったので今年はJTBのツアーに申し込んでしまいました。(自分で取ってる暇もないし）

ホテルはPARC 55と、会場から徒歩5分程度の場所で非常に良かったです。近場にいると、夜の予定が入っていても歩いていけますし、ゆっくり眠れてセッションへも身が入るし良いですね。dreamforce期間中はホテルが高騰しますので、自分で予約する場合はお早めに。

今年失敗したこと：シューズの選択

昨年よりも会場が広くなっていた気がします。ウォーキングシューズとはいえ革靴で行ってしまったのですが、足が疲れますね。
割とセッションからセッションへと渡り歩いていく感じなのですが、今歩いた距離見てみたら

Day1：11.6km
Day2：16.2km(追加の5kmはdreamfesの会場に行ったからですね)
Day3：11km
Day4：11.1km(dreamforceタワーツアーに参加してました)

という感じで10km超えが続きました。ガッツリ会場内を散策する人は履物に気をつけましょう。

反省点：Day1の夜はブッキングしまくり

行く前は、Googleカレンダー上で予定を入れていっていたのですが、タイムゾーンを変更してきちんと処理をし始めたのが遅すぎてブッキングしまくりました。

Japan Night
Heroku Night
開発者パーティー

参加表明したものでも３つもあり、結局開発者パーティー行けなかったのが悔やまれます。行きたかった…

ということで、初日の夜はいろんな場所でパーティーが開催されていると思いますので、参加しましょう。

パーティーの見つけ方は、担当営業の方に聞くか、TwitterでdreamforceとかDF18とかで検索すると出てきますのでチェックです。情報は自分で取りに行きましょう。これだけの規模だとパーフェクトなサポートは期待できませんので(笑

最終的にはHeroku Nightの前半だけ顔だしてJapan Night会場へ駆け込みました。Japan Night短めだったのでその後Heroku Nightに戻ろうかとも思ったのですが、時差ボケで眠く…て寝てしまいましたね。

モバイルの言語を英語にしておきましょう

SalesforceのEventアプリですが、言語設定がアプリ内にありません。端末の設定を英語にしておきましょう。
画面を見せながら、これどこだ？とか、予約のステータス見せろって言われた時にパッと見せて理解してもらうとか、そういうことがままありますので。

サンフランシスコの通信環境をどうするか問題

筆者はiPhone XのSIMロック無し端末を使っているので、事前に日本で現地で使えるSIMを購入して持っていってます。業務でイモトのWi-Fi使ったこともあるのですが、別端末でWi-Fi接続するのも面倒ですし、可能であればSIM買って持っていくのを推奨。Wi-Fi端末が電源切れるとか面倒ですし。

今年は昨年とは違うSIMを試してみました。昨年の記録はこちら

サンフランシスコ訪問時にZip SIMを使ったときのまとめ

今年使ったのはMOST SIM

最大7日間通信し放題っていうプラン。昨年のZip SIMは通信量制限があって、途中で一度追加しているのですが、それが面倒だったので使い放題を選択。

インフラはT-mobileを使っている模様。電波が入っている所では困りませんでした。(ホテルの電波が弱くてイマイチだなーとは思いましたが)

国内でアクティベーションして出発しましょう

MOST SIMが届いたら封を開け、アクティベーションを行います。出発の12時間前にはやったほうが良いと思います。というかもっと前のほうが良いです。

アクティベーション時に、利用開始日と何日間使うかを聞かれますので、設定します。設定すると電話番号がメールで届くという形。

実は、フライト当日の朝にやったので、国内にいるうちにこのメールが届くかヒヤヒヤしました。前日にはやろうね！

加えて、アメリカにいるのが５日間ということで、５日間使うって設定してしまったのですが、ここはフルの７日間に設定しましょう。今回帰国日にちょうど台風がぶちあたっていたため、あそこで帰れなかったら僕は電波難民になっていました。

使い方

飛行機が飛び立ったら、国内のSIMを抜き、MOST SIMに差し替えるだけ。
アメリカに着陸したら電源を入れて通信が出来るか確認してみてください。なんと簡単な！！

今年もソロ参加

昨年に続きソロ参加が続いていますが身軽で良いですよ。セールスフォースの方々も割とソロで転々としているみたいです。お客様にべったりアテンドされている人ももちろんいますが。

Twitter見てたらTrailblaizerな皆さんがslack立ち上げてるのを見かけたのでそちらに参加もしてみました。皆さんグッズ集めまくってて凄い！

夜はパーティーに参加したり、担当営業さんを誘って飲みに行ったり、ユーザー会等で知人になった方々とご一緒したりで、寂しく過ごすこともありませんでした。知り合いが沢山いると良さそうですね。

肝心のdreamforce18の中身はどうだったのか

MulesoftとCustomer360が中心でしたね。

Salesforceも、コミュニティクラウドやらマーケティングクラウドやらコマースクラウドやらと、いろんなプラットフォームを立ち上げているのですが、そこに入ってくるターゲットはいずれも人間です。(IoTは端末ですが)

一人の人間がいろんなインフラを使っているのを一元管理し、今までどんなことをやってきたのかを視覚化(それこそカスタマージャーニーそのものですね)しちゃいましょうというものでした。

話を聞いていて、え？出来てなかったの！？って思ったのですが(笑)、Salesforceは買収してプラットフォーム拡張してるので、仕方のない部分ですね。

とはいえ、dreamforce前日にこんなニュースがあがってきたのを見ていたのですが、みんなそこに困ってるのだということが明らかになったなと感じています。

アドビ、マイクロソフト、SAPがデータの統合分析で提携

Salesforceは自分たちの持つツール内でしっかり連携出来る仕組みを確立しました。この発表は3社横断ということも有り、結構難しいよねそれは…という肌感です。

弊社でも実はこの問題は認識していて、結局この人って何を利用してもらったっけ？っていうのは、全部一元管理出来てないんですよね。リバネスではherokuつかってつなぎこむ方針で決めたのですが、その方針は間違ってないよなと確信しました。

その他に気になったのは昨年に引き続きIoT(実用化に耐えうる仕様にアプデされてる模様)とhealth cloud(ユーザに関わるウェアラブルデバイスのデータを一元管理してました)ですね。Mulesoftに実装されているコネクタの種類の多さも凄かったなぁ(競合の皆さん大変だ)。
QuipにSlideが実装されてましたが、これはもう少しアップデートが必要という感じですね。頑張ってほしい！

昨年発表されていたmyTrailheadは2019初旬にリリースみたいです。はよはよはよはよ！これは期待。

そんなわけで、DF18でも未来を見せてもらいました。どんどん実装していくぜー！と気合十分でございます。

技術やさんにもおすすめ

MosconeWestのTrailblazer広場にはDeveloperForestっていう技術やさん向けセッション＆ブースがあります。色んな小ネタだったり、このライブラリ使うと面白いこと出来るよ！みたいな話だったり、インテグレーションの効率化とかまぁマニアックなものがたくさんあります。

事前にセッション情報集めるのは数が多いので大変なのですが、気になるキーワードで検索してセッションにスターつけとくだけで、体験は変わると思いますよ。

mini hackがライトニングに移行してた

去年はそうでもなかったような気がするのですが…

今年はmini hackの内容がライトニングコンポーネントのが多かったですね。本格的に脳内を移行しないとツラいチャレンジが多かった気がします。僕は一つだけクリアしておきました。

カスタマーサクセスを実現するというのはどういうことか

Salesforceを使い始めると「カスタマーサクセス」というキーワードが耳に入ってきます。門外漢な僕からしたらなにそれ！？という感じだったのですが、カスタマーサクセスとはツールの定着化みたいな部分だけではないというのが面白かったですね。

success cloudを扱っているブースでは、効果的なプレゼンテーションに必要なことはなにか？を教える＆実際に作って見るワークショップなんかもやっていたり。

ビジネスそのものを伸ばすツールの提供という部分にも踏み込んでいる点は、さすがの巨大イベントだなと。

マインドフルネスなんかも好きみたいなので、坊さんとお話できる場所なんかも確保されていたりして面白い感覚だなって思いました。

dreamforce18の写真

こちらにまとめてありますのでよろしければ御覧ください

実は、DAY4に新しいSalesforceタワーツアーにも行かせていただきました。素晴らしい就業環境だったなぁ。目指すべきものがありました。

市内を散策してみましょう

余談です。

サンフランシスコ市内には、FordのgoBikeというレンタル自転車サービスがいたるところに配置されています。これ使うと、散策しやすくなるので良いですよ！

注意点は、サドルの高さに気をつけましょうということですね(笑

時間あるしチャリ乗ろう！と思い立って走ってきたのですが、山の中腹で体力の限界を感じております、、、 pic.twitter.com/g5hnA0w1Ls

— 吉田丈治リバネスCIO (@geeorgey) 2018年9月29日

電動アシストチャリもあったんかーいの顔してる（激疲 pic.twitter.com/cJIgElAqNd

— 吉田丈治リバネスCIO (@geeorgey) 2018年9月29日

KUSANAGIのphp7へのエクステンションの追加方法

吉田丈治 — Wed, 12 Sep 2018 06:55:38 +0000

KUSANAGIを使ってからそれなりに経つのですが、わからないことが多くて試行錯誤の日々です。

今回は、php-soapを入れたかったのですがよくわからず。というか、KUSANAGIの理解してないっぷりが露呈する結果となりました。

KUSANAGIでは、php-fpm環境とphp7-fpm環境が選べるのですが、今何を使っているのかを調べるには

$ kusanagi status

と打てばわかります。

[code]# kusanagi status
Profile: *******
FQDN: *******
Type: WordPress
KUSANAGI Version 8.4.0-3
sakura

*** (active) nginx ***
● nginx.service – The NGINX HTTP and reverse proxy server
Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
Active: active (running) since 水 2018-09-12 15:38:40 JST; 12min ago

*** (active) php7-fpm ***
● php7-fpm.service – The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php7-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since 水 2018-09-12 15:38:40 JST; 12min ago

*** (active) MariaDB ***
● mysql.service – LSB: start and stop MariaDB
Loaded: loaded (/etc/rc.d/init.d/mysql; bad; vendor preset: disabled)
Active: active (exited) since 水 2017-11-01 09:59:17 JST; 10 months 10 days ago

*** ruby ***
KUSANAGI Ruby is not installed yet

*** add-on ***

*** Cache Status ***
bcache off
fcache off

*** WAF ***
off
[/code]

php7を使ってるとこんな感じになります。

PHP環境の変更は

$ kusanagi php7
とやるとphp-fpm(PHP7)へ

$ kusanagi php-fpm
とやるとphp-fpm(PHP5.6)へ変更されます

インストール済み拡張モジュールの確認方法
PHP7の場合は
$ php7 -m
php-fpmの場合は
$ php-fpm -m

でリストが表示されます。

KUSANAGI自体のアップデートは

$ yum update

現在インストールされているパッケージのリストを取得するには

$ rpm -qa | grep php

現在使ってるPHPのバージョンを調べたいなと思ったときに

$ php -v

とやりがちなのですが、これだとちゃんとわかりません。ｐｈｐ７の場合は

$ php7 -v

とする必要があります。

では、そのphp7にエクステンションの追加を行うにはどうしたらよいのでしょう。

$ yum install ****

では駄目でした。

参考にしたのはこちら
KUSANAGIのPHP7.2環境にphp-intlをインストール

php-soapをインストールする場合はこちらのコマンドで行けました
$ yum –enablerepo=remi,remi-php7.2 install php72-php-soap

php-fpm(PHP5.6)環境へのインストールの場合は
$ yum –enablerepo=remi,remi-php56 install php-soap

VisualforceでExcelで開けるファイル(複数シート)を作成してダウンロードする方法

吉田丈治 — Fri, 25 May 2018 05:19:20 +0000

指示書を作成する際などにExcelで共有しないといけないというシチュエーションはそれなりにあると思います。

Salesforceには構造化されているデータが有るが、例えばリードと取引先担当者に散っていて、一つのレポートでは出力出来なかったり、一つのレポートでデータリストは出力できるものの、それを適宜フィルタ処理をして別々のシートにリストを記載したり、はたまたそのデータリストを集計するテーブルを別シートに設けたり。

処理が複雑になればなるほどミスが発生しやすくなるので、直接Excelファイルを出力したいと思うことはあるのではないでしょうか。

こんな方法があるとは知らずに手作業していたのですが、感動しました。おすすめです。

OPEN XML形式でファイルを出力すればExcelで読み込むことが出来る

参照：VisualforceでCSVファイルとExcelファイルを出力するには

Visualforce page

[code]

xmlns:o="urn:schemas-microsoft-com:office:office"
xmlns:x="urn:schemas-microsoft-com:office:excel"
xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet"
xmlns:html="http://www.w3.org/TR/REC-html40">

7個のセルを結合する
テキストの場合はtypeをStringに
数字の場合はtypeをNumberに

[/code]
Workbook > Worksheet > Table > Row > Cell
という階層構造になってます。

apex

[code]
public with sharing class 使用するコントローラー名 {
public String getXmlVer() {
return ‘’ + ‘\r\n’;
}

public String getXmlApp() {
return ‘’ + ‘\r\n’;
}
}
[/code]

ファイルのダウンロード

ファイルのダウンロードは
https://yourNameSpace.lightning.force.com/apex/yourVisualforcePageName
にアクセスすれば、xmlファイルがダウンロードされるので、それをExcelで開けばOKです。

Excelでファイルが開けない場合

恐らくシンタックスエラーが出てると思いますので、xmlファイルをテキストエディタ等で開いて、適切な形に直しましょう。

Google Chartsを使って層別散布図を書くには

吉田丈治 — Mon, 12 Mar 2018 14:38:13 +0000

散布図を書こうと思う。

データはグループ化されており、それぞれを色分けした散布図が書きたい。でもよくわからずにハマったので書く。

サンプルはここにあるんです

よくある散布図ですね。

これを青一色じゃなくて、グループごとに分けたいときあるじゃないですか。ないですか。あると思います

結論から言うとこういう散布図

これを例に取ると、年次別のデータにグループ化しておいて、それを表示しましょうというもの。

しかし、サンプルには書いてないんですね。なんだよそれって。

書き方

[code]

function drawGradeM() {
var button = document.getElementById(‘change-chart’);
var chartDiv = document.getElementById(‘chart_div’);

var dataGradeM = new google.visualization.DataTable();
dataGradeM.addColumn(‘number’, ‘横軸数値’);
dataGradeM.addColumn(‘number’, ‘1年次’);
dataGradeM.addColumn(‘number’, ‘2年次’);
dataGradeM.addColumn(‘number’, ‘3年次’);
dataGradeM.addColumn(‘number’, ‘4年次’);
dataGradeM.addColumn(‘number’, ‘5年次’);
dataGradeM.addColumn(‘number’, ‘6年次’);
dataGradeM.addColumn(‘number’, ‘7年次’);
dataGradeM.addColumn(‘number’, ‘8年次’);
dataGradeM.addColumn(‘number’, ‘9年次’);
dataGradeM.addColumn(‘number’, ’10年次’);
dataGradeM.addColumn(‘number’, ’11年次’);
dataGradeM.addColumn(‘number’, ’12年次’);
dataGradeM.addColumn(‘number’, ’13年次’);
dataGradeM.addColumn(‘number’, ’14年次’);

dataGradeM.addRows([
ここにデータセットを記入する*後述
]);

var dataGradeMOptions = {
title: ‘グラフのタイトル’,
hAxis: {title: ‘横軸名’},
vAxis: {title: ‘縦軸名’}
};

var chart = new google.visualization.ScatterChart(document.getElementById(‘chart_div’));
chart.draw(dataGradeM, dataGradeMOptions);

}

[/code]

こんな感じで書きます。サンプルとそれほど変わらないと思う。

HTMLには

[code]

[/code]

みたいな感じでid指定しておけば、そこに表示されます。

肝心なデータセットの書き方どうするのか

散布図をレイヤーごとに分けて表示するには、データセットの書き方はこんな感じになります

つまり、

縦軸データ,1年次,2年次,3年次・・・・

というデータセットにする。

最大年次を6年として、1年次に5ポイント取っていて、横軸が3の場合は

[3,5,0,0,0,0,0]

2年次に10ポイント取っていて、横軸が21の場合は

[21,0,10,0,0,0,0]

という感じです。グループ別にカラムが一つ増えるイメージですね。

CSVで書くと

横軸データ,1年次ポイント,2年次ポイント,3年次ポイント,4年次ポイント,5年次ポイント,6年次ポイント

という形式でカラムを増やしていく必要があります。

結論

書けてしまえば簡単ですね(白目