Quantcast
Channel: tyoshikawa1106のブログ
Viewing all 1438 articles
Browse latest View live

SFDC:gulp-jsforce-deployを使って静的リソースをデプロイする方法

$
0
0

gulp-jsforce-deployを使って静的リソースをデプロイする方法についてです。何も考えず静的リソースでJSやCSSを管理しようとすると開発時に『静的リソースからファイルをダウンロード』→『Zipファイルを解凍』→『JSやCSSに処理を追加』→『Zipに変換』→『静的リソースにアップロード』・・・と現実的ではない手順で対応する必要がでてくると思います。


gulp-jsforce-deployはコマンドラインからSalesforceへのデプロイ処理を実行できる便利なツールです。これをつかってこの問題を解決できます。


はじめにgulp-jsforce-deployの環境構築の手順についてはこちらです。リンク先の記事ではVisualforceページとApexクラスをデプロイする手順についてまとめてあります。


ページとクラスをデプロイできるところまで準備してそこから検証を進めました。
f:id:tyoshikawa1106:20160703030117p:plain


静的リソースをデプロイするにはpkgフォルダにstaticresourcesフォルダを用意してその中にデプロイ対象のファイルを用意する必要があります。
f:id:tyoshikawa1106:20160703030606p:plain


それではどうやってデプロイすればいいか確認してみます。まず、次のように圧縮していないフォルダを用意してデプロイを実行してみました。
f:id:tyoshikawa1106:20160703030709p:plain


当たり前ですがこれではデプロイできません。エラーにはなりませんでしたがそもそも対象として認識されませんでした。
f:id:tyoshikawa1106:20160703030800p:plain


それではZip形式にした場合はどうでしょうか。
f:id:tyoshikawa1106:20160703030855p:plain


当然これも対象として認識されません。
f:id:tyoshikawa1106:20160703030957p:plain


最後にZipファイルの名前を変更して拡張子を『.resource』にして実行します。
f:id:tyoshikawa1106:20160703031245p:plain


これでようやくデプロイ対象として認識されました。
f:id:tyoshikawa1106:20160703031351p:plain


ですがまだエラーとなっています。

Error on pkg/staticresources/MyStaticResources.resource : 値を入力してください: [ContentType]


理由はXMLファイルが存在していないためです。通常は次のようにXMLファイルが一緒に存在しています。
f:id:tyoshikawa1106:20160703031521p:plain


このようにファイルを用意してあげます。
f:id:tyoshikawa1106:20160703031637p:plain


内容はこちら

<?xml version="1.0" encoding="UTF-8"?>
<StaticResource xmlns="http://soap.sforce.com/2006/04/metadata">
    <cacheControl>Private</cacheControl>
    <contentType>application/zip</contentType>
</StaticResource>


これで再度実行してみると・・・エラーにならずにデプロイできました。
f:id:tyoshikawa1106:20160703031759p:plain


Salesforce組織にログインして静的リソースを確認してみます。無事にファイルが保存されていました。
f:id:tyoshikawa1106:20160703031903p:plain


ファイルをダウンロードしてみました。ZipにまとめたJSファイルとCSSファイルがきちんと格納されていました。
f:id:tyoshikawa1106:20160703032101p:plain


この静的リソースを読み込むように変更してみます。
f:id:tyoshikawa1106:20160703032903p:plain


無事にCSSとJavaScriptが適用されました。
f:id:tyoshikawa1106:20160703032943p:plain


Zipファイルに圧縮するときですが圧縮時のフォルダによってパスが変わるので注意してください。

圧縮例①

f:id:tyoshikawa1106:20160703033106p:plain

<apex:includeScript value="{!URLFOR($Resource.MyStaticResources, 'myjavascript.js')}" />
<apex:stylesheet value="{!URLFOR($Resource.MyStaticResources, 'mycss.css')}" /> 
圧縮例②

f:id:tyoshikawa1106:20160703033218p:plain

<apex:includeScript value="{!URLFOR($Resource.MyStaticResources, 'MyStaticResources/myjavascript.js')}" />
<apex:stylesheet value="{!URLFOR($Resource.MyStaticResources, 'MyStaticResources/mycss.css')}" /> 


という感じです。パスの違いは開発時に影響がでるのでやりやすいパスになるように考慮してZipに変換する必要があります。


これで無事にgulp-jsforce-deployを使って静的リソースをデプロイすることができました。ですが、まだ基本的な使い方を確認できただけです。これだけでは『処理追加』→『圧縮』→『拡張子をresourceに変更』→『デプロイコマンドを実行』と通常の手順のときと同じような負担が必要になってしまいます。


なのでここからをGulpやWebpackなどをつかって自動化を行う必要があります。検索すると参考になる情報がいくつか見つかりました。


イメージ的にlibフォルダを用意、そこでJSやCSSに処理を実装。ビルドコマンドを実行するとstaticresourcesフォルダにコピーを作成→ZIPに変換→ファイル名変更(拡張子の変更)という感じの流れでできたらいいなと思います。
f:id:tyoshikawa1106:20160703040723p:plain


まだここから先は確認できていないので、今回はgulp-jsforce-deployを使って静的リソースをデプロイするときの基本的な手順の確認ということでここまで。きちんと確認できたら別記事にまとめようと思います。

追記

続きの記事書きました。


SFDC:Gulpをつかって静的リソース(.resorceファイル)を用意する方法

$
0
0

gulp-jsforce-deployを使って静的リソースをデプロイする方法の続きの記事です。前回は基本的な使い方を確認しましたが、今回はJSやCSSが入っているフォルダをGulpをつかって.resorceファイルに変換する方法について紹介します。

はじめに

JSやCSSをまとめたフォルダをZipに変換するため、『gulp-zip』をインストールします。

$ npm install --save-dev gulp-zip

※gulp-jsofrce-deployでは最初からインストール済みでした。


Zipファイルを.resorce拡張子に変更するため『gulp-rename』も必要になります。

$ npm install --save-dev gulp-rename


次のgulpfile.jsを用意しました。これでやりたかったことを実現できます。


それでは実際の流れを確認していきます。

処理の流れ

libフォルダにJSやCSSをまとめたフォルダを用意します。(複数処理できるか確認するため、2つのフォルダを用意しました。)
f:id:tyoshikawa1106:20160703063014p:plain


次のgulpコマンドを実行するとlibフォルダの中にあるフォルダが.resourceファイルに変換されてstaticresourcesフォルダに格納されます。

$ gulp setup-staticresources

f:id:tyoshikawa1106:20160703063241p:plain


gulp-jsforce-deployの機能をつかってデプロイを実行します。

$ foreman run gulp deploy

f:id:tyoshikawa1106:20160703063712p:plain


静的リソースに正しくデプロイされていることを確認できました。
f:id:tyoshikawa1106:20160703063834p:plain


Visualforceページで正しく読み込めるかも確認してみました。
f:id:tyoshikawa1106:20160703064033p:plain


問題なさそうです。
f:id:tyoshikawa1106:20160703064059p:plain


無事に、開発したJSやCSSを.resorceファイルに変換して静的リソースにアップロードすることができました。これさえできればAngularJSやReactをつかったVisualforceページの開発がやりやすくなると思います。

補足説明

.resourceファイルに変換するためにgulpfile.jsに追加した処理は次の部分です。

var fs   = require('fs');
var path = require('path');
var rename = require("gulp-rename"); 

