Index
Links
Glossary
Index
Key Concepts
Data Residency Option(DRO)
個人情報など重要なデータはオンプレミスのデータセンターに置いたままで、 Database.comを利用可能にする機能。 重要な情報は組織外への持ち出しを禁止する、 というセキュリティポリシーを持つ企業や政府機関でも、 それに対応しつつクラウドデータベースを利用可能にする。 DROの提供は2012年の前半を予定。
Collaborative Application
異なる場所にいる複数のユーザがデータとサービスを共有するようなアプリケーションのこと
Object
データを保存しておく場所。
データベースでいう「エンティティ」「テーブル」にあたる。
ただし、単なるデータ集合ではなく、オブジェクト指向におけるオブジェクトのように、
機能が自動的に組み込まれている。
(UI、セキュリティ、共有モデル、ワークフローなど)
従来用語からすると「インスタンスを永続化可能なクラス」というほうが近いかもしれない。
オブジェクトの特定の「インスタンス」が「レコード」となる。
ビルトインで用意されている「標準オブジェクト(standard>objects)」と、
自分で作成する「カスタムオブジェクト(custom>objects)」の2種類がある。
Basic vocaburaly
field dependencies
Field dependencies are filters that allow us to change the contents of a picklist based on thevalue of another field.
For example, rather than displaying every value for Country in a single picklist, we can limit the values that are displayed based on a value for another field, like Continent. That way our users can find the appropriate country more quickly and easily.
Dependent field need the controlling field.
A controlling field controls the available values in one or more corresponding dependent fields. A dependent field displays values based on the value selected in its corresponding controlling field.
In the previous example,the Continent picklist is the controlling field, while the Country picklist is the dependent field.
Overview
License
- Editionが複数ある。
- Developer Edition
- 開発者向け環境。
- 無期限で利用できる。
- <制限>容量が20メガバイトまで
- <制限>利用可能なユーザー数に制限あり
- <制限>構築した利用環境を有料環境に移行できない
- ※ただし、作成したアプリケーションは、設定情報をパッケージングし、他の環境に展開できる。
Design Concept
- DOAが基本
Advantage of Salesforce.com
- データに対する細かなアクセス制御
セキュリティおよび共有モデルでは、 さまざまなデータに対するユーザのアクセスを細かく制御することができます。
- イベント駆動型のワークフローを組める
ワークフローにルールを定めることで、 新しいレコードの作成やレコード項目の値の変更などといった特定のビジネスイベントが発生した場合に、 自動的に、タスクを割り当てたり、データを更新したり、電子メールアラートを送ったりすることができます。 承認手続きを設定することで、各段階で決済すべき人など、 レコードを承認するために必要な手順を定めることができます。
Key Technology
Multi Tenancy
すべてのユーザ、すべてのアプリケーションが ある1つのインフラストラクチャとコードベースを共用するアプリケーションモデル。
Metadata-Driven App Development Model (Apex Builder)
コード不要の「blueprints(青写真)」を記述することで アプリケーションの定義が可能なアプリケーション開発モデル。 データモデル、オブジェクト、フォーム、ワークフローなどは、メタデータで記述されます。
Force.com Web Services API(Apex API)
Web サービスを定義するアプリケーションプログラミングインターフェイス。 事実上すべてのプログラミング言語、プラットフォームから Force.com 上のすべてのデータに直接アクセスすることができます。
AppExchange Directory
Salesforce のユーザであれば、数百件の AppExchange アプリケーションを参照 / 試用したり、 コメントを寄せたり、インストールしたりできる Web サイト。 作成したアプリケーションをAppExchange サイトに掲載し、コミュニティで共有することができます。
App Development
Index
Create new app
- AppSetup -> Create -> Apps => "New" button
Information Resource
Overview
- [-] JP:An Introduction to Environments - developer.force.com
- [-] An Introduction to Environments - developer.force.com
Trend
- [*] 2011-09-28:セールスフォース・ドットコムが新アプリ「do.com」の提供を予告。プロジェクト管理アプリケーションか? - Publickey
- [*] 2011-09-05:「スティーブ・ジョブズ氏の功績とモバイルファースト」 エリック・シュミット氏とマーク・ベニオフ氏の対談(後編) - Publickey
- [*] 2011-09-05:「ワールドクラスのソフトウェア会社になる方法」 エリック・シュミット氏とマーク・ベニオフ氏の対談(前編) - Publickey
- [*] 2011-09-02:[速報]ソーシャル、モバイル、オープンに対応するセールスフォース・ドットコムの「次世代アプリケーションプラットフォーム」。Dreamforce'11 - Publickey
- [*] 2011-09-02:セールスフォースのクラウドデータベース「Database.com」が正式サービス開始。無料で10万件まで利用可能、セキュリティポリシー対応機能も開発中。Dreamforce'11 - Publickey
- [*] 2010-04-28:Javaをクラウドに乗せる「VMforce」、セールスフォースとVMwareが共同提供 - Publickey
Evaluation Article
Architecture
Multi Tenant Architecture
- [-] 知られざる「マルチテナントアーキテクチャ」(1)~SaaSはみんな同じではない? - Publickey
- [-] 知られざる「マルチテナントアーキテクチャ」(2)~スケーラビリティのカギは組織ID - Publickey
- [-] 知られざる「マルチテナントアーキテクチャ」(3)~スキーマとメタデータの謎 - Publickey
Architecture of Salesforce (ACM Symposium on Cloud Computing 2010)
- [-] セールスフォースのアーキテクチャ(物理アーキテクチャ編)~ Podによるスケールアウト - Publickey
- [-] セールスフォースのアーキテクチャ(マルチテナントデータベース編)~ Flex Schemaとオプティマイザ - Publickey
- [-] セールスフォースのアーキテクチャ(シングルコード編)~ セールスフォースの内部コードで見る、過去との互換性をどう保つか - Publickey
- [-]
Tutorial
- [@] Members:Creating On-Demand Apps PDF - developer.force.com
- [@] JP:Creating On-Demand Applications: An Introduction to the Force.com Platform - developer.force.com
Evaluation Draft
- 没メモ
<セールスフォースのコストメリット> ・ノンプログラミングで学習コストも開発コストも安い! ・業務にマッチした
<デメリット?> ・ノンプログラミング部分について逆に足かせにならないのか? (複雑なことをやろうとするとかえって大変=コスト高) ・覚えるべきスキルが分散されることによるデメリット -エンジニアのスキルポータビリティの低下 -ノウハウの分散 ・楽天全体のエンタープライズアーキテクチャレベルで見た時の 統一性のないヘテロアーキテクチャの加速 →特に、Salesforceではデータベースのマルチテナントアーキテクチャを 大きなウリとしているが、 業務系全体をすべてセールスフォースに移管しないことには、 このメリットを享受することはできないのでは? 個別のシステムに対してのみ導入するのであれば、 業務系システムのプラットフォームとしてのメリットは 一つ大きく減るのではと思います。
■広範なセールスフォースの概要を圧縮して説明できるようになる
■調査が終わった後に、我々がセールスフォースについての照会や問い合わせに 対応できるようになる
■実際の開発にあたって現場エンジニアがハマりがちなクセのある部分のノウハ ウをためておく
■セールスフォースの特性が、楽天での業務システム開発/運用にマッチするの かの適合性を検証する
■セールスフォースの技術特性を簡便に整理しレポートする。 他クラウドサービスとの比較での得意分野/不得意分野を明確にする。
■セールスフォースの技術アーキテクチャを評価する。 陳腐化するリスクはないのか、将来性はあるのか、親和性はどうか、等々。 -バージョンアップ時の下位互換性は担保されるのか? どこかで打ち切られるリスクはないのか? -データ漏洩をブロックするセキュリティアーキテクチャは? -アベイラビリティの担保は具体的にどのようにして実現されているのか? -どのような思想で作られているのか? 既存アーキテクチャに慣れ親しんだエンジニアにとって、 ハードルは高いものなのか? またつまづきそうなギャップはどこにあるのか?
■公称スペックには載らないような、技術的な弱点を実地検証する。
技術的な評価に徹するにしても、
■開発現場にとって開発環境としての手軽さを考えるのか、 (いちいちSYSに依頼しなくても自分たちですぐに開発環境を立ち上げられる… →という用途であれば、force.developperを扱うよりも、 Heroku、VMforceの方がマッチするでしょうし、 調査の主眼もそちらにするべきでは。 ですし、開発環境であれば、プライベートクラウドのほうが、 データもサーバも外に出す必要なく、こちらに軍配があがる?!
■業務システムの素早い構築 →であれば、ノンプログラミングでの構築が主眼になるでしょうし、
社内外に協力を求める場面も増えるでしょうし、 その際にも「こういう趣旨でいま動いています」と説明できるような、 明文化された資料が必要なのではと思います。