DocuSign連携Nintex2017年05月23日(火)皆様こんにちは、インフォシェアの小高です。おさらいその2ということで、今回はDocuSign連携についてです。この連携はオンプレでもオンラインでもどちらも使用可能なソリューションとなります。こちらもNintexの連載記事Season2に追記したいと思います。連載記事(Season2)の目次はこちらから。DocuSign自体は、SharePointやNintexとは独立したドキュメントに電子署名を行うことができるサービスです。本来の使い方としては、依頼元のユーザーがDocuSignサイトから、あらかじめ登録してあるテンプレートファイル(docx等)を、署名者に送信するところから始まります。署名者にはメールが送られてくるので、そのリンクを元に、下記の様なDocuSignのサービスで電子署名を行う形になります。上記の署名ボタンをクリックすると、下記のような手書き可能なUIが表示されますので、ここで署名を行います。(手書きではなく、決まったスタイルの選択も可能です)後は、依頼元のユーザーはDocuSignのサイト、署名者はメールで、署名後のドキュメントをPDFとして入手する形となります。Workflowを使用すると何が嬉しいか、それは、、、依頼元のユーザーは、この一連の流れをSharePointのみで完結できる点にあるんですね。DocuSignのサイトに行かなくてもいいんです。テンプレートファイルにはSharePointのリストに入力した値を差し込んだ形で署名者に送ることが出来るようになります。差し込まれていました。(変更可能です)実はこれ、下記の様なSharePointのフォームに入力したものでした。このアイテムの保存でワークフローを実行していたんですね。流れとしては、こんなイメージになります。今回のデモでは、上記を秘密保持契約の締結と言うシナリオでご紹介いたしました。(もちろん、秘密保持契約のテンプレートファイルはあらかじめDocuSignにアップロードしておく必要があります)ですので、最終的にPDFとして、依頼元と署名者が入手するPDFは以下のようなものになります。(手書きの署名、、、(汗))実際のワークフロー自体は、いくつかのアクションを組み合わせて実装する形となりますが、もっとも肝心なリストアイテムの内容をDocuSignのテンプレートに差し込むアクションは以下になります。(DocuSignテンプレート事前入力サービス)最後に注意点です。これまでお客様と電子署名の話になる場合、承認時のハンコを押すイメージで話をお受けする場合が殆どでした。これは、承認と署名を同一視している話に他なりません。承認時の差し戻しや取戻しのシナリオを考えた場合、この署名のソリューションとは少々相性が悪いと考えられます。(例えば、承認時にコメントを残したい、証跡を取っておきたい等)SharePointとDocuSignは別のソリューションですので、行ったり来たり、あるいはデータの連携は少なければ少ないほど良いと考えられるからです。した意味で、SharePointとDocuSignの連携ソリューションでは、承認はSharePointで、署名はDocuSignでと、分けて考えることをお勧めします。署名はドキュメントのファイナライズという事ですね。これはDocuSignのライセンス体系においても有利になります。ご興味のある方がいらっしゃいましたら、以下のお問い合わせからご連絡いただければと思います。Workflowのドキュメント生成Nintex2017年05月22日(月)皆様こんにちは、インフォシェアの小高です。ご参加の皆様ありがとうございます。時間がかなり限られてましたので、駆け足になってしまいました。一度おさらいを含めてこちらに記載しておきます。内容自体はドキュメント生成になりますので、Nintexの連載記事Season2に追記したいと思います。連載記事(Season2)の目次はこちらから。ドキュメント生成とは、何とも普通の響きですね。「なぜそんな普通の事を」と思われるかもしれませんが、これは結構大変な変革なのです。言うのも、サーバーサイドのOfficeファイル作成は、技術的には(理屈では)出来ることはわかりますが、実際行うとなると結構色々なハードルがあるのが現状なのですね。Officeファイルを1からプログラムで生成するとなると、ぱっと思い浮かぶのはOfficeオートメーションですが、これをサーバーで実行する開発者は皆無でしょう。なると、その他のライブラリの使用となりますが、どれも一長一短と言ったところ。なかでも気になるのがサーバーの負荷です。実際SharePointの標準機能でもExcelエクスポート機能は、ファイルの作成自体をクライアントで行っていました。(iqyファイルでしたね。)ですので、Nintexの実装として、サーバー負荷を均一にできうるSharePointワークフローでの実装は納得できる感じです。実際の設定ですが、実装は「ドキュメントの生成」というワークフローアクションとなっていまして、これはオンプレでもオンラインでも使用可能です。アクションの設定は以下のような感じになっております。最終的に生成したいドキュメントのテンプレートファイルを指定していきます。このテンプレートファイルは、SharePointのライブラリにおいてあるdocx等のファイルで、事前に作っておき(中身はなんでもいいです)、こちらの設定画面で登録を行います。Taggerペインが表示されます。このペインは、WF内の値をドキュメントがわに差し込む設定ができるようになっていますので、ドキュメントに差し込みの設定を行います。(WF内の変数や列の値の参照が可能です)後はWFを実行すると、、、例えば、元々の申請フォームはこんな感じだったとしますね。値がテンプレートのdocxファイルに差し込まれて以下のようになります。このファイルは自動的にリストアイテムの添付ファイル、任意のライブラリに保存が選択できます。繰り返しますが、このファイルのフォーマットは私がデモとして作成したものですので、いかようにも変更できます。ちなみにこのファイルですが2ページ目があります。テンプレートを2種類用意して、2つ目のテンプレートは画面の条件によって2ページ目になったり、そもそもドキュメントに含まれなかったりを実装しています。今回は2つのファイルをまとめて1つのdocxにしてますね。(PDFにすることも可能です。)他にも以下のような特徴があります。セッションデモでは、申請承認が終わり承認された後、申請者が扱うdocxファイル(印刷でもなんでもしてください的なものですね)と管理者が保管するPDFファイルを、それぞれ添付ファイルとライブラリに自動的に作成しました。ちなみにですが、このドキュメント生成は別途ライセンスが必要になりますので、その点はご注意ください。ご興味のある方がいらっしゃいましたら、以下のお問い合わせからご連絡いただければと思います。