// function.getFolders
var getFolders = function (dir) {
  return fs.readdirSync(dir)
           .filter(function (file) {
              return fs.statSync(path.join(dir, file)).isDirectory();
           });
}

// Setup Static Resourecs
gulp.task('setup-staticresources', function() {
  var folders = getFolders('./pkg/lib/');
  folders.map(function (folder) {
    // Setup resource
    gulp.src('./pkg/lib/' + folder + '/*')
      .pipe(zip(folder + '.resource'))
      .pipe(gulp.dest('./pkg/staticresources'));
    // Setup resource-meta.xml 
    gulp.src('./pkg/template/template.resource-meta.xml')
        .pipe(rename(folder + '.resource-meta.xml'))
        .pipe(gulp.dest('./pkg/staticresources/'));
  });
});


getFoldersの処理でlibフォルダ内のフォルダ情報を取得し、folders.mapでフォルダを1つずつ変換しています。


困ったのが.resource-meta.xmlファイルを準備する方法です。悩んだ結果、templateフォルダに雛形ファイルを置き、それをコピーする方法で対応してみました。(ファイル名以外は内容は同じだと思うので...)


もしかするとまだ見落としている問題があるかもしれませんが、ひとまずやりたかったことは実現できたと思います。次はこれを使ったVisualforceページ開発の流れをまとめてみようかなと思います。

SFDC:Salesforce Development 2016 - Part 1

$
0
0

Salesforce Platformでの開発方法について考えてみました。gulp-jsforce-deployというライブラリのおかげでメタデータAPIをつかって静的リソースへのアップロードを簡単に行えるようになっています。これを活用すればAngularJSやReactをつかったVisualforceページ開発がやりやすくなります。その辺りの手順についてです。

はじめに

gulp-jsforce-deployをつかえば、ページ、クラス、静的リソースと開発に必要なファイルを簡単にデプロイすることができます。ですが個人的にMavensMateの便利機能も手放したくないなと思っています。というわけで静的リソース周りの開発はgulp-jsforce-deployを利用してそれ以外はMavensMateを使った開発という流れで考えてみました。

Salesforceプロジェクトを作成

まずはMavensMateをつかってSalesforceプロジェクトを作成します。今回は新しく用意したDev環境をつかっています。
f:id:tyoshikawa1106:20160703140747p:plain

Gitリポジトリの作成

Salesforceプロジェクトを作成したらGitリポジトリで管理できるように設定します。今回の方法で開発を行うにはGitの管理は必ず必要になります。

.gitignoreの作成 ~ .git initまで

まずはGit対象外のファイルを管理するため.gitignoreファイルを用意します。この辺りの操作はターミナルから行うのが簡単だと思います。cdコマンドでSalesforceプロジェクトのディレクトリに移動します。
f:id:tyoshikawa1106:20160703141232p:plain


.gitignoreを作成します。giboコマンドを利用するのが簡単だと思います。後でnpmを利用するのでNodeも追加しておきます。

$ gibo OSX Windows SublimeText Node >> .gitignore

作成後は.gitignoreの編集を行います。下記のファイルが管理対象外になるように指定します。

  • config/ ←新規追加
  • *.sublime-project ← コメントアウトの解除
  • *.sublime-workspace ← そのままでOK

これで.gitignoreの準備ができました。
f:id:tyoshikawa1106:20160703142141p:plain


git initコマンドを実行して.gitファイルを作成します。

$ git init

f:id:tyoshikawa1106:20160703142310p:plain

リモートブランチにリポジトリを作成

GitHub or Bitbucket , Public or Privateという感じで選択肢がありますが、今回はGitHubにPublicリポジトリを作って開発を進めます。通常はPrivateリポジトリでの開発になると思います。
f:id:tyoshikawa1106:20160703142742p:plain


リポジトリを作成後は、git initまで終わっているので次のコマンドを実行します。

$ git add .
$ git status
$ git commit -m "first commit"
$ git remote add origin git@github.com:tyoshikawa1106/salesforce-development-2016.git
$ git push -u origin master

これでリモートブランチにリポジトリを作成するところまでできました。
f:id:tyoshikawa1106:20160703143840p:plain

README.mdファイルの作成

README.mdファイルはそのプロジェクトの概要をわかりやすく説明するために必要なファイルです。今回はGitHub上から作成しておきます。作成後はgit pullコマンドで変更を反映します。

$ git pull

これでREADME.mdファイルの作成もできました。
f:id:tyoshikawa1106:20160703144255p:plain

静的リソースの開発環境準備

静的リソース周りの開発はgulp-jsforce-deployをつかって行います。appフォルダを用意してその中で管理していこうと思います。

$ mkdir app
$ cd app
$ npm init
$ npm install gulp gulp-zip gulp-rename gulp-jsforce-deploy --save-dev
$ bower init


次のファイル構成を基本構成として用意します。細かいファイルの内容はGitHubのリポジトリで確認してください。

├── gulpfile.js
├── package.json
├── .env
├── .bowerrc
├── vendor
└── pkg
    ├── package.xml
    ├── devstaticresources
    ├── templates
    └── staticresources


devstaticresourcesフォルダで静的リソースにアップロード対象のファイルを管理します。

$ gulp build-staticresources
$ foreman run gulp deploy

BowerとVendorフォルダ

SLDSなどのライブラリをBowerでインストールできるようにしておきます。インストール先はvendorフォルダです。

Lightning Design Systemのインストール

SLDSのインストールから静的リソースへのアップロードまで試してみます。

$ bower install salesforce-lightning-design-system --save

実行するとvendorフォルダに格納されます。
f:id:tyoshikawa1106:20160703152934p:plain:w200


インストールできたら静的リソースにアップロードします。手順は次のとおりです。

  1. devstaticresourcesフォルダにSLDS202フォルダを作成
  2. lightning-design-systemのassetsフォルダをコピーしてSLDS202に格納
  3. ビルドとデプロイコマンドを実行
$ gulp build-staticresources
$ foreman run gulp deploy

これでLightning Design Systemを静的リソースにアップロードできます。
f:id:tyoshikawa1106:20160703203759p:plain


わざわざassetsフォルダだけコピーしなくても全部のファイルをアップすればいいじゃないかと思うかもしれません。静的リソースには5MBまでという条件があります。なのでSassなどの設定ファイルを含めてアップロードしようとするとあっという間に上限をオーバーしてしまいます。基本的に静的リソースにアップするのはビルド後のファイルだけとし、設定ファイル関係はGitリポジトリで管理するのが一般的みたいです。


SLDSがアップロードできたのでVisualforceページに読み込んでみます。VFページやApexクラスの作成はMavensMate側の機能を利用できます。
f:id:tyoshikawa1106:20160703154125p:plain


いつもどおりに実装して・・・
f:id:tyoshikawa1106:20160703161431p:plain


画面を表示すると正しく静的リソースにアップロードしたファイルを読み込んでCSSを適用できていました。
f:id:tyoshikawa1106:20160703161520p:plain

いったんまとめ

ここまででMaventsMateとgulp-jsforce-deployの機能を利用してVisualforceページを開発できることを確認できました。あとは同じ要領で開発を進めていけるんじゃないかと思います。実際にAngularJs / Reactをつかった開発の流れも確認していきたいのですが、続きは別記事にしようと思います。


今回確認につかったコード一式はこちらにまとめてあります。appフォルダをコピーすれば簡単に動作確認ができると思います。

追記

続き書きました。


関連記事


SFDC:Salesforce Development 2016 - Part 2

