ncdc-API20200623

2020/06/23 弊社主催のウェブセミナー資料です。
-------------------------------
【概要】
近年、API（Application Programming Interface）の活用が注目を集めています。
この背景には、さまざまな技術の発展とWebAPIを無償公開するサービスの増加により、APIが容易に導入できて、多くのメリットが得られるものとして進化し続けてきたことが挙げられます。

「API利用＝開発の効率化・開発コストの削減」というイメージされる方が多いと思いますが、具体的にはどの分野で使われてどう効果を上げているのか、API活用の最新事例を知る機会は多くないかもしれません。
そこで、このセミナーでは、マネージャー層向けに他社の事例などを踏まえたAPI活用のヒントをお伝えします。

また、最近は、マイクロサービスアーキテクチャの台頭により、旧来のモノリシックなシステムをWeb APIを活用したマイクロサービスにリプレイスするケースも増えています。
この応用で、レガシーシステムからの脱却を図る際に一からシステムを作り直すことなく、API連携によって段階的な改善を図るという手法もあります。

そのため、API は先進的なIT企業だけでなく、社内にレガシーシステムを抱えてDXが思うように進められない大手企業からも注目されています。

こうしたマイクロサービスアーキテクチャや、レガシーシステムとAPI連携するシステムを設計する際に注意すべきポイントと、実装に必要な知識・スキルについても、セミナー内で解説します。

Transcript

1. マネージャー層向け
   API活用セミナー
   最新の事例とDXへの応用手法を知る
   2020/06/23
   NCDC株式会社
   十川 亮平
   

   View Slide

2. 取締役/CTO
   十川亮平
   プレゼンター紹介
   NCDCでは、モバイル、API、IoT、機械学習など
   を使った新規サービスの企画立案や、プロジェ
   クト推進の支援を担当。
   Webサービス／モバイルアプリのバックエンド
   プラットフォームである「AppPot」のプロダク
   トマネージャーとして、マーケティング活動や
   APIの開発を行っている。
   

   View Slide

3. NCDCのサービス
   l CX/UXと先端テクノロジーによってデジタルイノベーションを推進します
   3
   NCDC
   CX/UX
   デザイン
   先端
   テクノロジー
   自社
   サービス
   • 新規サービス企画
   • CX/UXデザインコンサルティング
   • IoT/AI
   • クラウドインテグレーション
   • モバイル・Web先端技術
   • モバイルプラットフォーム
   [AppPot]の製造・販売
   • IoTプラットフォーム
   • [AppPot IoT]の製造・販売
   

   View Slide

4. NCDCのサービスの特徴
   l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで
   システムを構築します
   4
   ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション
   ITアーキテクチャのデザイン リファレンス実装
   DX推進のための組織デザイン
   

   View Slide

5. 今日お伝えしたいこと
   l Why API
   l API周辺のテクノロジー
   l APIの設計、考慮すべきこと
   l APIを活用した事例
   l NCDCのアーキテクチャ・コンサルティングサービス
   l バックエンドサービスAppPot
   5
   

   View Slide

6. Why API
   ・APIのメリット
   ・マイクロサービス
   ・ SPA
   

   View Slide

7. APIとは
   l APIとは外部からアプリケーションの機能を呼び出すためのインターフェイス
   l OSがプログラムに提供するAPI、モジュール（部品）を呼び出すためのAPIな
   ど様々ありますが、本セッションでは
   「主にWebサービスを用いて外部から機能を利用するAPI」
   についてお話させていただきます。
   顧客向け
   フロントエンド
   管理向け
   フロントエンド
   社内の
   他システム
   他社の
   他システム
   API
   データベース
   7
   

   View Slide

8. APIとは
   l APIに含まれるものは主に次の通りです
   8
   顧客向け
   フロントエンド
   管理向け
   フロントエンド
   社内の
   他システム
   他社の
   他システム
   API
   データベース
   データモデル
   エンドポイント
   （呼び出し先）
   呼び出し方
   

   View Slide

