Morning Girl

Web API, Windows, C#, .NET, Dynamics 365/CRM etc..

Power Apps Common Data Service のAPIをPostmanとExcel(CData Add-in)で使ってみる

Power Appsは様々なWeb サービスをベースに独自のアプリケーションをUIベースで開発できるマイクロソフトのサービスです。

f:id:sugimomoto:20180516001329p:plain

powerapps.microsoft.com

基本的には、様々なクラウドサービス、SharePointやOffice365、Dynamics 365等のサービスに接続してカスタムアプリを作るのですが、Power Apps独自でデータベース的な構成を持つこともでき、それをベースにカスタムアプリを作成することもサポートしています。そのPower Appsのデータベース的要素がCDS・Common Data Serviceと呼ばれています。

続きを読む

Dynamics 365 のAPIを利用する上での全体像整理 2018/05時点

なんだかサービス? モジュールが増えすぎて、いまいち何がなんだかわかりづらい最近のDynamics 365 シリーズ

改めて全体を俯瞰したいな、連携するときに何がどのAPIで利用できるのか知りたいな、という動機から、ちょっとまとめを実施してみました。

基準となるアプリケーションの一覧

Planと言うべきかModuleと言うべきか、悩ましいところですがアプリケーションでとりあえず統一します。

US版サイトを例として、Dynamics 365 のアプリケーションを確認すると、以下のように表示されます。

現在全部で9種類

  • Sales
  • Customer Service
  • Field Service
  • Project Service Automation
  • Finance and Operations
  • Business Central
  • Talent
  • Retail
  • Marketing

f:id:sugimomoto:20180513162517p:plain

続きを読む

【API Memo】Github が新しいAPI、Checks APIをリリース

Githubが新しいAPI、Checks APIをリリースしましたね!

f:id:sugimomoto:20180511105156p:plain

私がニュースを知ったのは、Sankei Bizでしたが

www.sankeibiz.jp

Github公式のプレスリリースはこちら。

blog.github.com

機能としては、ビルド結果の成功・失敗だけでなく、詳細なエラーメッセージも含めて、API経由で取得できるようになり、そのビルド結果に応じたネクストアクションが取りやすくなるAPIとのこと。

従来はインテグレーション実施後にビルドの成功/失敗ステータスだけがGitHubユーザーインターフェース上に表示されていましたが、Checks APIの導入によりステータスの詳細が表示され、必要に応じてビルドプロセスの再実行もGitHubユーザーインターフェイス内で完結できるようになりました。

Checks API のリファレンスは以下から。

Checks | GitHub Developer Guide

実際の使い方については、この公式Blog 記事がわかりやすそう。

New Checks API public beta | GitHub Developer Guide

所感

個人的にこのプレスリリースで興味を引かれたのは「Microsoft Visual Studio App CenterやOutlookとの連携」のプレスリリースも同時に打っていること。

www.publickey1.jp

APIの公開しましたー、ユースケースこうですー、だけでなく、すでにGithubのエコシステムとしてどのようにサードパーティに使用してもらっているのか? というところまでセットでリリースしているのがすごいなぁと。

実際の公式Blogのプレスリリースでも以下のように述べられていますね。

本日の発表は始まりに過ぎません。 私たちは、アプリケーションのオープンエコシステムに簡単にアクセスできるようにすることで、迅速かつ柔軟性の高いワークフローを作り出し、最も重要な業務に集中できるようになると考えています。みなさんがGitHubを最大限に活用し、GitHubプラットフォームとシームレスに機能する有益でパワフルなツールを構築できるよう、これからもさまざまな方法を提供していきます。

実際のエンドユーザーはAPIを直接触ることなく、他のツールを通じて恩恵に預かれるという点でも、これはかなり真っ当なAPIプレスリリースの一つだと思います。

【API Memo】ガートナーフルライフサイクルAPI管理のMagic Quadrantレポートを見て

f:id:sugimomoto:20180512171359p:plain

GartnerがフルライフサイクルAPI管理のMagic Quadrant reportを発表したみたいですね。

www.gartner.com

どこの会社でもプレスしていますが、CA Technologiesがとりあげられていたニュースを見ましたので、そのメモ書きです。

www.dreamnews.jp