$
0
0

Salesforce Development 2016 - Part 1の記事の続きです。Part 1でSalesforceプロジェクトの作成からGitリポジトリの準備、gulp-jsoforce-deployによる静的リソースへのデプロイを確認しました。今回はAngularJSをつかってVisualforceページを作成するときの手順を確認したいと思います。

AngularJSの準備

まずAngularJS自体をBowerをつかってインストールします。

$ cd app
$ bower install angular --save
$ bower install angular-route --save
$ bower install angular-messages --save


これでAngularJS開発で必要なファイルを用意できます。
f:id:tyoshikawa1106:20160703205453p:plain


次はAngularJSを静的リソースにアップロードします。devstaticresourcesフォルダにAngularLibというフォルダを用意してその中に先ほどインストールしたファイル一式を格納しました。
f:id:tyoshikawa1106:20160703205738p:plain


準備ができたらデプロイを実行します。方法はPart1で確認したやり方と同じです。

$ gulp build-staticresources
$ foreman run gulp deploy


これでAngularJSの準備ができました。
f:id:tyoshikawa1106:20160703210050p:plain

覚えておきたいポイント

この方法でデプロイするときに注意しなくてはならない点についてです。AngularJSを静的リソースにアップするためにデプロイコマンドを実行しました。ここで今回の作業で関係の無いSLDSのファイルを確認してみましょう。
f:id:tyoshikawa1106:20160703210223p:plain


最終更新日時がAngularJSをデプロイした時間で更新されています。このようにデプロイのたびに関係無いファイルが一緒に更新されてしまうと困ったことになります。この問題はpkgフォルダ内のpackage.xmlファイルで対象を指定することで解決できるはずです。今回、membersタグの内容が『*』になっているためすべてのファイルがデプロイ対象となってしまいました。ここのファイル指定をデプロイしたいファイルだけに制限すれば関係無いファイルがデプロイされるのを防止できます。


そうすると次はpackage.xmlを管理するのが大変になります。ここで役立つのが作業時にブランチをつくるという考え方です。課題毎にブランチを作成してpackage.xmlには作業対象のファイルのみ指定、コミットを行うという風に進めれば自然とpackage.xmlの指定が必要になると思います。この辺はまた別の記事でまとめてみたいと思います。

AngularJSをつかってVisualforceページを開発する

AngularJSの開発で必要になるのは基本的に次の3つのファイルだと思います。

  • app.js
  • controller.js
  • service.js


これらのファイルをVFページ毎にフォルダにまとめて静的リソースにアップロードします。
f:id:tyoshikawa1106:20160703215800p:plain


あとはVisualforceページで読み込むだけです。
f:id:tyoshikawa1106:20160703215857p:plain

AngularJSの読み込み
<apex:includeScript value="{!URLFOR($Resource.AngularLib, 'angular/angular.min.js')}" />
<apex:includeScript value="{!URLFOR($Resource.AngularLib, 'angular-route/angular-route.js')}" />
<apex:includeScript value="{!URLFOR($Resource.AngularLib, 'angular-messages/angular-messages.min.js')}" />
ページ毎のJSの読み込み
<apex:includeScript value="{!URLFOR($Resource.AngularAccountAppLib, 'app.js')}" />
<apex:includeScript value="{!URLFOR($Resource.AngularAccountAppLib, 'controllers.js')}" />
<apex:includeScript value="{!URLFOR($Resource.AngularAccountAppLib, 'services.js')}" />


これで取引先の一覧を表示するページをAngularJSをつかって作成できました。
f:id:tyoshikawa1106:20160703220423p:plain


もちろんRemoteActionによるApexの呼出しも問題ありません。
f:id:tyoshikawa1106:20160703215950p:plain


今回、app.js, controller.js, services.jsとページ専用のJS処理を実装するファイルが必要になりました。それぞれのファイルに処理を追加した後、デプロイコマンドを毎回実行するのは少し面倒だと思います。


この問題はGulpまたはWebpackのWatch処理をつかうことで解決できます。現時点では対応していませんが、Watch処理でdevstaticresourcesフォルダ内のファイルを監視してファイルが変更されたら自動でビルド処理とデプロイ処理のタスクを実行するように対応することで、手動でのデプロイ実行を無くすことが可能です。


この辺の対応についてもまた今度まとめようと思います。次回はReactを使ったVisualforceページの開発についてまとめてみたいと思います。

サンプルコード

今回対応分のコードを追加したサンプルです。

SFDC:Visualforce in Lightning Experience

$
0
0

Lightning Experienceで利用するためのVisualforceページを開発するときの話です。


Lightning Design Systemを適用することでスタイル部分は簡単にExperience風に変更できますが、Classicのときと同じように作ろうとすると自動で余白が追加されてしまいます。
f:id:tyoshikawa1106:20160705003902p:plain


この問題は『applyBodyTag="false"』を宣言することで解決できるみたいです。
f:id:tyoshikawa1106:20160705004000p:plain


これで周りに余白が追加されないようにできました。
f:id:tyoshikawa1106:20160705004101p:plain


Lightning Experiene向けのVisualforceページを作るときは標準スタイルをOFFにしてBodyタグなども自動挿入されないように設定しておくと良さそうでした。

SFDC:SalesforceAと権限セットの割り当ての新機能

$
0
0

SalesforceAはシステム管理者向けのモバイルアプリです。バージョン 3.2 の新機能で ユーザの権限セットを割り当ておよび削除できるようになりました。

f:id:tyoshikawa1106:20160705021340p:plain

https://itunes.apple.com/jp/app/salesforcea/id731117958?mt=8


バージョンアップ後にアプリにアクセスすると使い方マニュアルが表示されます。
f:id:tyoshikawa1106:20160705020740j:plain:w200

f:id:tyoshikawa1106:20160705020830j:plain:w200

f:id:tyoshikawa1106:20160705020835j:plain:w200

f:id:tyoshikawa1106:20160705020840j:plain:w200

f:id:tyoshikawa1106:20160705020856j:plain:w200


SalesforceAはこの他にもユーザの凍結やロック解除の操作をはじめ、Trust情報へのアクセス、ユーザの基本情報編集(プロファイルを含む)、パスワードリセット対応などシステム管理者に必要になる対応を行うための機能が用意されています。


開発者にとってはあまり必要になりませんが、運用担当者にとっては便利なアプリだと思います。

SFDC:Salesforce Development 2016 - Part 3

$
0
0

Salesforce Development 2016 - Part 3です。前回はAngularJSをつかってVisualforceページを開発するときの流れを確認しました。今回はReactをつかったVisualforceページ開発について確認したいと思います。


前回のPart2はこちら。

はじめに

AngularJSは必要なファイルを静的リソースにアップロードするだけで開発を進めることができました。Reactで開発する場合、ビルドの作業が必要になります。そのため、GulpやWebpackといった開発環境が必ず必要になります。


・・ということで今回の話が一番メインの話です。

NPMパッケージのインストール

無くても大丈夫なものも含まれているかもしれませんが、以下のパッケージをインストールします。

React
$ npm install react --save
$ npm install react-dom --save
$ npm install react-router --save
$ npm install react-slick --save
$ npm install reactify --save
Babel
$ npm install babel-core --save-dev
$ npm install babel-loader --save-dev
$ npm install babel-preset-es2015 --save-dev
$ npm install babel-preset-react --save-dev
Webpack
$ npm install webpack --save-dev
$ npm install style-loader --save-dev
$ npm install sass-loader --save-dev
$ npm install css-loader --save-dev
$ npm install node-sass --save-dev