9. APIがあると何が嬉しいの？
   l APIで公開された機能は、さまざまな場所から利用できる
   9
   ②APIを境界に
   関心を分離できる
   データやロジックを担
   当するAPIはそのままで、
   画面側だけを独立して
   変更、配信できる。
   ①再利用性
   いろいろのなクラ
   イアントから呼び
   出すことができる
   ③自動化
   APIがあると
   プログラムを
   使って自動化でき
   る
   RPAで人手の作業を
   自動化していますが、
   本来はAPIが提供さ
   れていればシステム
   同士が連携できる
   

   View Slide

10. API活用例① マイクロサービス
    10
    モノリシック
    （一枚岩）な
    システム
    マイ
    クロ
    サー
    ビス
    様々な機能を１つのシステ
    ムで実現。
    各機能やデータは密に連携
    しているため、システム改
    修時に影響範囲が大きく、
    変更に時間がかかる
    マイ
    クロ
    サー
    ビス
    マイ
    クロ
    サー
    ビス
    機能の塊で、システムを分割。
    各マイクロサービスは独立性を
    保ち、他サービスと連携しなが
    ら全体の機能を提供するという
    考え方
    Ex)ECサイトで商品、買い物かご、
    決済、顧客管理を別のサービス
    として構築。
    マイクロサービスとは
    

    View Slide

11. マイクロサービスと技術レイヤー
    11
    商品
    買い物
    かご
    決済 会計
    フロントエンド
    バックエンド
    （API）
    データベース
    技術
    レイヤー
    どのような単位で
    マイクロサービスに分けるか
    

    View Slide

12. システムの特性に合わせて、採用する技術を組み合わせることが容易になってきている
    12
    商品 買い物
    かご
    外部の
    決済
    サービ
    ス
    既存の
    会計
    システ
    ム
    フロントエンド
    バックエンド
    （API）
    データベース
    技術
    レイヤー
    どのような単位で
    マイクロサービスに分けるか
    MySQL NoSQL
    DB
    Node.js Java
    顧客向けフロントエンド
    

    View Slide

13. システムの特性に合わせて、採用する技術を組み合わせることが容易になってきている
    13
    商品 買い物
    かご
    外部の
    決済
    サービ
    ス
    既存の
    会計
    システ
    ム
    フロントエンド
    バックエンド
    （API）
    データベース
    技術
    レイヤー
    どのような単位で
    マイクロサービスに分けるか
    MySQL NoSQL
    DB
    Node.js Java
    API連携
    API連携
    顧客向けフロントエンド
    API連携
    API連携
    なぜこのようなことができるかというと、APIを介した連携だから。
    APIというインターフェイスが変わらなけれは、
    連携先の言語、実行基盤、実態がどこにあるのかが変わっても影響を受けない
    

    View Slide

14. API活用例② 企業間/社内間システム連携
    14
    設計 製造 施工管理 運用
    A工程
    施工
    B工程
    施工
    設計事務所 工場 元請けゼネコン 建物運用
    施工会社A 施工会社B
    独自
    システム
    独自
    システム
    独自
    システム
    Excel
    Excel 独自
    システム
    独自
    システム
    紙 紙
    Excel
    例えば建設業の例では
    

    View Slide

15. API活用例② 企業間/社内間システム連携
    15
    設計 製造 施工管理 運用
    A工程
    施工
    B工程
    施工
    設計事務所 工場 元請けゼネコン 建物運用
    施工会社A 施工会社B
    独自
    システム
    独自
    システム
    独自
    システム
    Excel
    独自
    システム
    独自
    システム API API データ
    連携
    API RPA
    APIを利用することでシステム間のデータのやりとりが、
    自動化でき、リアルタイム性、正確さが向上します。
    ※すべてをAPI化する必要はありません。
    リアルタイム性が必要ない部分はデータ
    連携を使用したり、システム化の費用対
    効果がでない部分はRPAを組み合わせる
    なども考えられます。
    

    View Slide

