Salesforceの記事のインポート機能を利用したKnowledgeのインポートにおける注意点

はじめまして、タンバリンのエンジニアの菊地と申します。

はじめに

記事のインポート機能とは以下の画面からCSVファイルとプロパティファイルを作成し圧縮したzipファイルをアップロードすることでSalesforceのKnowledgeをインポートできる機能である。 f:id:hk_tb:20200831160338p:plain f:id:hk_tb:20200831160454p:plain 上記の記事のインポート機能を利用した場合に項目エラー以外で正しく取り込めないケースが存在する。

インポート時にエラーになった場合に調査すること

  1. CSVファイルの圧縮方法の確認
  2. CSVファイルの文字コードと日付フォーマットの確認
  3. データカテゴリの入力方法の確認

調査内容詳細

  1. CSVファイルの圧縮方法の確認
    CSVファイルは、フォルダを圧縮するのではなく、CSVファイルとプロパティファイルを選択して圧縮する

    • 誤った例 f:id:hk_tb:20200831160905p:plain
    • 正しい例 f:id:hk_tb:20200831161207p:plain
  2. CSVファイルの文字コードと日付フォーマットの確認

    • CSVファイルに使用する文字コードはプロパティファイルで指定している文字コードと一致している必要がある f:id:hk_tb:20200831161520p:plain
    • 日付フォーマットはプロパティファイルで指定していない場合は、「yyyy-MM-dd」形式で入力する
    • 特にExcelでファイルを修正している場合は、文字コード、日付形式共に自動で変換される可能性があるため注意が必要
  3. データカテゴリの入力方法
    カテゴリグループの一意の名前をCSVファイルのヘッダーに指定し、その配下にあるカテゴリを+で結合する

    • 以下のようにデータカテゴリグループ及びデータカテゴリが設定されている場合 f:id:hk_tb:20200831162340p:plain f:id:hk_tb:20200831162353p:plain f:id:hk_tb:20200831162406p:plain
      上記の場合、CSVへの記載方法は以下となる

      …,Demo,…
      …,X1,…
      …,X1+Y1,…
      

単体テスト(フロント寄り)の分類をしてみる

ご挨拶

タンバリンの佐藤と申します。

ここ最近はプロジェクトでテストケース作成と打鍵を担当しているので、 整理がてら単体テストの分類をまとめてみようと思います。

なお、ここでいう単体テストは「フロント(画面)寄りの単体テスト」になります。 バックエンド寄りになるとメソッド単位のテストだとかになるので、ご承知おきください。

単体テストの分類

f:id:shota_tmb:20200831140810p:plain

デザインチェック

  • デザイン仕様書をベースとして、パーツの配置がずれていないか、パーツが過不足なくあるかを確認する
  • 観点表(こういったところを確認しますよ表)を作成して、横断的にチェックすることが多い印象。なので、既存のものがあれば流用がしやすい

f:id:shota_tmb:20200831140844p:plain

バリデーションチェック

  • 「チェックロジックがあり、エラー判定を返す」機能が対象
  • チェック対象が1項目だけの「単項目チェック」と、チェック項目が複数の「相関チェック」がある。相関チェックはテストパターンが多くなるため、注意が必要
  • また、複数のチェックが同一項目にかかる場合は、チェック順序も確認する必要がある
  • テストパターンが多くなる&改修頻度が多いため、自動テスト化することが多い

ロジックチェック

  • 「操作(多くはクリック)することで画面上になんらかの動きが発生する」機能が対象
  • 具体的には「画面遷移」「モーダルウィンドウ表示」「アンカーリンク」「パスワードの表示・非表示」など

以上です。

Laravelで二重登録を阻止する3つの方法

ご挨拶

タンバリンの若林と申します。

データをPOSTする際、何らかの不具合でデータベースに同じデータが複数登録されてしまう…そんな過ちを最近犯してしまったので、この記事で懺悔します。

前提

  • 言語:PHP
  • FW:Laravelの6系
  • lib:jQuery
  • 次のプロセスを想定:入力画面 → 確認画面 → 完了画面

1. 送信ボタンの連続クリックを阻止

確認画面 → 完了画面 の順に遷移する際、送信ボタンを複数回クリックすると、その回数分データが送信されてしまいます。

これは確認画面に下記の処理を書くことで阻止できます。 formからデータを送信時、送信ボタンを非活性にしてるんですね。