Reactまわりのフォルダ構成

フォルダ構成です。reactフォルダの中に必要なファイルをまとめます。

  • modulesに各コンポーネント
  • entryにビルド前のファイル
  • buildにビルド後のファイル

ビルドはWebpackをつかって行います。
静的リソースにはビルド後のファイルのみアップロードします。

├── react
|      ├── entry
|      ├── build
|      └── modules
|            └── comoponents
└── pkg
    ├── (略)
    └── webpack.config.js

f:id:tyoshikawa1106:20160705180236p:plain


build, entry, modulesはこのようになります。
f:id:tyoshikawa1106:20160705180344p:plain:w300


webpack.config.jsはこんな感じです。
f:id:tyoshikawa1106:20160705180449p:plain

Reactコンポーネントのビルド実行 ~ 静的リソースへのアップロード

上記のフォルダ構成と設定ファイルを用意したら次のコマンドでビルドを実行できます。

$ webpack

f:id:tyoshikawa1106:20160705180553p:plain


ビルド後のファイルは静的リソースにアップロードします。Part 1 / Part 2のときと同じようにdevstaticresourcesフォルダにまとめてデプロイコマンド実行します。
f:id:tyoshikawa1106:20160705181603p:plain:w300

$ gulp build-staticresources
$ foreman run gulp deploy

これでReactのビルド後のファイルを静的リソースにアップロードできました。
f:id:tyoshikawa1106:20160705181936p:plain

Visualforceページの作成

ReactでつくったJSファイルを静的リソースにアップできたのでいよいよVisualforceページを用意します。
今回用意するデモページは以下のとおりです。

  • ReactBoard.page
  • ReactCounter.page
  • ReactDiscussion.page
  • ReactHome.page
  • ReactSlick.page
  • ReactTodo.page

例えばReactBoard.pageの場合はこんな感じになります。
f:id:tyoshikawa1106:20160705184348p:plain


作成後、そのURLにアクセスしてみると無事に表示されました。
f:id:tyoshikawa1106:20160705184503p:plain


ということでReactコンポーネントをつかってVisualforceページをつくることができました。各コードの詳細は最後に記載するGitHubへのリンクを確認してください。

リンクURLについて

別のVisualforceページへのリンクを用意する場合、URLが『/apex/pagename』となるので注意してください。JS処理を静的リソースに用意する場合は『{!$Page.pagename}』という書き方は利用できません。
f:id:tyoshikawa1106:20160705185145p:plain

静的リソースからの画像読み込みについて

Reactコンポーネントの開発で静的リソースにアップしてある画像を利用したりすると思います。そのときは次のような感じで指定する必要があります。

<svg aria-hidden="true" className="slds-button__icon">
    <use xlinkHref="/resource/SLDS202/assets/icons/utility-sprite/svg/symbols.svg#home"></use>
</svg>

f:id:tyoshikawa1106:20160705185648p:plain

bundle.jsの読み込みについて

VisualforceでJSを読み込む際にはapex:inculdeScriptタグが用意されています。React開発で使おうとすると次のエラーが発生します。

Uncaught Invariant Violation: _registerComponent(...): Target container is not a DOM element.

f:id:tyoshikawa1106:20160705192922p:plain


apexタグの開発向けに用意されているものだからだと思います。Reactで開発する際には普通のHTMLタグで対応するほうがいいみたいです。

その他注意事項

Salesforceの外でつくったページをVisualforceに載せるときにCSSのスタイルが崩れることがあります。標準スタイルシートをOFFにしていても発生すると思います。そういうケースもあることを考慮しておくといいかもしれません。

まとめ

以上、ReactをつかったVisualforceページの開発についてまとめてみました。


SalesforceでReactをつかった開発を行うときは以下の流れを行うことになります。

  1. Reactコンポーネント開発
  2. ビルド実行
  3. 静的リソースへのアップロード準備
  4. 静的リソースへのアップロード実行
  5. 動作確認
  6. 完成するまで繰り返し


今回、ビルドの実行からSalesforceへのデプロイまで毎回コマンドを実行して行いましたが、GulpやWebpackでうまく対応すればこのあたりはもっと自動化できたり、より改善したりできると思います。


今回やったところを追加したサンプルコードはこちらです。

追記

続き書きました。

SFDC:Force.com CLI -Metadata Exportの使い方

$
0
0

Force.com CLIの使い方、Export機能を使ったメタデータ情報の取得についてです。あまり情報の多くないForce.com CLIですが海外の人の書いたブログが公開されています。・・ということでこのブログで紹介されていた便利機能を試してみました。

f:id:tyoshikawa1106:20160706015351p:plain

Bob Buzzard Blog: Force CLI Part 2 - Extracting Metadata


Force.com CLIを使うには最初にログインします。

$ force login


Exportするには次のコマンドです。

$ force export


実行すると次のエラーが発生するかもしれません。metadataディレクトリが存在しないため発生するエラーです。

Not done yet: Queued Will check again in five seconds.
Not done yet: InProgress Will check again in five seconds.
Not done yet: InProgress Will check again in five seconds.
Not done yet: InProgress Will check again in five seconds.
Not done yet: InProgress Will check again in five seconds.
Not done yet: InProgress Will check again in five seconds.
Error obtaining root directory
ERROR: stat /Users/tyoshikawa1106/desktop/work/metadata: no such file or directory


実行前にmetadataディレクトリを用意しておきましょう。
f:id:tyoshikawa1106:20160706013417p:plain


正しく実行されると『Exported to metadata』と表示されます。
f:id:tyoshikawa1106:20160706013550p:plain


metadataフォルダの中を確認すると全メタデータを取得できています。
f:id:tyoshikawa1106:20160706013628p:plain:w200



アプリケーションやカスタム表示ラベル、ページレイアウトからオブジェクト情報、その他諸々のメタデータを取得できています。
f:id:tyoshikawa1106:20160706013852p:plain


zipコマンドを使えばExport後のmetadataフォルダをzip変換することもできるみたいです。

$ zip -r metadata > backup.zip

f:id:tyoshikawa1106:20160706014128p:plain


特定のメタデータのみExportすることも可能です。

$  force fetch -t <target>


使用例です。

$ force fetch -t Aura
$ force fetch -t Layout

f:id:tyoshikawa1106:20160706014846p:plain


Force.com IDEやMaventsMateの機能でExportするよりも短時間で実行できます。これでエクスポートした後、Gitでバージョン管理というような使い方をしたりできると思います。

関連記事



SFDC:Salesforce Development 2016 - Part 4

$
0
0

Salesforce Development 2016 - Part 4です。Part1で記載しましたが、ページやクラス、静的リソース用のコードはGitで管理できるようにしていました。今回はメタデータもGitの管理対象に追加したいと思います。


ちなみにReactとVisualforceについてまとめたPart 3はこちらです。


Salesforceではオブジェクトやページレイアウトを始め、ほとんどの情報をメタデータで管理できる仕組みとなっています。なのでこのメタデータをダウンロードしてGit管理に追加すればカスタマイズ情報を管理できるはずです。


問題はメタデータの取得方法です。メタデータは種類だけでもこれだけのものが用意されています。カスタマイズを進めていくとファイル数がさらに膨大な数になります。
f:id:tyoshikawa1106:20160706013628p:plain:w200