16. APIの活用例③ UXが重視されており、顧客向けのUIを高速に改善したい
    16
    顧客向け
    フロントエンド
    API
    データベース
    データモデル、機能は
    比較的あまり変わらない
    UX/UIはどんどん
    改善していく
    APIを境界にフロントエンド（画面）とバックエンド（機能・データ）が
    分離され、それぞれが独立して改善、リリースできる
    

    View Slide

17. とはいえ、APIの管理について気をつける点がいくつかあります
    17
    顧客向け
    フロントエンド
    管理向け
    フロントエンド
    社内の
    他システム
    悪意のある
    クライアント
    API
    データベース
    APIの
    セキュリティ
    APIの
    仕様の公開
    どういう
    設計が良いの？
    どんな技術で
    作るのか？
    

    View Slide

18. API周辺のテクノロジー
    ・SOAPからRESTへ
    ・開発言語のサポート
    ・コンテナ
    ・サーバレス
    ・APIドキュメント
    

    View Slide

19. 一昔前からのAPI周辺技術の進化
    l 一昔前はWeb APIと言えばSOAPというプロトコルでした
    l WSDL（XML）でインターフェイスを定義
    l WS-*などの複雑な仕様
    l サポートする言語、ミドルウェアが限定的
    l 現在はRESTが一般的
    l シンプルな仕様
    l HTTPの仕様に合わせており、さまざまな言語で扱いやすい
    l URL
    l HTTPメソッド
    l 応答コード、など
    19
    

    View Slide

