いっぱいあるsfdxのコマンドの勘所をつかむための一枚絵を作ってみました。
(探せばありそうな気もしますが…)
作業メモです。
非管理パッケージを作った後で、取ってきたメタデータをコピーしてあげればよいみたいですね。
$ sfdx force:project:create --projectname sample-project
慣れないうちはレイアウトもデフォルトにしておいた方が無難でしょう。
CLI経由で、DE組織へのアクセスが行えるようにします。
$ sfdx force:auth:web:login -a de1
ブラウザが立ち上がって、Salesforceへのログインが促されるので、ログインします。
何かと使うので、組織のエイリアス de1
も指定しておきます。
バージョン管理したいメタデータをコンポーネントに追加した上で、非管理パッケージをアップロードします。
とりあえず重要なのは
だけなので、それ以外はテキトーに…。
以下、パッケージ名は「pkg1」にしたことを前提としています(要:適宜読み替え)。
$ sfdx force:mdapi:retrieve -s -r ./tmp -u de1 -p pkg1
./tmp/
の下に unpackaged.zip
が落ちてくるはず。
$ unzip ./tmp/unpackaged.zip -d ./unzipped
$ sfdx force:mdapi:convert -r ./unzipped
コマンドリファレンスに "This command must be run in a project." とあるので、必須な処理みたいですね。
ところでこのコマンド、「一体何をしているか?」ですが、基本的には、unzipped/**/*
から force-app/main/default/**/*
への再帰的なファイルコピーのようです。
ただし単純なコピーではなく、以下のように、いくつか例外(?)があります。
package.xml
はコピーしない。これは .forceignore
が効いているせいかもしれません。*-meta.xml
ファイルがない場合、オリジナルのファイルに -meta.xml
を付けた形でリネームする。挙動から推測するより、中身を見たほうが早いかも、と思いました。
Winter '18にて、Bulk API 2.0が正式リリースされました。
あんまり話題になっていないような気がするので、簡単にまとめてみます。
新機能については上記ページでも言及されていますが、主観で重要そうだなと思うところをピックアップします。
一番大きな違いはSOAPからRESTになったことですね。そのため、使う側からするとほぼ別物として見た方がよさそうです。
v1.0 | v2.0 | |
---|---|---|
API | SOAP(XML)ベース | REST(JSON,CSV)ベース |
結果の評価・後処理 | 結果(Request)はID, Success, Created, Errorの4項目しかないため、RequestとResultを行番号やIDで突き合わせて行なう | 結果取得APIレスポンスの中に要求した各項目も含めて返ってくるため、突き合わせが不要 |
バッチのローテーション | CSVが10,000行あるいは10,000,000 文字を超えたら 自分で 面倒を見る | 最大 150MB (base64 エンコード後) までは 自動で 分割される |
処理されなかったジョブデータ | 結果CSVから自分で評価して抜き出す | 専用のAPIがある |
また、アップロードするデータが20,000 文字以下の場合、ジョブの作成とアップロードをマルチパート要求で1回でできるので、 (大半のケースで)SalesforceのAPI消費が1.0よりも少なくて済むと思います(多分)。
APIがSOAPからRESTに変わったことで、「APIのドキュメントは公開するから好きなHTTPクライアントで実装してね」という方針になったのかどうかは分かりませんが、ネットで探してもあまり利用例が見当たりません。
ということで、試してみました(言語はJavaです)。
とは言え、Bulk API 2.0では、一般的なREST APIでJSONやCSVをやり取りするだけなので、呼び出し方さえ間違えなければさくっと動いてくれました*1。
で、色々と試行錯誤した結果、薄いクライアントライブラリ(ラッパー)ができあがったので、公開してみます。
(使用例はリポジトリのREADMEにあります)
*1:エラーレスポンスのフォーマットがドキュメントに見当たらなかったり、日本語版のドキュメントでレスポンスパラメータ名が間違っていたりはありましたが…w
一度は「ひとりAdvent Calendar」をやってみたいなーと思っていて、密かな目標として12月は25日まで毎日更新を目論んでいたのですが、半分にも満たない10日でFinishしました。
予定外に風邪をひいたりしてしまったことも多少は影響していますが、いやはや、完走できる人はすごいですね。
Salesforceネタが7つ、AWSネタが3つでした。
本分はJava屋(だと思っている)のですが、今年はあまり新しい刺激が(業務においては)少なく、守りの年でした。
あと、ブログに感想は書けていませんが、12月は以下の勉強会に参加していました。
さて、日頃からインプットとアウトプットのバランスをとるように心がけているのですが、相変わらずアウトプット(ここでのアウトプットはブログを書くことに限定します)はムラが多すぎるなーと反省。。
目標の25日には届きませんでしたが、継続的にアウトプットをするための気構えとして感じたことを書き留めておきます。
Advent Calendarにエントリするのは今年で4回目でしたが、今までで一番リラックスして書くことができました。こう言ってしまうとなんですが、記事を書くための仕込みの時間も一番短かったと思います。
なんとなくAdvent Calendarというと、大作(=分量が多い・技術的に高度・ネタ色が強い)でないとダメ、みたいに感じていましたが、そんなことはないのかなと思うようになりました。テーマに沿っており、将来の自分や誰かの役に立つネタであれば、極論、一文・一行でもいいのかなと思います。これはAdvent Calendarにかぎらず、普段のブログでも同じでもいえると思います。
そもそも、短いほうが読者もすぐに読めますし…。
というわけで、もっと気軽に、自分の日頃の気づきをアウトプットする場として、来年はブログを使っていきたいです。
一応、ひとりAdvent Calendarということで、始まる前に20日分くらいのネタ(タイトルだけ)は考えたりしていました。
ただ、その当時は「××のことを調べてxxの記事に書くぞ!」と思っていても、時間が経ってしまうと、その熱が冷めていて、結局調べもせず、書きもしないことがあるんですよね…。
なので自分は、書くと決めたらその日に(多少粗くても)書き切って投稿する、というスタイルが合っているように思いました。
ちなみに、日の目を見なかったネタについては、来年どこかで記事にしたいとは思っていますが…。
「反応があると嬉しい」ということは否定しませんが、アクセス数を稼ぐことが目的化してしまうと本末転倒であり、そもそもこのブログ、基本的に検索しかアクセスがないので、「自分のため」と割り切って書くのが長続きするコツかなと思います。
もうちょっと綺麗事を言うと、「将来の自分や誰かの役に立つネタ」を提供したい、というのがブログを書くモチベーションの源泉ですが…。
定量的な回数を決めてしまうと、それ以上書こうという気が薄れるし、逆に目標が高すぎてもモチベーションが下がるし、目標を決めないほうが性にあっているような気がしました。これは人によるかもしれません。コンスタントに素晴らしい記事を書いている人も世の中にはたくさんいますし。
Dev Hub Trial Orgはトライアル期限が過ぎてしまうと無用の長物になるわけなので、削除したいことがあります。
~/.sfdx
の下にある、 {Dev Hub Orgのユーザ名}.json
を消せばいいみたいです。
あと、~/.sfdx/alias.json
の方も修正する必要もあるかもしれません。
sfdxにも少しずつ慣れていきたいなと思い、色々試してみようとしているところです。
手始めに
$ sfdx help
とヘルプコマンドを打ち、そこで初めて、sfdxはプラグイン機構を備えていることを知りました。
sfdxのカスタムプラグインはどんな感じに作られるのか、試してみました。
https://github.com/tq-jappy/sfdx-hello-plugin
$ sfdx hello:sayHello
と打つと、
Hello sfdx!
とコンソールに出力するだけのものです。
これまで、趣味と実益を兼ねて、RedmineやJenkinsのプラグインの作成(や改修)に関わってきましたが、プラグインの作り方を学ぶには、似たような動作をする既存のプラグインを真似するのが一番の近道だと思っています。
とはいえ、sfdxの場合、まだそんなに数が豊富にあるわけではないので、「そもそもどうやって作ればいいんだろう?」と思って検索したところ、例えば以下のようなリポジトリが見つかりました。
あと、作者の方の紹介記事もありました。
これらを踏まえて、作りました。
基本的には、sfdxのプラグインは普通のNode.js開発の要領で作っていけばよいみたいですね。
エントリポイント(メイン) である index.js
の中で、 topics
, namespace
, commands
をそれぞれ exports してあげるのがルールなようです。
ただ、コマンド体系が複雑でなければ、namespaceは省略してもよいみたいです。プラグインの作法としてはさておき、動作上は問題ありませんでした。
コマンドのロジックは以下のコードです。 context
の中には認証情報なども含まれていそうなので、うまく駆使すれば色んな用途を満たすプラグインが作れるんじゃないかなと。
(function() { 'use strict'; module.exports = { topic: 'hello', command: 'sayHello', description: 'display hello message', run(context) { console.log('Hello sfdx!'); } } }());
JavaScriptで作成することから、jsforce(やその他のJS系のSalesforceライブラリ)と組み合わせるとよさそうですね。
今のプロジェクトでは、sfdxは実戦投入できていないものの、Jenkins, jsforce, gulp, jsforce-metadata-toolsを使ったCIを組んでおり、その中でApexのテスト結果をJenkinsのJunit/Coberturaレポート形式に出力する、みたいなこともしているのですが、そういう部分をsfdxのプラグイン化することで、sfdxへの移行も緩やかにしていけそうな気がしました。
昨日のエントリで検討した通り、シンプルな画面を新規開発する場合においては、Lightning基本コンポーネントを極力使って開発する、というのも、今後は一つの選択肢なんじゃないかなーという仮説を立ててみました。
Lightning基本コンポーネントについては、以下に書かれています。
しかし、実際に開発する場合、上記ドキュメント(リファレンス)を参照しながら、ということになると思うのですが、案外しんどいことに気づきます。
それはなぜかというと、ドキュメントがテキストのみであり、結果としてどういうUIになるか、仕上がりのプレビューがないことに起因します。
そのため、ちゃんとしたものを作ろうとすると、開発者ガイド、SLDSのドキュメント、場合によってはちょんプロを作ったりと、試行錯誤して作っていくことになりそうだなと予想しています。
(と、思っているんですけど、皆さんどうしているんでしょうね…?)
というわけで、本題です。
開発のハードルを下げるためには、「ライブエディタ(リアルタイムプレビュー)とかあったらいいんじゃない?」と思い立ち、空き時間を利用して作り始めてみました。
まぁ、車輪の再発明の気もしなくもないですが、練習も兼ねてなのでいいかなと。
作ってる画面の例として、lightning:layout
の場合は、以下のようなものです*1。
このライブエディタ自体も、極力Lightning基本コンポーネントを使って開発するように、意識しています。
動きとしては、コンポーネントの属性値 horizontalAlign
などを入力パラメータとして受け取って、その度にコントローラ側で $A.createComponents
でコンポーネントを再作成し、PreviewとCodeに反映しています。
実際に動かしてみると、 horizontalAlign
属性には center, space, spread, endの4つのオプションがあるわけですが、それぞれのオプションで配置にどのような違いがあるのかも一目瞭然で、なかなか便利そうな気がしています。
まだまだ作りが荒いですが、モチベを保つ意味で紹介してみました。 sfdxでCI/CDをやりつつ、年内くらいには形になるといいな…。
*1:PreviewとCodeで数字がズレているのはバグですね…