Force.com IDE, MaventsMateにもエクスポートする機能は用意されていますが、ファイル数が多くなっていくとエクスポート実行に時間が掛かってしまいます。


そこで便利なのがForce.com CLIです。このツールを使えば上記方法に比べて短時間でエクスポートできます。


次のコマンドでログイン、エクスポートを実行できます。

$ force login
$ force export


Force.com CLIを利用するにはmetadataフォルダが必要になります。次のような感じでappフォルダの中に用意しました。
f:id:tyoshikawa1106:20160706023121p:plain:w300


実行イメージです。
f:id:tyoshikawa1106:20160706023719g:plain


Force.com CLIを利用すれば効率よくSalesforceのメタデータを取得できました。ファイルが取得できたので後は普通にGitで管理できます。・・・メタデータを取得できても一部使い方が難しいものありました。メタデータで何ができて何ができないかは検証しておくといいかもしれません。

SFDC:Apexで文字数上限オーバー時に省略記号を表示する方法

$
0
0

Apexで開発するときString型の文字数が指定した上限を超えた時に省略記号「...」を表示して残りは非表示にするケースがあると思います。subStringをつかった方法でも対応できますが、よりシンプルに実装できるabbreviateというメソッドがありました。

f:id:tyoshikawa1106:20160706152349p:plain


動作確認のコードです。


このような実行結果を確認できます。
f:id:tyoshikawa1106:20160706152812p:plain


abbreviateの引数「maxWidth」は省略記号「...」を含めた文字数となります。省略時でも5文字までは必ず表示したいという場合は 5(最低文字数) + 3(省略記号文字数) で8と指定する必要がありました。それと上限8と指定した場合、省略記号が追加されるのは9文字以上となった場合だけです。8文字(上限値)ピッタリのときは省略されずに表示されます。


abbreviateの対象になるString変数がNULLだった場合はExceptionエラーが発生します。ブランク(空文字)の場合はエラーになりません。


ちなみにString.addreviteはWinter'13から使えたメソッドです。
f:id:tyoshikawa1106:20160706153345p:plain

SFDC:Force.com CLI -Metadata Importの使い方

$
0
0

Force.com CLI -Metadata Importの使い方についてです。Force.com CLIにはSalesforceのメタデータをエクスポートすることができます。インポート機能を使えばメタデータをSalesforce組織に取り込むことができます。

f:id:tyoshikawa1106:20160707001913p:plain

利用例

例えばforce export機能を使ってカスタム表示ラベルのメタデータを取得し、別のSalesforce組織にインポートするというような使い方ができると思います。

エクスポート対象の組織にログイン

$ force login

エクスポートの実行

$ force export

これでカスタム表示ラベルのメタデータを取得できます。
f:id:tyoshikawa1106:20160707005802p:plain

エクスポート組織からログアウト

続いて別のSalesforce組織に切り替えます。まずはエクスポート対象の組織からログアウトします。

$ force logout -u <username>


ログアウト後はインポート対象の組織に『force login』をつかってログインし直します。

補足

Force.com CLIは別アカウントでログインしてもログアウトするまではログインしたまま残ります。activeコマンドで対象ユーザを切り替えるといったことも可能です。

$ force active -a <username>

※基本的には作業が終わったらログアウトを行うようにした方が良さそうです。

インポート組織にログイン
$ force login <import org usernamse>
インポート用ディレクトリに対象ファイルを用意する

エクスポートしたファイルをインポート用ディレクトリにコピーします。(インポートしたい情報のみで大丈夫です。)
f:id:tyoshikawa1106:20160707010121p:plain


package.xmlでインポート対象を指定します。
f:id:tyoshikawa1106:20160707010214p:plain

インポートを実行

※実行前に『force active』コマンドでアカウントを間違えたりしていないか確認するようにしておくと安心です。

次のコマンドでインポートを実行します。

$ force import


実行結果はこんな感じです。
f:id:tyoshikawa1106:20160707010640p:plain



インポート先の組織を確認してみるとカスタム表示ラベルが取り込まれていることを確認できます。
f:id:tyoshikawa1106:20160707010817p:plain


force importをつかったメタデータのインポートの流れはこんな感じです。

インポート時の注意点

force importを使えばSalesforceのカスタマイズ情報を簡単に取り込むことができます。ですが使い方を間違えると古いカスタマイズ情報で上書きしてしまう事故が発生しそうです。そんなトラブルを回避するために次の点に気をつけておくと良さそうです。

1. エクスポート用のメタデータは最新のものを持ってくる

エクスポートした後、知らない間に変更されてしまうと古い情報をインポートすることになってしまいます。エクスポートして時間のたったメタデータを対象にするのはやめておいたほうが良さそうです。

2. インポート対象のフォルダには必要なものだけいれる

例えばカスタム表示ラベルをインポートしたい場合、その他のメタデータをmetadataフォルダに残しておくと関係のないカスタマイズ情報をインポートしてしまう危険があります。package.xmlで対象を制御はできますがうっかり指定し忘れて全ファイルがインポート対象になってしまったというトラブルが考えられます。


基本的にはエクスポート、インポートは作業フォルダを用意してうっかり事故の起こらないように注意しておくといいと思います。あとは定期的にエクスポートしてGit管理するようにしておくと万が一トラブルが発生してしまったときでも復元しやすくなると思います。

SFDC:開発向けWave Analyticsのホームページ

$
0
0

DevelopersサイトにWaveAnalyticsのホームページが公開されたみたいです。

f:id:tyoshikawa1106:20160708125404p:plain

Analytics - developer.force.com

Learn

Waveに関するTrailheadサイトへのリンクです。
f:id:tyoshikawa1106:20160708125454p:plain:w200

Do

Waveに関するヘルプ、開発者ガイドなどへのリンクです。
f:id:tyoshikawa1106:20160708125540p:plain:w200

Get

Waveに関するツールへのリンクです。これはちょっと確認しておくと良さそうです。
f:id:tyoshikawa1106:20160708125709p:plain:w200

Analytics-Cloud-Dataset-Utils

その他

あとはこんな感じでした。
f:id:tyoshikawa1106:20160708125927p:plain

参考

SFDC:Force.com CLIの『export』と『fetch』の違い

$
0
0

Force.com CLIにはメタデータをエクスポートできる『force export』コマンドが用意されていますが、もうひとつ同じようなことができる『force fetch』コマンドが用意されています。この2つのコマンドの違いについてです。

force export

まずはforce exportについてです。

$ force login
$ force export


このコマンドを実行するとすべてのメタデータとpackage.xmlをダウンロードできます。実行時に既に前回ダウンロードしたファイルが存在している場合は最新のファイルで上書きされます。

force fetch

fetchコマンドを使えば特定のメタデータのみを指定してダウンロードすることができます。

$ force login
$ force fetch -t <Target>


例えばApexクラスの情報を取得したい場合は次のようになります。

$ force fetch -t ApexClass

f:id:tyoshikawa1106:20160708160119p:plain


特定のメタデータのみ取得したい場合はforce fetchコマンドが便利そうです。

SFDC:Salesforce Development 2016 - Part 5

$
0
0

今回はBitbucketをつかったSalesforceのプロジェクト管理についてです。Bitbucketにはコミットしてファイルのバージョン管理をする以外にも覚えておきたい便利機能がいくつかあるのでそれも一緒に紹介したいと思います。


ちなみにSalesforceのメタデータ管理についてまとめたPart 4はこちらです。