【View】

<script>
    $(function () {
        $('form').submit(function () {
            $(this).find(':submit').prop('disabled', 'true');
        });
    });
</script>

2. ブラウザバックによる再度送信を阻止

完了画面 → 確認画面 の順にブラウザバック後、 確認画面 → 完了画面 の順に遷移する際、再度送信ボタンをクリックすると、また同じデータが送信されてしまいます。

これは完了画面へ遷移する際のメソッドに下記の処理を書くことで阻止できます。 送信後にCSRFトークンを再生成してるんですね。 これでブラウザバック後に再度送信しても元々のトークンと値が違うため、419のエラーが出てきて送信ができなくなります。

【Controller】

$hoge->createUser($request) // テキトーに登録系の処理
$request->session()->regenerateToken(); // これを書く。トークンを再生成
return view('complete');

3. 完了画面のリロードによる再度送信を阻止

確認画面 → 完了画面 の順に遷移後、完了画面のまま画面をリロードすると、また同じデータが送信されてしまいます。ブラウザのリロードは直前のリクエストを再度実行することができるので、直前に登録系の処理があった場合は二重登録の原因になります。

これは完了画面へ遷移する際に別のメソッドを挟む下記の処理を書くことで阻止できます。 登録系の処理完了画面を見せる処理 の2つに分けてるんですね。 これで完了画面をいくらリロードしようが、直前のリクエストは画面を見せるだけなので問題ありません。

【Controller】

public function register(Request $request)
{
    $hoge->createUser($request) // テキトーに登録系の処理
    return redirect()->route('complete'); // web.phpでルーティングを定義しておく
}

public function complete()
{
    return view('workshop.complete'); // 完了画面を見せるだけの処理
}

以上になります。 いかがでしたでしょうか。割と簡単にできる再現性の高い内容かと思います。 皆様の開発業務に貢献できていましたら幸いです。

参考文献

https://qiita.com/syobochim/items/120109315f671918f28d https://www.bnote.net/blog/laravel_double_submit.html

二段階認証設定をしたSalesforceと連携したTeamSpiritで起こっていたバグの解消

こんにちは。 タンバリンのクラウドアプリケーションディレクターの中川です。

弊社はTeamSpiritを使って勤怠打刻や経費精算を行っています。 社内のSalesforceと連携させているのですが、どうやら設定している二段階認証と相性が悪いようで、 スマートフォンから勤怠打刻ができなくなってしまっていました。

二段階認証のレベルは下げず、スマートフォンからも打刻できるようにする方法を記事にします。

前提

  • Salesforce側の二段階認証をプロファイルで ログインに必要なセッションセキュリティレベル が [高保証] に設定 としていました
  • 二段階認証のレベルは下げずにスマートフォンからも打刻できるようにしたい、という要望です
  • SalesforceのappexchangeでTeamspiritを使っています。 以下参照

appexchangejp.salesforce.com

方法

スマートフォンで打刻できなかったのはTeamSpirit側との相性の問題で、 プロファイルで ログインに必要なセッションセキュリティレベル が [高保証] に設定 として二段階認証を設定していると出るエラーのようでした。

プロファイルで ログインに必要なセッションセキュリティレベル が [高保証] に設定 となっているこれを外します。 更に、同じくプロファイルで ユーザインターフェースログインの 2 要素認証 をチェックした上で API ログインの 2 要素認証 にもチェックつけることで二段階認証を保ちつつアプリで打刻できるようにしています。


ちなみに…… デフォルトで作成されたシステム管理者プロファイルだとユーザインターフェースログインAPIログインのチェックが触れなかったので、シス管プロファイルのみコピーして設定しなおし、ユーザを当て直したりしました。

以上です。 みなさんも良き二段階認証ライフをお過ごしください。

GoogleスプレッドシートにSalesforceレコードを出力してみた

タンバリンのイノウエです。

管理者だけが閲覧出来るデータがあって、チーム内でだけは権限がなくても共有してあげたい。

でも権限申請は面倒だし、ライセンスの追加購入も難しい...そんな時に、きっと役立ちます。

事前準備

以下、Chromeで行います。

アドオンをインストールする

https://gsuite.google.com/marketplace/app/data_connector_for_salesforce/857627895310

