SFDC：Community Cloud開発向け - Apex TriggerとConnect APIで試行錯誤した話

Community Cloudで顧客とChatterでやりとりする際に相手の投稿が通知されない問題に遭遇することがあると思います。例えば自分のユーザプロファイルに直接投稿してもらったり、メンションを指定してくれれば通知メールは届きますが、B2Cの顧客にそんなことをお願いするのは難しいと思います。

そこでApexトリガで対応するのはどうかと下記のトリガ処理をつくってみました。(サンプル処理なので本番向けではありません。)

trigger FeedItemTrigger on FeedItem (after insert) {

    private FeedItemTriggerHandler handler = new FeedItemTriggerHandler();

    if (Trigger.isAfter) {
        if (Trigger.isInsert) {
            // コミュニティユーザがサポートフィードに投稿したことを担当者に通知
            handler.notificationCustomerChatterPost(Trigger.new);
        }
    }
}

public with sharing class FeedItemTriggerHandler {

    /**
     * コンストラクタ
     */
    public FeedItemTriggerHandler() {
        
    }

    /**
     * コミュニティユーザがサポートフィードに投稿したことを担当者に通知
     */
    public void notificationCustomerChatterPost(List<FeedItem> feedItems) {
        // サポートフィードへの投稿を通知対象として取得
        List<FeedItem> targetFeedItems = new List<FeedItem>();
        for (FeedItem f : feedItems) {
            // オブジェクト判定
            if (String.isNotEmpty(f.ParentId) && f.ParentId.getSObjectType().getDescribe().getName() == 'Support__c') {
                targetFeedItems.add(f);
            }
        }
        // Chatterに投稿
        for (FeedItem f : targetFeedItems) {
            // new connect api
            ConnectApi.MentionSegmentInput mentionSegmentInput = new ConnectApi.MentionSegmentInput();    
            ConnectApi.FeedItemInput feedItemInput = new ConnectApi.FeedItemInput();
            ConnectApi.MessageBodyInput messageBodyInput = new ConnectApi.MessageBodyInput();
            ConnectApi.TextSegmentInput textSegmentInput = new ConnectApi.TextSegmentInput();
            ConnectApi.FeedElementCapabilitiesInput feedElementCapabilitiesInput = new ConnectApi.FeedElementCapabilitiesInput();
            // new List
            messageBodyInput.messageSegments = new List<ConnectApi.MessageSegmentInput>();
            // Post Message
            String post = '【システム通知】新しいメッセージが投稿されました。';
            // textSegment set
            textSegmentInput.text = post;
            messageBodyInput.messageSegments.add(textSegmentInput);
            
            // feedItem set
            feedItemInput.body = messageBodyInput;
            feedItemInput.feedElementType = ConnectApi.FeedElementType.FeedItem;

            // Use a group ID for the subject ID.
            feedItemInput.subjectId = '<TARGET_USER_ID>';

            // capabilities
            feedElementCapabilitiesInput.link = new ConnectApi.LinkCapabilityInput();
            feedElementCapabilitiesInput.link.url = 'https://<YOUR_DOMAIN>.salesforce.com/' + f.parentId;
            feedElementCapabilitiesInput.link.urlName = 'メッセージリンク';
            feedItemInput.capabilities = feedElementCapabilitiesInput;

            // Mention a group.
            mentionSegmentInput.id = 'TARGET_USER_ID';
            messageBodyInput.messageSegments.add(mentionSegmentInput);

            // Chatter Post
            ConnectApi.FeedElement feedElement = ConnectApi.ChatterFeeds.postFeedElement(Network.getNetworkId(), feedItemInput);
        }
    }
}

顧客がコミュニティから投稿すると・・・

Apexトリガの処理が実行され、所有者ユーザのプロファイルにメンション付きで通知投稿が行われます。それにより次のようなメール通知が届きます。

Salesforceにログインしてメール内のリンクをクリックすると対象の投稿ページに移動できます。

これで顧客の投稿時に通知メールを送信できるのではと考えました。

やってみてわかったこと

1. FeedItemトリガだけではコメント投稿時に処理が実行されない。

FeedItemオブジェクトはChatterの投稿用オブジェクトなのでコメント投稿時には実行されません。コメント投稿時には標準の通知機能が働くので大きな問題ではないですが、正しくやるにはコメントオブジェクトにもトリガを用意した方が安全かもしれません。