プロジェクト管理の流れ

Gitリポジトリの作成方法は大丈夫だと思うので、Bitbucketにリポジトリが作られたところから始めます。プロジェクトに途中参加したときのイメージです。
f:id:tyoshikawa1106:20160708170903p:plain

MaventsMateでSalesforceプロジェクトを作成

まずはいつもとおりにプロジェクトを作成します。
f:id:tyoshikawa1106:20160708171601p:plain


この時点ではSalesforceから最新のコードを取得しただけとなります。
f:id:tyoshikawa1106:20160708171737p:plain

Gitリポジトリとの紐付け

ターミナルからGitコマンドで.gitファイルを作成します。

$ git init

f:id:tyoshikawa1106:20160708171935p:plain


続いてBitbucketとの紐付けを行います。

$ git remote add origin git@bitbucket.org:<your app>.git
$ git remote

f:id:tyoshikawa1106:20160708172126p:plain


Bitbucketとの紐付けができたらGitリポジトリ上のファイルを取得します。

$ git fetch origin
$ git reset --hard FETCH_HEAD

f:id:tyoshikawa1106:20160708172304p:plain


.gitignoreファイルを始め、リポジトリ上で管理されたファイル一式を取得できました。
f:id:tyoshikawa1106:20160708172412p:plain:w200


これでプロジェクトへの参加準備が完了です。

Issue(課題)の作成

設定から有効化することでIssue機能が利用できるようになります。これで誰がどのような作業を行うか管理できます。
f:id:tyoshikawa1106:20160708172701p:plain


画面の開発などのタスクはIssueを作成して管理するようにします。
f:id:tyoshikawa1106:20160708173341p:plain


担当者はそのIssueの作業者です。KindはIssueの種類 (バグ / タスクなどの識別)。Priorityは緊急度という感じで管理できます。ファイルを添付することも可能です。場合によっては設計書や打ち合わせのメモを添付することで情報の共有ができます。


Issueを作成すると#1というように識別番号が自動採番されます。
f:id:tyoshikawa1106:20160708173832p:plain

Issueの対応開始

作業開始時には画面右上のメニューで『開く』を選択します。
f:id:tyoshikawa1106:20160708174052p:plain


これによりステータスが『Open』で更新されます。課題一覧画面での作業状況確認に役立ちます。
f:id:tyoshikawa1106:20160708174236p:plain

ブランチの作成

開発をはじめるときブランチを用意します。ブランチ名ですが、Issue名をつけるようにしておくと管理がしやすくなるみたいです。

ブランチ名にissue番号を使う - Qiita


メニューのブランチページから作成できます。
f:id:tyoshikawa1106:20160708175045p:plain


これでIssue毎にブランチを作成して作業を進める準備ができました。
f:id:tyoshikawa1106:20160708175240p:plain

Source Treeの準備

ブランチを作成したらSource Treeから操作できるようにします。まずはSourceTreeを起動してSalesforceプロジェクトをドラッグ&ドロップしてブックマークとして設定します。
f:id:tyoshikawa1106:20160708182129p:plain:w200


次にBitbucketのページの『SorceTreeにチェックアウト』ボタンをクリックします。
f:id:tyoshikawa1106:20160708182351p:plain:w200


これでSourceTreeにブランチをチェックアウトしてコミットやプッシュなどを行えるようになりました。
f:id:tyoshikawa1106:20160708182630p:plain

開発

普通に開発を進めます。
f:id:tyoshikawa1106:20160708184325p:plain

コミットとプッシュ

画面の開発ができたらコミットしてプッシュします。(実際の開発では細かくコミットしますが今回はデモなので省略します。)


uncommited changesを選択します。作業ツリーのところが追加/変更のあったファイル一覧です。
f:id:tyoshikawa1106:20160708184628p:plain


チェックをつけてステージ環境に移行します。
f:id:tyoshikawa1106:20160708184709p:plain:w300


コミットメッセージを入力してコミットします。
f:id:tyoshikawa1106:20160708185013p:plain


コミットが完了したらプッシュを行います。このとき、masterにはプッシュしません。
f:id:tyoshikawa1106:20160708185151p:plain:w200


これでBitbucketのリポジトリにブランチごとプッシュできました。
f:id:tyoshikawa1106:20160708185356p:plain

プルリクエストの作成とコードレビュー

開発が終わったら、masterにマージします。ですがそのままマージするのではなくプルリクエストをつかって対応します。プルリクエスト機能を使えば誰かにレビューしてもらい、問題なければマージされるという流れを作ることが出来ます。
f:id:tyoshikawa1106:20160708185656p:plain


メニューのプルリクエストから作成できます。
f:id:tyoshikawa1106:20160708185931p:plain


ブランチの閉鎖にチェックをつければマージ後に自動でブランチが削除されます。最初そのほうがスッキリしていいかと思っていたのですが、過去の作業ログを残す意味でも削除しない方がいい気がしてきました。


プルリクエスト作成後の画面はこんな感じです。
f:id:tyoshikawa1106:20160708190201p:plain


コードの差分箇所をここで確認できます。
f:id:tyoshikawa1106:20160708190231p:plain


コメントを残してレビュー結果などを相手に伝えることもできます。
f:id:tyoshikawa1106:20160708190409p:plain


特定のファイルに対してコメントすることも可能です。
f:id:tyoshikawa1106:20160708190522p:plain


その場合、このように吹き出しで確認できます。
f:id:tyoshikawa1106:20160708190609p:plain


プルリクエストには却下機能も用意されています。
f:id:tyoshikawa1106:20160708190828p:plain


ですが、却下するとそのプルリクエストは終了してしまいます。コメントをやりとりして指摘事項の修正を続ける場合は却下する必要はありません。


コメントからタスクを作成する機能も用意されています。
f:id:tyoshikawa1106:20160708191521p:plain


レビューの指摘事項等をまとめておくと次のレビュー時に何を確認すればいいか管理しやすくなりそうです。
f:id:tyoshikawa1106:20160708191640p:plain

指摘事項の修正対応と再レビュー

レビューで指摘されたテストクラスの追加を行いコミットまで終わりました。
f:id:tyoshikawa1106:20160708192241p:plain


問題がないことを確認して再度プッシュします。すると先程のプルリクエストに自動で反映されます。
f:id:tyoshikawa1106:20160708192423p:plain


コミット履歴からも確認できます。(レビュー後のコミットで変更された箇所だけの確認もここからできます。)
f:id:tyoshikawa1106:20160708192454p:plain


このように却下しなければレビュー→修正→再レビューという流れで作業を進めることができます。

プルリクエストの承認とマージ

プルリクエストには承認機能がついています。レビューアが複数人いる場合などはここで誰が承認したかを管理できます。
f:id:tyoshikawa1106:20160708193003p:plain

承認者にはチェックがつきます。
f:id:tyoshikawa1106:20160708193051p:plain


レビューアの承認後、マージボタンをクリックしてmasterにマージします。(ここはレビューアの人の作業)
f:id:tyoshikawa1106:20160708193336p:plain


これでmasterブランチに開発内容が反映されました。
f:id:tyoshikawa1106:20160708193502p:plain

f:id:tyoshikawa1106:20160708193542p:plain

Issueのクローズ

マージされ予定していた作業が完了しました。最後にIssueのステータスをクローズにします。
f:id:tyoshikawa1106:20160708193739p:plain

f:id:tyoshikawa1106:20160708193814p:plain