Googleスプレッドシートで新規シートを開く

f:id:Kinoue_tambourine:20200501150457p:plain

データの出力手順

いよいよ本題です。

1.アドオンを有効化する

メニューの「アドオン」から、以下の順でクリックしてください。

「Data connector for Salesforce」→「Click to enable the add-on」

f:id:Kinoue_tambourine:20200501150548p:plain

2.アドオンを開く

再度メニューの「アドオン」から、以下の順でクリックしてください。

「Data connector for Salesforce」→「Open」

f:id:Kinoue_tambourine:20200501150752p:plain

3.Salesforce認証を行う

アドオンを開くと下図右部のような小窓が開きますので、「AUTHORIZE」をクリックしてください。

f:id:Kinoue_tambourine:20200501150823p:plain

別ウィンドウで認証画面が開きますので、ログインしたのちアクセスを許可してください。

f:id:Kinoue_tambourine:20200501150904p:plain

f:id:Kinoue_tambourine:20200501150939p:plain

下記画面に遷移すれば認証完了です。認証画面は閉じても大丈夫です。

f:id:Kinoue_tambourine:20200501151007p:plain

注意事項

このとき表示されるログイン画面はブラウザで持っているセッションに依存します。

データを出力したい環境にログインしようとしていない可能性がありますので、ウィンドウのURLをよく確認してください。

例)お客様環境で作業した直後などはその環境のログイン画面が表示されます。

4.データの出力を行う

アドオンのメニューから「Import」を選択します。

f:id:Kinoue_tambourine:20200501151128p:plain

出力するオブジェクトを選択して「NEXT」をクリックします。 f:id:Kinoue_tambourine:20200501151604p:plain

出力するフィールドを選択して「NEXT」をクリックします。 f:id:Kinoue_tambourine:20200501151633p:plain

必要に応じてフィルターを設定します。条件を指定して「ADD」をクリックします。 f:id:Kinoue_tambourine:20200501151708p:plain

スクロールして出力行数を指定したら「GET DATA」をクリックします。 f:id:Kinoue_tambourine:20200501151730p:plain

実行確認画面が表示されますので「REPLACE」をクリックします。 f:id:Kinoue_tambourine:20200501151755p:plain

出力完了です! f:id:Kinoue_tambourine:20200501151903p:plain

注意事項

・出力に際しては、認証時に使用したアカウントの持つ権限が参照されます。Salesforce上で閲覧権限が無いものについては出力出来ませんのでご注意ください。

・他の人に出力ファイルを共有する場合は閲覧者権限を付与してください。編集者権限を付与すると、出力者の権限でアドオンを使用出来てしまうことを確認しています。

参考文献

base.terrasky.co.jp ※上記サイトには本記事では紹介していない他の機能についても解説されています。

ふりかえり手法の紹介:YWT

タンバリンの髙橋です。ふりかえりのYWT(わいだぶりゅーてぃー)というフレームワークをご紹介します。

YWTとは何か?

日本能率協会コンサルティングが提唱したふりかえりのフレームワークです。 YWTは以下の頭を取った略称です。覚えやすいですね。

- Y:やったこと
- W:わかったこと
- T:次にやること

実施の事前準備

  • 道具を用意する:付箋、サインペン、模造紙またはホワイトボード、タイマー
    • オンライン実施の場合は、使用ツールの事前動作確認必須。
    • trelloやJamboard、miro、DropboxPaper、スプレッドシートなどお好みで。
    • グラフィカルにやりたいか、議事録で二次利用したいか等を判断材料に。
  • ふりかえりのテーマを募集する
  • 参加者の招待、時間・場所の確保

  • タイムスケジュールを決める  

    • 60分ふりかえり時の時間配分目安です。オーバーするのでざっくりでOK

      1. . 話し合うテーマ、グランドルールに同意する(5分)
      2. やったことを付箋紙に書く(個人作業:5分)
      3. やったことを共有する(チーム作業:7分) 
      4. わかったことを付箋紙に書く(個人作業:5分)
      5. わかったことを共有する(チーム作業:7分)
      6. 次にやることを付箋紙に書く(個人作業:5分)
      7. 次にやることを共有する(チーム作業:7分)
      8. アクションに落とし込み合意する(チーム作業:5分)
      9. 全体のふりかえり