2. 社内用Chatterページにはコミュニティ側の投稿は表示されない

コミュニティ内で社内ユーザにメンション付きで投稿しても社内ユーザのプロファイルページには表示されませんでした。ここも大きな問題にはならないと思いますが地味に落とし穴です。

3. 社内のChatterグループはコミュニティ側ではアクセスできない。

例えばコミュニティユーザの連絡通知投稿をひとつにまとめるためにChatterグループを用意しても、コミュニティ側ではアクセスできません。コミュニティ側でChatterグループを作成すればアクセスは可能ですが、コミュニティに移動しないと見れませんし本来の用途としてはあまり意味のないものになってしまいました。

4. Community Login UserライセンスでもConnect APIは利用可能

そもそもライセンス的に実装可能なのか不安だったのですが、これは問題ありませんでした。APIの利用を許可の設定はプロファイルで指定できます。Community Login Userライセンスが問題なければ他のライセンスでもほぼ問題ないはずです。ただしConnect APIには利用時の制約があるので注意して下さい。

Salesforce Developers

5. 通知のための処理にApexトリガは向いていない..と思う

最終的に通知メールを送信するためにApexトリガを使うのは向いていないと思います。投稿時にトリガで通知用の別投稿を行うということがそもそも効率的ではないと思います。投稿機能自体を自作してしまい、投稿時にかならずメンションを付ける処理にした方が、投稿/コメント関係なく通知メールが届きますし、通知メールから直接返信も可能になります。

このトリガをつかった方法で一番の障壁は顧客のプロフィールページにApexトリガから投稿した内容が表示されてしまうことです。

これも致命的な問題では無いと思うのですがあまり綺麗ではないと思います。

こんな感じでいろいろ試行錯誤してみたのですが、ApexトリガでConnectAPIをつかって通知するのはイマイチな方法だと感じました。投稿機能が自作する方が綺麗なシステムになると思います。