以上がIssueのオープンからクローズまでの流れです。これで作業毎に誰がどのような対応を行ったか記録を残すことができます。またコードレビューを行うことでうっかりミスの発見や、より良い実装方法の共有などを行うことができます。

Git管理とインデント

Apex開発でインデントを指定する際にタブかスペースか人によって違ったりすると思います。Bitbucketのページからコードを確認する際に、タブの場合隙間が少し広く表示されてしまうので個人的にはスペースの方が良さそうかなと思います。

タブの場合

f:id:tyoshikawa1106:20160708194836p:plain

スペースの場合

f:id:tyoshikawa1106:20160708194855p:plain

最後に

こんな流れでSalesforceプロジェクトをGitで管理できると思います。


SalesforceはGit管理と相性が良くないという話もあったと思いますが、DreamforceでSalesforce × Gitに関するセッションがあったり、Bitbucketを開発しているAtlassian社がSalesforce Developers向けにCookbookを公開したりと、Salesforceとバージョン管理についてもいろいろベストプラクティスが検討されているみたいです。


Gitを使ってバージョン管理することで後から不要になったコードをコメントアウトして残す必要もなくなり、メンテナンスがやりやすくなります。またReactやAngular2などビルド作業が必要になる開発では、静的リソース以外にコードを管理できる環境が必須になると思うのですが、Gitリポジトリを用意することでビルド時の設定ファイルなどを管理できるようにもなると思います。


以上、BitbucketをつかったSalesforceのプロジェクト管理についてでした。

SFDC:Lightning Experienceナビゲーションの仕様変更

$
0
0

Winter '17へのアップデートでLightning Experienceのナビゲーションメニューに関する大きな変更が予定されているみたいです。現在、LEXのナビゲーションメニューは画面左側に表示されています。
f:id:tyoshikawa1106:20160713171008p:plain


このナビゲーションの位置がWinter'17で変更され、Salesforce Classicのときと同じように画面上側に表示されるようになるみたいです。(アプリケーションの切り替えもここでできるっぽい)
f:id:tyoshikawa1106:20160713171308p:plain


けっこう大きな変更ですが、さっそくSalesforceのヘルプページが公開され、変更理由や事前準備の手順などが記載されていました。
f:id:tyoshikawa1106:20160713171547p:plain

FAQ - Lightning Experience Navigation Changing with Winter ‘17


顧客やパートナー、Salesforce内での継続的な研究からのフィードバックに基いて、生産性を向上するために変更します..という感じの理由でした。


この変更でアプリケーション名がナビゲーションに表示されたり、ブランディングイメージ(ロゴ)、カラーをカスタマイズしたりできるようになるみたいです。
f:id:tyoshikawa1106:20160713172534p:plain


LEXのナビゲーションメニューは、Classicのアプリケーションとは別もの扱いでプロファイル毎に1つしか設定できなかったのですが、この仕様変更でClassicと同じようにカスタマイズできるようになるのかなと思います。


左側に表示されてるデザインは気に入っていたので変更は少し残念ですが、カスタマイズできることは増えるっぽいので、この変更でLEXが使いやすくなればいいなと思いました。既に運用環境でLEXを利用しているところは、ヘルプをちゃんと確認しておいた方が良さそうです。


SFDC:TrailheadにDesk.com関連のモジュールが追加されました

$
0
0

Salesforce製品の1つDesk.comがTrailheadに追加されました。Customer Supportに対応するための製品です。
f:id:tyoshikawa1106:20160714131628p:plain




以下の内容について学ぶことができます。

Desk.com Basics
  • Desk.comとは
  • Desk.comでビジネスを助けることができる方法
  • Desk.comとサービスクラウドの違いを説明
  • Desk.comにおける管理者とエージェントコンソールの違い
  • クラシックと次世代エージェントコンソールの違い
  • Desk.comの主なセクションを検索する場所
Desk.com Toolkit
  • 管理コンソールを使用すると、Desk.comのカスタマイズにどのように役立つか
  • 管理コンソールをナビゲートする方法
  • 新しいエージェントを設定し、グループにエージェントを追加


Desk.comにはDeveloper環境のように開発者が自由に利用できる環境は無いみたいなので少し勉強しづらいですが、14日間のFreeTrial環境があるので、本当に必要になったときはここで使い方を確認できると思います。
f:id:tyoshikawa1106:20160714132024p:plain

Desk.comとサービスクラウドの違い

サービスクラウドとDesk.com:Salesforceのは、2つの顧客サービスの製品を持っているので、あなたが混同される可能性があります。両方は、最良の事業の種類を果たす異なる強度を有します。

Desk.comはケースを中心としている企業に最適です。顧客サービスのための要求は、通常、単一の問題ではなく、相互接続された顧客の問題を伴います。

サービスクラウドは、アカウント中心でビジネスに最適です。これらの事業については、顧客サービス・エージェントは、マーケティング、製品管理、契約、注文管理、または課金データとして、企業のさまざまな部分から引か情報と、顧客の完全なビューを必要としています。

Desk.comとServiceCloudの連携

Desk Connectというものが用意されているみたいです。これを使ってDesk.comとServiceCloudをシームレスに連携できるみたいです。

Desk.com is connected to Salesforce via, you guessed it, Desk Connect.

管理とエージェントコンソールの違い

デスクを設定する場合は管理コンソール、顧客と対話する場所がエージェントコンソール。

クラシックと次世代エージェントコンソールの違い

次世代エージェントコンソールは、エージェントコンソールの新しいバージョン。クラッシコンソールは廃止される予定。

デスク内の異なるコンソールやツール間を移動する方法

ハンバーガーメニューから。
f:id:tyoshikawa1106:20160714133620p:plain

ソーシャルアカウントと連携する方法

CHANNELメニューから設定できる

外部アプリと連携する方法

APPSから設定できる


その他詳細はTrailheadを確認するのが良いと思います。こんなダッシュボードをつくったりもできるみたいです。
f:id:tyoshikawa1106:20160714134714p:plain

SFDC:Shield Platform Encryption(プラットフォームの暗号化)を試してみました

$
0
0

Shield Platformを利用すればセキュリティ向上のための暗号化を行うことができるみたいです。使い方はTrailheadで紹介されています。

f:id:tyoshikawa1106:20160714135627p:plain

Shield Platform Encryption | Salesforce Trailhead

利用方法

アクセス権限の割り当て

権限セットを用意します。
f:id:tyoshikawa1106:20160714140115p:plain


System PermissionsにManage Encryption Keysがあります。これで権限を追加できます。
f:id:tyoshikawa1106:20160714140325p:plain


権限セットはユーザの詳細ページなどから割り当てできます。
f:id:tyoshikawa1106:20160714140443p:plain


これでアクセス権限の追加ができました。

Platform Encryptionの設定

設定の検索ボックスに「Platform Encryption」と入力すると設定画面を見つけることができます。
f:id:tyoshikawa1106:20160714140620p:plain


Generate Tenant Secretボタンをクリックすると、Encrypt Files and Attachmentsの権限を有効化できるようになります。
f:id:tyoshikawa1106:20160714140804p:plain


日本語の場合はこんな感じ。(Platform Encryption → プラットフォームの暗号化)
f:id:tyoshikawa1106:20160714140910p:plain


f:id:tyoshikawa1106:20160714141140p:plain

f:id:tyoshikawa1106:20160714141157p:plain