()内注記 - 個人作業:個人でもくもく作業 - チーム作業:参加者に対してシェアしたり、みんなでやる作業

実施

1. 話し合うテーマ、グランドルールに同意する(5分)

  • 問題対わたしたち、反省会ではない、一人ひとりの意見を尊重、他、ふりかえりにおけるお約束事を周知します。
  • 上司と部下の関係や、仲違いメンバーがいても、全員が課題と向き合う場と認識してもらいます。
  • 話し合うテーマについて詳細化が必要かどうか、このテーマでOKか、参加者の合意を得ます。

    2. やったことを付箋紙に書く(個人作業:5分)

  • 付箋やtrelloのカードに、テーマに沿って実施したことを個人作業でもくもくと記入をしてもらいます。
  • 良いこともネガティブなことも、事実を書いてもらいます。

    3. やったことを共有する(チーム作業:7分) 

  • 書いた内容を参加者に分かるよう、共有してもらいます。
  • この時、一人30秒以内におさまるように、とアナウンスしてください。
  • 7分以上になっても、皆の書いた付箋はさらっと全体触れられるようにしましょう。

    4. わかったことを付箋紙に書く(個人作業:5分)

  • やったことを踏まえ、良いこともネガティブなことでも、気づきを書いてもらいます。

    5. わかったことを共有する(チーム作業:7分)

  • やったことを共有する、と同様に実施。
  • 他の人へ感謝ポイントがあったら「ありがとう」を伝えましょう。

    6. 次にやることを付箋紙に書く(個人作業:5分)

  • わかったことを踏まえ、次にやることを書きます。
  • やったこと、わかったことに関連しなくても、挑戦・試したいことでもOKです。

    7. 次にやることを共有する(チーム作業:7分)

  • やったことを共有する、わかったことを共有する、と同様に実施。

    8. アクションに落とし込み合意する(チーム作業:5分)

  • 次にやることで出てきた内容を「効果的」「すぐできる」で振り分けて、優先度が高いものから実施できるか、具体的にはどうするかを考えます。
  • BacklogタスクやToDoリストまで記載できると良いです。

    9. 全体のふりかえり

  • 実施した後、参加者の皆さんからフィードバックをもらい、次のふりかえり実施の時の参考にします。
  • 時間が足りなければ、別途フィードバックもらうようにしてください。

既視感ありませんか…?

日報や進捗会議で「やったこと」「次にやること」は報告されていると思います。 ここに「わかったこと」を挟むことで、ミニマムにふりかえりすることができます。

「次にやること」が次のふりかえりで「やったこと」になり、 「わかったこと」で気づいたことを考え「次にやること」がどんどんブラッシュアップされていくイメージです。

(参考)KPT(KPTA)とYWTはどう違うの?

「思い出し」行為

ふりかえりでは、過去の行動を「思い出し」してから分析することが重要になります。 YWTは最初に、やったことを挙げていくので、これが思い出しに当たります。

KPTA(けぷた)では、まず最初に「思い出し」をした後にKeepを挙げるルールがありますが、 「思い出し」をしないまま、いきなりKeepを挙げてしまい、うまく使えない印象を抱く人もいるようです。

向き不向き

KPTAとYWT使い方はほぼ一緒、ではありますが、大きいカテゴリとしてこんな感じかと。

KPTA:業務の内容や目標、カイゼンポイントをふりかえる YWT:経験や学びをふりかえる

また、KPTAのProblem(問題)ありき前提で会話するのを避けたい場合、 あえてYWTのふりかえりを挟むことがあります(メンバーが疲弊しきってるプロジェクトとか)

個人的には、お試しで初回はYWT、2回目以降KPTAの実施をやってみることをお勧めします。

参考リンク

これだけ!KPT(書籍)

KPTとYWTの違いは?

Analytics Cloud External Data APIをPHP/Forrestで試してみた。

どうも、エンジニアの守屋です。

今回はPHP/Forrestを使って「Analytics Cloud」にCSVファイルをアップロードしてみます。

※Forrestとは、PHPでSalesforce/REST APIを便利に扱えるライブラリ。 github.com

今回の記事では認証系は省略します。



【アップロード全体の流れ】

  • InsightsExternalDataにデータ形式情報をセット
  • InsightsExternalDataPartにCSVファイルをアップロード
  • アップロードしたデータの取り込み処理を実行
続きを読む