Connect API (Chatter in Apex) のサンプル (Spring'16バージョン)

少し前のバージョン用ですがまだ利用できると思います。

Demo Video1

Demo Video2

Demo Video3

SFDC：LightningMessageのインストールを試してみました - Part 2

Part 1の続きです。

前回失敗してみてnamespaceの部分は管理パッケージの名前プレフィックスを付けるべきだったんじゃないかと気づきました。(当時Lightning Componentを開発するには名前プレフィックスが必須でした...)

ということでgit clone→build.propertiesファイル作成→パッケージ用名前プレフィックスを指定と対応します。

準備ができたらデプロイコマンドを実行します。

$ ant -Dpackage.xml=package.xml -f build.xml deploy

今回はあっさり成功しました。

開発者コンソールからソースコードを確認できます。

私のドメインの有効化は必須です。未対応の場合はエラーとなります。

アプリにアクセスするとエラーメッセージが表示されました。

ですがインストール手順は正しくできていると思いますので、ソースコードを現在の仕様に合わせて修正するだけで使えるようになるんじゃないかと思います。やり方がわかればすごくシンプルなインストール手順でした。

SFDC：LightningMessageのインストールを試してみました - Part 1

Lightning Experienceへの移行をする際にChatterメッセージが使えなくなるのが地味に障壁となっていました。Lightning ComponentでつくってあるChatterメッセージアプリがあれば解決するんだけどなと考えていたらそういうアプリを作ってくれている人が居たのを思い出しました。

README.mdにインストール方法も記載されています。

インストール手順

まずはgit cloneコマンドでソースコード一式をダウンロードします。

build-sample.propertiesをコピーしてbuild.propertiesを作成します。

DE組織あたりでパッケージを作成します。(たぶん。。)

lm.namespaceに作成したパッケージ名を入力。ユーザ名とパスワードにDE組織のログイン情報を入力します。

デプロイはantを利用します。Force.com移行ツールの出番です。

build.xmlは用意されています。後はコマンドを実行するだけです。

ant -Dpackage.xml=package.xml -f build.xml deploy

こんな感じ。

よくみるとエラーとなっていました。

Error: No COMPONENT named markup://LightningMessage:LightningMessageCmp found : [markup://c:LightningMessage]

やり方がよくなかったみたいです。ソースコードは取得できているので今回はgulp-jsforce-deployを使う方法で対応します。

git cloneしてソースコード一式取得した後にpkgフォルダにLightning Messageアプリのコードを格納します。

Set upに記載されているコマンドを実行して準備します。

デプロイコマンドはこんな感じ。

$ SF_USERNAME=username@example.com SF_PASSWORD=yourpassword gulp deploy

次のようなエラーがでたらnpm installでインストールすれば解決します。

Error: Cannot find module 'through2'

あとは次のエラーがでるかもしれません。

メインマークアップは空にできません。Lightning 定義バンドルを削除する場合は、代わりにバンドルを直接削除してください。

ソースコードで __namespace__と記述されている箇所があるのでc:とか除外とかすれば解決します。(antのときのエラーはこれが原因かな)

これでデプロイを実施できました。

試しにアプリケーションを開いてみると

どこか設定不足かもしれませんがエラーが。Lightning Componentの仕様は頻繁に変更されているのでそれが原因かもしれません。

antとかよくわからないまま試してみたのでどこか手順ミスがあったかもしれません。またエラーメッセージもちゃんと調べれば解決するかもしれないです。今回はそこまでやる予定はないのでここまで。Force.com移行ツールやgulp-jsforce-deployの使い方を久しぶりに思い出せて良かったです。

追記

antをつかったインストールの正しい手順を確認できたので追記しました。

SFDC：Salesforceの災害対策について

Salesforceは日本用のインスタンスでAP0が用意されています。災害発生などで長期間利用できない状態になった時にどのように対応されるかについてサクセスコミュニティで紹介されていました。災害対策用の専用AP0インスタンスが別に用意されていてリアルタイムで同期を取っているそうです。

Success Community

こういった情報の詳細は下記にまとめられているとのことでした。

Security

保護

SFDC：Spring'17 - 新しい一括処理ジョブページ

Spring'17 へのアップデートで新しい一括処理ジョブページが利用できるようになりました。

Apex 一括処理ジョブの状況監視

設定のApexジョブのページに行くとリンクが追加されています。

こちらが新しいジョブページです。

特定の一括処理クラスで [詳細情報] をクリックすると、次の情報を含む一括処理クラスの親ジョブが表示されるそうです。

• 状況
• 実行日と完了日
• 各一括処理の経過時間
• 一括処理された数
• 一括処理に失敗した数

実行時に表示された内容です。

詳細リンクをクリックしたときの内容はこんな感じでした。

新しいジョブページはClassicとExperienceの両方で利用可能とのことです。

SFDC：Spring'17 - ApexテストのモックフレームワークStub APIを試してみました

Spring'17で正式リリースされたStub APIを試してみました。Apexテストで例外テストができる仕組みを用意できたりするみたいです。

Apex スタブ API を正式リリース

リリースノートだけではイマイチ使い方がわかりませんでしたが、Apex開発者ガイドでサンプルコードが紹介されていました。

Build a Mocking Framework with the Stub API

使い方概要

まずテスト対象のクラスとして下記処理を用意します。

public class DateFormatter {    
    // Method to test    
    public String getFormattedDate(DateHelper helper) {
        return 'Today\'s date is ' + helper.getTodaysDate();
    }
}

次のヘルパークラスに処理部分をもたせます。

public class DateHelper {   
    // Method to stub    
    public String getTodaysDate() {
        return Date.today().format();
    }
}

上記処理は以下のような書き方で呼び出すことができます。

DateFormatter df = new DateFormatter();
DateHelper dh = new DateHelper();
String dateStr = df.getFormattedDate(dh);

このように独立させた処理をスタブAPIをつかって効率よくテストできるみたいです。

試験のために、私たちは隔離したいです getFormattedDate（）この方法は、フォーマットが正常に動作していることを確認します。の戻り値getTodaysDate()この方法は、通常、日によって異なります。ただし、この場合には、我々は、フォーマットに私達のテストを分離するために一定の、予測可能な値を返すようにしたいです。むしろこの方法が一定の値を返すクラスの「偽」のバージョンを書くよりも、私たちは、クラスのスタブバージョンを作成します。スタブオブジェクトは、実行時に動的に作成され、私たちはその方法の「スタブ」動作を指定することができます。

Apexクラスのスタブバージョンを使用するには：

• 実装することで、スタブクラスの動作を定義します System.StubProvider インタフェース。
• 使用してスタブオブジェクトをインスタンス化します System.Test.createStub（） 方法。
• テストクラス内からスタブオブジェクトの関連するメソッドを呼び出します。

StubProviderインターフェイスの実装します。implements System.StubProvider と宣言したテストクラスになります。

@isTest
public class MockProvider implements System.StubProvider {
    
    public Object handleMethodCall(Object stubbedObject, String stubbedMethodName, 
        Type returnType, List<Type> listOfParamTypes, List<String> listOfParamNames, 
        List<Object> listOfArgs) {
        
        // The following debug statements show an example of logging 
        // the invocation of a mocked method.
       
        // You can use the method name and return type to determine which method was called.
        System.debug('Name of stubbed method: ' + stubbedMethodName);
        System.debug('Return type of stubbed method: ' + returnType.getName());
        
        // You can also use the parameter names and types to determine which method 
        // was called.
        for (integer i =0; i < listOfParamNames.size(); i++) {
            System.debug('parameter name: ' + listOfParamNames.get(i));
            System.debug('  parameter type: ' + listOfParamTypes.get(i).getName());
        }
        
        // This shows the actual parameter values passed into the stubbed method at runtime.
        System.debug('number of parameters passed into the mocked call: ' + 
            listOfArgs.size());
        System.debug('parameter(s) sent into the mocked call: ' + listOfArgs);
        
        // This is a very simple mock provider that returns a hard-coded value 
        // based on the return type of the invoked.
        if (returnType.getName() == 'String')
            return '8/8/2016';
        else 
            return null;
    }
}

クラスのスタブバージョンをインスタンス化します。

public class MockUtil {
    private MockUtil(){}

    public static MockProvider getInstance() {
        return new MockProvider();
    }
    
     public static Object createMock(Type typeToMock) {
        // Invoke the stub API and pass it our mock provider to create a 
        // mock class of typeToMock.
        return Test.createStub(typeToMock, MockUtil.getInstance());
    }
}

これでテストクラスからスタブAPIを利用する準備ができました。次のようなテストの書き方ができます。

@isTest 
public class DateFormatterTest {   
    @isTest 
    public static void testGetFormattedDate() {
        // Create a mock version of the DateHelper class.
        DateHelper mockDH = (DateHelper)MockUtil.createMock(DateHelper.class);
        DateFormatter df = new DateFormatter();
        
        // Use the mocked object in the test.
        System.assertEquals('Today\'s date is 8/8/2016', df.getFormattedDate(mockDH));
    }
}

無事開発者ガイドのサンプルコードのテストを実行することができました。

開発者ガイドのサンプルでは任意のシステム日付をセットしてテスト実行できることを確認できます。DateHelperクラスの処理でDate.todayでシステム日付を取得しています。MockProviderクラスの30行目でテストデータ用に任意の値で疑似システム日付を準備していました。DateFormatterTestクラスの12行目でスタブAPIをつかって用意した疑似システム日付がただしく利用できていることをassert処理で確認しています。

StubProviderインターフェイスの実装は少しややこしそうですが、疑似システム日付を用意できるのはすごく便利そうです。また、疑似Exceptionなども実装することができればテストがやりやすくなると思います。

SFDC：Lightning Design SystemのProgress Indicatorを試してみました

Lightning Design SystemのProgress Indicatorを試してみました。普段画像などを用意して実装するプログレスバーをCSSとSVGで表現することができます。

バージョン2.1では正しく動作しなかったので現時点で最新の2.2.1で試してみました。

実装時の注意点

Lightning Design SystemのサイトにあるサンプルコードをVisualforceページで動かすと一つ目のマーカーの左側にスペースができてしまいます。

これはCSSでマージンを変更することで解決します。

ol li {
    margin-left: 0;
}

※実際には他のCSSに干渉しないようにクラスやID指定を組み合わせます。

Progress Indicatorで各マーカーの下にラベルを表示したいときがあると思います。その場合はslds-is-relativeをつかって対応可能です。

モバイルレイアウトでも対応してくれる便利なCSSコンポーネントでした。

デモ動画

サンプルコード