ファイルを Salesforce Files にアップロードするとき、またはレコードに添付するときに暗号化できるようにしたり、新しいテナントの秘密は、24 時間に一度生成できるというルールがあります。


エクスポートボタンでテナントの秘密の暗号化されたコピーを取得できます。
f:id:tyoshikawa1106:20160714141323p:plain


Platform Encryptionの基本設定はひとまずこんな感じです。

フィールド、ファイル、および添付ファイルを暗号化

項目を暗号化リンクをクリックすると各項目の設定ができるようになります。
f:id:tyoshikawa1106:20160714141716p:plain


設定できる項目はこんな感じ。一部の標準オブジェクトの項目のみとなっているみたいです。
f:id:tyoshikawa1106:20160714141846p:plain


暗号化機能を利用する間にいくつか制限があるので必ずヘルプを確認してください。とメッセージもありました。
f:id:tyoshikawa1106:20160714141942p:plain

https://help.salesforce.com/htviewhelpdoc?err=1&id=security_pe_considerations.htm&siteLang=ja


また、暗号化には少し時間がかかります。
f:id:tyoshikawa1106:20160714142109p:plain


有効化が完了すると次のようなメール通知が届くようになっています。
f:id:tyoshikawa1106:20160714142214p:plain


例えば取引先の電話項目を暗号化対象に追加します。追加後にレコードを作成すると・・・
f:id:tyoshikawa1106:20160714142550p:plain


電話項目の値が暗号化されました。
f:id:tyoshikawa1106:20160714142643p:plain


暗号化された値はシステム管理者ユーザでも表示することはできませんでした。
f:id:tyoshikawa1106:20160714142914p:plain


編集画面ではこのように表示されます。
f:id:tyoshikawa1106:20160714143250p:plain


暗号化された値を表示するには、View Encrypted Dataの権限が必要になります。
f:id:tyoshikawa1106:20160714143654p:plain


権限を追加すると内容を確認できるようになります。
f:id:tyoshikawa1106:20160714143756p:plain


プラットフォームの暗号化機能の使い方はざっくりこんな感じでした。Sandbox環境のテストデータを暗号化するときなんかにも利用できるみたいです。

SFDC:[Known Issues] Windows Update後のExcel出力機能のトラブル

SFDC:自動採番項目とUPSERTの注意点

$
0
0

Salesforceの自動採番項目はUPSERT処理の対象として選択できないみたいです。データローダ向けの話ですが、ヘルプページが用意されていました。Apexからでも同じ理由でエラーになるんだと思います。

f:id:tyoshikawa1106:20160715220540p:plain

データローダで外部 ID として自動採番が利用できません


実際に試してみました。まずは普通にテキスト型のNameだった場合です。
f:id:tyoshikawa1106:20160715220904p:plain


テストデータを1件用意して確認します。
f:id:tyoshikawa1106:20160715220949p:plain


検証コードはざっくりですがこんな感じ。
f:id:tyoshikawa1106:20160715221205p:plain


無事に更新されました。Upsert処理時にNameをキーに更新できることも確認できたと思います。
f:id:tyoshikawa1106:20160715221326p:plain



それではNameが自動採番型だった場合です。
f:id:tyoshikawa1106:20160715221452p:plain


Upsert処理は同じように実行します。
f:id:tyoshikawa1106:20160715221539p:plain


実行するとエラーになりました。
f:id:tyoshikawa1106:20160715221606p:plain

System.DmlException: Upsert failed. First exception on row 0 with id a0Gi000000R4Y36EAF; first error: MISSING_ARGUMENT, Name not specified: []


値が見つかりません。という感じのエラーだと思います。自動採番項目の値はUpsert時には認識されないのかもしれません。


この問題の解決方法についてですが、こちらのページで1つ紹介されていました。テキスト型項目を用意してワークフロールールなどで自動採番の値をセットする。・・数式のときでも利用する方法です。たぶん他に方法は無いんじゃないかなと思います。


意外と自動採番項目をUPSERTの対象にする機会ってなかったので、こういうルールがあることに気づきませんでした。オブジェクト構成を考える時には意識しておくと良さそうです。

SFDC:DreamHouseの日本語版が公開されました

$
0
0

DreamHouseの日本語版が公開されました。

f:id:tyoshikawa1106:20160722221738p:plain

DreamHouse JP サンプルアプリケーション | Salesforce Developers


実際に自分の組織で動作確認できるパッケージが用意されています。インストールページに詳細な手順が記載されていました。
f:id:tyoshikawa1106:20160722222026p:plain

インストール手順

ざっくりこんな感じです。

1. 新しい Developer Edition 組織を作成

まずは新しいDev環境を用意します。
f:id:tyoshikawa1106:20160722222423p:plain

2. Lightning Experienceの有効化

f:id:tyoshikawa1106:20160722222832p:plain

3. 私のドメインの有効化

カスタムドメインが必要になります。
f:id:tyoshikawa1106:20160722222928p:plain

4. Enable App Builder for Lightning Experience (PILOT)のチェック

組織によってはLightning アプリケーションビルダーのページに『Enable App Builder for Lightning Experience (PILOT)』が表示されているみたいです。自分の組織には無かったのでスキップしました。
f:id:tyoshikawa1106:20160722223735p:plain

5. パッケージをインストール

パッケージをインストールします。インストールURLはDeamHouseのサイトに公開されています。『すべてのユーザのインストール』でインストールする必要があります。
f:id:tyoshikawa1106:20160722223857p:plain

6. パッケージインストール時の注意点

『すべてのユーザのインストール』でインストールする必要があります。

7. Lightning Experienceに切り替え

設定などから切り替えます。
f:id:tyoshikawa1106:20160722224144p:plain

8. Lightning LockerService セキュリティの無効化

Summer'16の場合..ということで重要な更新で無効化します。
f:id:tyoshikawa1106:20160722224324p:plain


9. アプリケーションの設定

アプリケーションの設定で、Property ExplorerタブをDreamHouseアプリケーションに追加します。
f:id:tyoshikawa1106:20160722224648p:plain

10. アプリケーションにアクセス

アプリケーションにDreamHouseが追加されています。
f:id:tyoshikawa1106:20160722224444p:plain

11. Data Import

Data Importタブを選択してInitialize Sample Dataボタンをクリックします。
f:id:tyoshikawa1106:20160722224906p:plain

f:id:tyoshikawa1106:20160722224930p:plain:w200

12. インポート結果の確認

続いて、Brokersタブにアクセスします。Data Importがうまく実行されていればデモデータが用意されています。
f:id:tyoshikawa1106:20160722225059p:plain


同じく、Propertiesタブにアクセスするとデモデータを確認できます。
f:id:tyoshikawa1106:20160722225227p:plain


ナビゲーションの設定でサイドメニューにDreamHouseアプリのタブを表示するようにしておくとアクセスしやすくなります。
f:id:tyoshikawa1106:20160722225535p:plain


ただし、Lightning ナビゲーションのカスタマイズはWinter'17で廃止される予定です。


これで、DreamHouseアプリで必要なオブジェクトやデモデータの準備が整いました。DreamHouseアプリをつかうことでLightning開発やSalesforce1モバイル、Heroku、Bot、Slack連携などのアプリを試してみることができます。
f:id:tyoshikawa1106:20160722230031p:plain


それらのコードは基本GitHubで公開されています。今回の手順でSalesforceの組織を準備したら、それぞれのアプリのコードをGitHubから取得して試していくという流れになると思います。

関連記事

Viewing all 1438 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>