元プレスリリースはこちらかな。

www.ca.com

さらに大本になるガートナーのレポートにリストアップされているメーカー・製品を一覧を見るなら、こちらがわかりやすいです。

www.gartner.com

個人的に、CA TechnologyAPI Management製品は、オールラウンダーというか、すべての機能をまんべんなくカバーしている印象です。

Gartnerの評価点としても、以下のように述べられているように、

本レポートは各ベンダーがそれぞれのビジョンの実行能力と完全性という2つの主要基準に基づいて評価されました。また、ガートナーによれば、それらの評価基準のもとで、市場の理解、マーケティング戦略、販売戦略、提供(製品)戦略、ビジネス・モデル、垂直/産業戦略、イノベーション、地理的戦略などを考慮しています。さらに、製品/サービスの実行能力の評価基準のもとで、プロバイダーの機能製品/サービス基準を、APIのライフサイクルの各段階に対応する5つのカテゴリーに分類しています。具体的には、計画と初期設計、実装とテスト、展開と実行(基本)、展開と実行(拡張)、バージョン管理、および撤収/破棄です。

APIのライフサイクルの各段階に対応する5つのカテゴリーに分類して、評価するからこその印象かなと思います。

  • 計画と初期設計
  • 実装とテスト
  • 展開と実行(基本)
  • 展開と実行(拡張)
  • バージョン管理、および撤収/破棄

このレポートそのものは、API Management サービスないしツールのレビューが中心ですが、

以下のAPI エコスシステム プラクティスに関するレポートと合わせて、見たほうがいいのかなと。

Gartner Reprint

如何にAPIを構成し、如何に使われるAPIにするべきか? といったところが見えてくると思います。

【API Memo】Cloud Sign API 情報まとめ

様々なクラウドサービスのAPIについて触れて回るまとめ記事です。

今回はクラウド型契約書管理サービス ClouSignのAPIに関する情報まとめ。

f:id:sugimomoto:20180509181626p:plain

サービス・API 概要

公式サイトは以下から。

www.cloudsign.jp

クラウドサイン(以下「当サービス」とします)は、どのようなサービスですか。 当サービスは、事前に内容についてお互いの合意が済んでいる契約書・発注書などの書類をアップロードし、相手方が同意することにより、相互同意がなされたことを示す電子署名が施されるサービスです。また電子署名が施された書類の保管、管理もサービス上で行うことができます。

APIに関する概要は以下からどうぞ。

help.cloudsign.jp

API Check Point

API Check Point
サービスページ https://www.cloudsign.jp/
サービス提供形態(SaaS/PaaS/OnPremises) SaaS
APIエンドポイント https://api.cloudsign.jp
API ポータル / ドキュメント https://app.swaggerhub.com/apis/CloudSign/cloudsign-web_api/0.5.1
トライアル有無 あり
SDK / Driver なし
サービスカテゴリ 契約書管理
APIプロバイダ CloudSign
APIフォーラム/掲示 なし
SNS URL https://twitter.com/cloudsign_jp
認証モデル 独自:API Key
利用規約のURL
範囲(Public / Internal) Internal
API アーキテクチャ REST / OpenAPI
サポートされているリクエスト形式 JSON, URI Query String/CRUD
サポートされている応答形式 JSON

所感

Web UI上から行える操作は一通りAPIからも実施することができ、アプローチによってはマイクロサービスのように完結することができる面白いAPIだと思います。

はじめにテンプレートを作る必要があるので、そこはWeb UIから済ませておくのがいいかもですね。

また、ドキュメントがOpen API(Swagger)で公開されている点も嬉しいです。

他社クラウドサービスとの連携にも力を入れている感じで、Kintoneとの連携アプリも公開されていますね。

kintone-sol.cybozu.co.jp

Web hooksも公開されていて契約の完了(同意、または却下・取り消し)にSlack連携なども試せそうなのがいいですね。

help.cloudsign.jp

Salesforce版もTeraSkyが提供していますが、これはたぶんCloudSignのAPIをベースにマイクロサービスのようにSalesforceへ取り込んだものじゃないかなぁと思います。

appexchangejp.salesforce.com

ちなみに、過去にCloud Sign APIを使って、Tableauから接続してみたことがあります。