20. 様々な開発言語で簡単にAPI化することができます
    l Java + JAX-RS
    アノテーションでURLのパスや
    HTTPメソッドを指定することでWeb
    サービスを定義できる。
    特別なClassの継承や、XMLを書く必要は
    ない。
    20
    import javax.ws.rs.GET;
    import javax.ws.rs.Produces;
    import javax.ws.rs.Path;
    @Path("/helloworld")
    public class HelloWorldResource {
    @GET
    @Produces("text/plain")
    public String getClichedMessage() {
    // Return some cliched textual content
    return "Hello World";
    }
    }
    l Node.js + Express
    JavaScriptで簡単にWebサービスを書け
    る
    const express = require('express')
    const app = express()
    app.get('/helloworld ', (req, res) => res.send('Hello
    World!'))
    app.listen(3000, () => console.log('Example app
    listening on port 3000!'))
    API化が楽というだけで、
    APIそのものの開発が楽だとは言ってないです
    

    View Slide

21. APIの実行基盤としてのコンテナ / サーバレス
    l APIはサーバーサイドで実行されるため、何らかの環境が必要
    l 代表的なものとして、以下があげられますが
    本日はコンテナ、サーバレスについてお話します
    21
    コンテナ
    オンプレ
    サーバー
    IaaS サーバレス
    サーバー上にOSをセットアップ
    アプリケーション・サーバー、
    Webサーバーなどのミドルウェアを構築
    開発したアプリケーションをデプロイ
    IaaSの場合は、AWS EC2などを利用し、
    ハードウェアを意識する必要はない。
    主にDockerを使用
    して、物理サー
    バー上に仮想化さ
    れた環境（コンテ
    ナ）の中でアプリ
    ケーションを運用。
    物理サーバー上で
    多くのコンテナを
    動作させることが
    できるため、１つ
    のコンテナを小さ
    く、シンプルにす
    ることができる
    クラウドベンダー
    が提供している仕
    組みをなどを利用
    して、
    開発者はサーバー
    を意識することな
    く、開発、運用す
    ることができる。
    実行した分だけの
    従量課金が多い
    

    View Slide

22. コンテナとは
    l Dockerの仮想化技術がベースとなっている
    l Kubernetes、AWS ECSなどはDockerコンテナを運用するためのもの
    （オートスケール、フェイルオーバー、負荷分散など）
    l 徹底的に自動化ができるようになっている。
    22
    図は下記より引用
    https://www.docker.com/resources/what-container
    

    View Slide

23. コンテナとは
    l Dockerの仮想化技術がベースとなっている
    l Kubernetes、AWS ECSなどはDockerコンテナを運用するためのもの
    （オートスケール、フェイルオーバー、負荷分散など）
    l 徹底的に自動化ができるようになっている。
    23
    図は下記より引用
    https://www.docker.com/resources/what-container
    コンテナの１つとしてAPIが配置される。
    負荷に応じてインスタンスを増やした
    り、障害時に別の環境にフェイルオー
    バーできる
    Dockerが動作する別のホストへ
    コンテナを持っていくことができる
    可搬性
    本番環境→検証環境
    １号機→２号機
    

    View Slide

24. コンテナとは
    l コンテナ環境を構築する際に、１つのコンテナ上に沢山の
    アプリケーションを動かすのではなく、
    １つだけにするのがシンプル
    l 例えばJavaでは、これまではTomcat、JBossなどのアプリケーションサーバー
    上で複数のWebサービスを動かしていましたが、
    コンテナ時代はSpring Bootのような１コンテナ=１アプリケーションで動かす
    ための実行基盤が主流
    24
    図は下記より引用
    https://www.docker.com/resources/what-container
    Java VM
    Guest OS
    Application
    Spring Boot
    

    View Slide

25. サーバレスとはサーバーが無い？
    l 実際には物理的なサーバー上にアプリケーションを配置しますが、
    開発者がサーバーや、実行基盤のようなミドルウェアを意識する
    必要がありません
    l 暗黙的にはこのような処理が行われています
    l 処理の実行回数により課金が行われる
    25
    アプリケーション
    サーバー
    ①処理要求
    ビルド済み
    アプリケーション
    ②サーバー上に
    読み込み
    ③処理の実行
    ④アプリケーションの破棄
    

    View Slide

26. サーバレスとはサーバーが無い？
    l 実際には物理的なサーバー上にアプリケーションを配置しますが、
    開発者がサーバーや、実行基盤のようなミドルウェアを意識する
    必要がありません
    l 暗黙的にはこのような処理が行われています
    l 処理の実行回数により課金が行われる
    26
    アプリケーション
    サーバー
    ①処理要求
    ビルド済み
    アプリケーション
    ②サーバー上に
    読み込み
    ③処理の実行
    ④アプリケーションの破棄
    サーバーなどのハード障害はあり得る。
    しかし、次の処理要求は別の正常な
    サーバーで処理される。
    サーバーの復旧や、フェイルオーバー
    などの仕組みを自分たちで考える必要
    がない
    多少のオーバーヘッドがあります。
    サーバーへの読み込み、アプリケー
    ションの破棄はクラウド側で最適化
    される
    （できるだけ再利用してくれる）
    

    View Slide

27. サーバレスとコンテナの使い分け
    マネージドサービス サーバレス コンテナ IaaS
    機能 • 提供されたもの
    を使う
    • 自前で開発
    • 処理が15分以内
    • コネクションプール
    が使えず、DBは
    RDBMSと相性悪い
    • 自前で開発 • 自前で開発
    アプリフレー
    ムワーク例
    • 使用しない • Serverless Framework • Spring Boot • Spring Boot、
    Spring Framework
    インフラ • クラウドベン
    ダーに任せる
    • クラウドベンダーに
    任せる
    • リクエスト数に応じ
    て使った分だけ課金
    • ハードウェア、仮想
    化環境はクラウドベ
    ンダーに任せる
    • 用意したインスタン
    スに合わせて課金
    • ハードウェアは提供され
    る。
    • OS以上を自前で構築
    • 用意したインスタンスに
    合わせて課金
    運用 • クラウドベン
    ダー
    • 基本、クラウドベン
    ダーに任せる
    • 機能のリリースなど
    は自前
    • コンテナ管理はクラ
    ウドベンダー
    • コンテナイメージ、
    アプリは自前
    • インフラ管理より下のレ
    イヤーはクラウドベン
    ダー
    • OS、アプリは自前
    サービス
    例
    • AWS Cognito
    認証サービス
    • AWS Lambda • ECS（AWS独自）
    • EKS（Kubernetes）
    • EC2
    27
    • 開発しなくて良い／運用コストが下がる
    • 制約は大きい
    やりたいことと提供されるものがあっている場
    合には、非常に効果を発揮する。
    要件とフィットしていれば、使ったほうが良い
    • 自由度が高い
    • 開発、運用の費用は相対的に
    大きい
    

    View Slide

28. 制約はありますが、許容できるならサーバレスがおすすめ
    l 安い！
    l APIが呼び出された量での課金
    のため、特に新規事業、新規
    サービスのような、ローンチ
    時に大量アクセスが無い様な
    APIの場合、すごく安い
    l 運用が楽
    l サーバーの管理が不要
    l 障害時の再起動、フェイル
    オーバーすら不要
    28
    https://aws.amazon.com/jp/lambda/pricing/
    

    View Slide

29. 事例）サーバレスとマネージドサービスをフル活用したアーキテクチャ
    29
    Webアプリ
    コンテンツ
    アプリ向けAPI Lambda
    業務ロジック
    DynamoDB
    添付ファイル
    Cognito
    ユーザー認証
    利用者
    社内システム
    社内システム
    社内向けAPI
    Lambda
    業務ロジック
    マスタ
    データ連携
    バッチによる
    日次データ取り込み
    AWS 自社データセンター
    Cloud
    Front
    S3
    自社営業
    向け配信
    SNS
    Push通知
    

    View Slide

30. 事例）サーバレスとマネージドサービスをフル活用したアーキテクチャ
    30
    Webアプリ
    コンテンツ
    アプリ向けAPI Lambda
    業務ロジック
    DynamoDB
    添付ファイル
    Cognito
    ユーザー認証
    利用者
    社内システム
    社内システム
    社内向けAPI
    Lambda
    業務ロジック
    マスタ
    データ連携
    バッチによる
    日次データ取り込み
    AWS 自社データセンター
    Cloud
    Front
    S3
    自社営業
    向け配信
    SNS
    Push通知
    AWS Lambda
    サーバレスな処理実装
    Cognito
    マネージドな
    認証サービス
    DynamoDB
    スケールアウト可能な
    データベース
    アプリケーションは
    S3とCloudFrontで配信
    

    View Slide

31. もしAPIを広く使ってもらいたいならAPIの使い方の公開はとても重要
    31
    https://api.slack.com/apis https://docs.apppot.jp/
    閉じられた範囲でのAPIの利用であれば、ExcelやWordで記載されたAPI仕様書で問題ないかも知れませんが、
    幅広く使用してもらいたいAPIの場合は、APIの使い方の公開が重要です。
    顧客によっては、APIがあることが選定理由になるかも知れません。
    

    View Slide

32. APIで考慮すべきこと
    ・APIの設計
    ・セキュリティ
    ・APIマネジメント
    ・バージョニング
    

    View Slide

33. APIの開発に必要なスキルセット
    l APIの開発を行うためにはどんなスキルセットを持った
    エンジニアが必要でしょうか？
    l ただし、以下のような内容をキャッチアップする必要があります
    l ベストプラクティスはAPIを使う側も理解
    している（べき？）ので、基本的なルー
    ルは説明しなくても分かってもらえる。
    l 各種ライブラリがサポートしているので、
    作る側、使う側とも楽。
    Web APIのベストプラクティスの理解
    l DDDやオブジェクト指向などの
    設計手法を使って、システムの機能や
    データをモデリングし、
    どのような単位でAPIを作っていくか
    設計する
    APIの粒度や機能の集約の考え方の理解
    基本的には、Java、Node.js、Pythonなどでサーバーサイドの
    プログラミングが書けるエンジニアであれば大丈夫です！
    むしろ、これまでのサーバーサイドエンジニアはWebアプリケーションの
    画面も開発していたことを考えれば、APIになることでよりバックエンドに集中できる
    33
    

    View Slide

34. APIの設計
    34
    商品
    テーブル
    在庫
    テーブル
    入庫などの操作（メソッド）が
    実際にAPIを呼び出す単位。
    どのようにAPIを設計すべきか
    商品
    - 商品マスタ取得API
    Webアプリ
    在庫
    - 入庫API
    - 出庫API
    - 在庫確認API
    モバイル
    アプリ 他システム APIの利用側の要件だけに
    従って作ると似て非なる
    APIが大量にできることに・・・
    

    View Slide

35. APIの設計
    35
    商品
    テーブル
    在庫
    テーブル
    入庫などの操作（メソッド）が
    実際にAPIを呼び出す単位
    どのようにAPIを設計していくか。
    商品
    - 商品マスタ取得API
    Webアプリ
    在庫
    - 入庫API
    - 出庫API
    - 在庫確認API
    モバイル
    アプリ 他システム APIの利用側の要件だけに
    従って作ると似て非なる
    APIが大量にできることに・・・
    在庫、商品などのオブジェクトのデータモデルと、
    そのオブジェクトが持つ操作（メソッド）や、データの項目を定義
    図の例では、このサービスでの在庫というデータの項目を共通的に定義し、
    在庫に対する操作（入庫、出庫、確認など）を洗い出し、それをクライアントに提供するという考え方
    

    View Slide

36. じゃあどうやってオブジェクトを見つけて定義するのか？
    l ドメイン駆動設計（DDD）やオブジェクト指向の手法を使って
    サービス、システムをモデリングするなどが考えられます
    36
    エリック・エヴァンスのドメイン駆動設計
    モデリングの例
    

    View Slide

37. APIのベストプラクティスって何？
    l RESTful （RESTの原則の則っている）であること
    l 使用するリソース（機能やデータなど）をURIで識別できること
    l ステートレスであること
    l 別のリソースへの参照はリンクで表現する
    l HTTPのメソッド
    例えば、営業部の社員一覧を取得する場合は次のようなURLを
    GETメソッドで呼び出します
    https://hostname/company/sales/employees
    同じく、営業部の社員番号1440の社員の情報を取得したければ
    https://hostname/company/sales/employees/1440
    RESTfulを理解しているエンジニアが見れば、APIの仕様を見ると
    機能ややりとりできる情報が想像できます
    37
    

    View Slide

38. APIのセキュリティ
    l APIの呼び出し元が正しいことを確認
    l 次ページ
    l APIのスロットリング
    l スロットリングとは、特定の利用者が大量にAPIを呼び出していたり、悪
    意のあるユーザーの攻撃に対して流量制御をかけます
    l 不正なアクセスの検知
    l リクエストの傾向や、通信内容を見て不正アクセスを検知
    l WAF（Web Application Firewall）の導入を検討
    https://aws.amazon.com/jp/waf/
    l 暗号化
    l HTTPSを使用した通信経路の暗号化
    l APIのネットワーク的なアクセス経路
    l 公開レベルに応じて、ネットワーク的に保護
    38
    

    View Slide

39. APIの呼び出し元が正しいことを確認
    l APIは機能やデータを公開するため、それを誰に
    どこまで使わせるのかは慎重に検討する必要があります
    l APIの呼び出し元の確認には次のようなものがあります
    l IPアドレス
    l 特定のIPアドレスのクライアントから利用できる
    l 通信経路が安全でない場合、IPアドレスのなりすましがあり得る
    l APIキー
    l パスフレーズを知っているクライアントから利用できる
    l 認証済みトークン
    l ユーザーの認証を行った時に発行されるトークンを検証
    l クライアント証明書
    l クライアントに証明書を発行
    39
    

    View Slide

40. APIの運用
    l 今日は時間の制約がありますのでキーワードだけ
    l 処理をトレースできる仕組みの検討
    l 複数のレイヤーをまたがって処理を行いますので、
    どこでエラーが発生したのか、その影響範囲の確認、
    どこで時間で時間がかかっているのか
    を特定するためにリクエストごとに
    ユニークなIDを発行してフロントエンド、API、
    バックエンドの処理ロジックでログに出すような仕組
    み
    l APIのバージョン管理
    l APIはいろいろなところから利用される可能性があり
    ます
    l 将来的にインターフェイスが変更になった場合に、
    多数のクライアントが困らないようにバージョン
    ごとに並行稼動してクライアントがバージョンを
    指定して呼び出し分けることができるような仕組み
    40
    顧客向け
    フロントエンド
    管理向け
    フロントエンド
    API
    データベース
    

    View Slide

41. NCDCのAPIに関するサービス・プロダクト
    

    View Slide

42. NCDCのアーキテクチャ・コンサルティングサービス
    l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで
    システムを構築します
    42
    ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション
    ITアーキテクチャのデザイン リファレンス実装
    DX推進のための組織デザイン
    

    View Slide

43. NCDCのアーキテクチャ・コンサルティングサービス
    l ビジネスモデルの検討からデザインによる可視化、先端テクノロジーの組み合わせで
    システムを構築します
    43
    ビジネスモデルのデザイン UXデザイン/PoC システム・インテグレーション
    ITアーキテクチャのデザイン リファレンス実装
    DX推進のための組織デザイン
    システム全体のアーキテク
    チャの策定
    使用する技術、サービスの
    選定
    アプリケーション開発者が
    該当技術に慣れていない場
    合、リファレンス実装を行
    い技術移管
    

    View Slide

44. バックエンドサービスAppPot
    企業のスマートデバイス活用を支援する
    モバイルアプリの開発／運用プラットフォームです
    44
    特徴③
    特徴②
    既存の社内システムとの
    連携が容易
    サーバー開発不要
    企業で必要な機能を
    実装済み
    特徴①
    ίετ࡟ݮ º ։ൃظؒ୹ॖ
    

    View Slide

45. AppPotの主要機能
    45
    Ϣʔβʔ؅ཧ
    •ログイン／ログアウト
    •Active Directory／LDAP／Google Appsとの認証
    連携
    σʔλ؅ཧ
    •端末とサーバー間のデータの同期
    •トランザクション制御によるデータの信頼性
    の確保
    •オフライン状態での利用と、オンライン時の
    再送
    ΞϓϦͷ࢖༻ঢ়گͷϞχλϦϯά
    •使用されている機能やエラー情報の収集、参
    照
    ϓογϡϝοηʔδɺFϝʔϧ
    •管理画面やAPI経由でアプリからのPush
    メッセージの送信
    •API経由でeメールの送信
    ηΩϡϦςΟ
    •端末内のデータの暗号化
    •SQL Injectionなどのセキュリティ対応済み
    ଞγεςϜͱͷ࿈ܞ
    •他システムとのWebサービス、ファイル、
    データベースとの連携
    •別オプションでERPパッケージ製品との連
    携コネクター
    各機能を簡単に使⽤するためのWeb APIと、
    iOS / Android / JavaScriptのSDKが提供されています
    

    View Slide

46. AppPotの事例
    46
    l モバイルアプリ：Monaca上でAngularJSを使ったハイブリッドアプリ
    l サーバー側処理はAppPotのみで、スクラッチ開発はなし。
    l 使っている機能：データ永続化 / Google OAuth認証 / モニタリング /
    ファイルAPI / 他システム連携アダプタ
    

    View Slide

47. View Slide