以下の記事で詳しく書いているので、よかったらどうぞ。

kageura.hatenadiary.jp

参考記事

note.mu

【API Memo】STORES.jpとオープンロジの物流部門における戦略的パートナーシップ。オープンロジのAPIをベースに実現

以下のニュースが興味深かったので取り上げてみます。

ecnomikata.com

最短2分でネットショップを作成できるSTORES.jpを運営する、ストアーズ・ドット・ジェーピー株式会社は、物流プラットフォームを運営する株式会社オープンロジと業務提携し、STORES.jp利用者向けに商品保管・配送代行を行う「倉庫サービス」を正式に開始した。

もとのプレスリリースはこちら。

blog.openlogi.com

ネットショップにおける受注から発送までを、STORES.jpのサービスをベースに、オープンロジのAPIを駆使しながら自動化を目指すようです。

STORES.jpにはいくつかサービスがあるみたいですが、メインの組込対象サービスはSTORESの倉庫サービス

stores.jp

プレスリリースでも以下のように述べられてます。

STORES.jpの倉庫サービスは以前より存在しておりましたが、より多くのお客様のニーズに応えるべく、オープンロジAPI 連携を行い、リニューアルいたしました。

表に出ているのは、完全にこの倉庫サービスで、エンドユーザーはSTORES.jpの倉庫サービスをインターフェースとして、内部のビジネスプロセスの連携にオープンロジのAPIが使わているようです。

こういったビジネスプロセスのマイクロサービスとして、APIが使われているアプローチはいいですね。

オープンロジは物流アウトソーシングサービスですが、かなり高機能なAPIも公開されているみたいです。

日々の物流業務をもっと効率的に。物流アウトソーシングサービス OPENLOGI

APIドキュメントは以下から。

OPENLOGI API v1.4

f:id:sugimomoto:20180510103751p:plain

商品登録から、入庫・出庫まで、まさに物流のアウトソーシングAPIベースでできてしまう雰囲気のAPI

認証方法はOAuth。結構きれいなREST Ful APIといった感じ。

テスト環境もあるみたいなので、私自身倉庫業務とは無縁なビジネスをしていますが、これはちょっと使ってみたいところ。

このアプローチは、寺田倉庫のminikuraと同じですかね。ビジネスモデルそのものを、API化してしまって、データだけでなく、ビジネスプロセスそのものを動かせるサービス。

prtimes.jp

【API Memo】Twitter Kit SDK が10月末でサポートを終了する模様

Twitter Kit SDK が10月末でサポートを終了するらしいですね。

f:id:sugimomoto:20180509133713p:plain

元情報ソースはこちら。

blog.twitter.com

ニュースサイトでも大きく取り上げられています。

www.itmedia.co.jp

Twitter SDKAndroid, iOS, Unityの3種類提供していたようで、この3種類すべてでサポートを終了するようです。

Overview — Twitter Developers

公式Blogで興味深いのが以下のメッセージ

We built Twitter Kit to help publishers build native apps, but given the evolving needs of our publishers, we have decided to sunset our support of the SDK. We plan to ramp up investments in widgets and our web embeds.

私たちはパブリッシャーがネイティブアプリを開発するのに役立つTwitterキットを作成しましたが、パブリッシャーのニーズの変化に対応して、SDKのサポートを取りやめることにしました。 私たちは、ウィジェットやウェブ埋め込みに投資する予定です。(雑翻訳)

Twitterが提供しているSDKのラインナップから見ても分かる通り、スマートフォンアプリなどでもっとTwitterを使ってもらうための方針だったと思いますが、最近APIへの取り組みの変化、純正TwitterアプリやWebを使う方向へ持っていきたいのかな、というニュアンスも以下のニュースから感じていたので、来るべくして来たのではないのかなと思います。

www.itmedia.co.jp

あと、ちょっとこのニュースを見て、改めて意外だったのは、JavaやC#、RubyPHPといったメジャーな言語SDKは公式で提供していなかったところ。

もちろん、APIは引き続き提供されるので、SDKが即使えなくなることは無いにしても、APIのバージョンアップが激しいTwitter APIへの追従はオープンソースで人気であろうとは言えど、大変だろうなぁと思います。