ブログBLOG

皆様こんにちは、インフォシェアの小高です。

Nintexの連載記事Season2です。

今回は申請書における自動採番について考えてみたいと思います。
これって、どのお客様とお話しても十中八九この話題になります。それほどメジャーな要件にも関わらず、実装は結構大変なんですよね。

連載記事（Season2）の目次はこちらから。
連載記事（Season1）の目次はこちらからになります。

———————

初めに書いてしまうと、Nintexだろうが、ShaerPointだろうが、自動採番の機能はありません。（Notesもですね。）ですから必要な場合は実装しなければなりません。

自動採番におけるごくごく基本的な要件２つとしては
１）申請ごとにユニークな番号を採番したい
２）申請ごとになんらかの連番を採番したい
となるでしょう。もちろんこれ以外にも色々な機能要件があります。

１）だけだったら、それこそGUIDでもいいのですが、２）の要件を達成するためには、次に採番される番号をなんらか決める必要があります。例えば、SharePointで実現するならば、番号管理リスト的な物を用意して、次に採番する番号が確定できるようにする感じですね。あるいは申請書が1つなら、申請書リストに申請番号列を用意して、そこを確認しながら、次の番号を付与するとしてもいいと思います。

ここで問題となるのは、１）の要件の方です。
と言うのも、上記の番号管理リストへの処理はもう少しちゃんと書くと

１．次に採番される番号を取得
２．採番された番号を申請書側に更新
３．次に採番される番号を更新

と言った処理に分けることが出来ます。もちろんこの通りでなく、１と３、あるいは２と３の処理は順番を逆にしてもよいでしょうし、３がないパターンもあるでしょう。ただ内容はあまり重要でなくて、問題は取得してから更新をおこなうと言った処理が分離する点です。

このような場合、Aさんの自動採番処理の最中に、Bさんの自動採番処理が割り込んでくる可能性が否定できないのです。

（番号管理リストが5番を採番する場合の例）

この原因はSharePointのリストでは、いわゆるデータベースのトランザクション処理（ロックが必要ですね）の実現が出来ないためです。

さらに言うと、自動採番をいつどこで行うかでも考え方が変わってきます。例えば、申請書の承認後に採番するのであれば、ワークフローの中で実装する必要があります。その場合、仮に上記のロック的な動きが実現できたとしても、ワークフローはロック系のエラーになるでしょう。

こうした事情から、なにも対策しなければ、重複した番号が採番される可能性がありますし、ロックの仕組みの実現があっても（例えば、番号管理をSQL Serverで行う等）、実行するとワークフローエラーになるかもしれません。

ワークフローは、さまざまな要因でエラーになることがあります。
SharePointが正しく動いていない場合もそうですし、ネットワーク障害もそうでしょう。そんな時、ワークフローの中で採番していると、採番自体が正しく行われない状態が起こりえます。

その場合は、ワークフローを再度実行してもらえばいいんです。しかし考えてみてください。SharePointのワークフローはエンドユーザーには容易に実行することができないユーザーインターフェイスだと思いませんか？

　　　⇒　　

そうなんです。そこがワークフローでの実装の問題点となりますね。
じゃあどうしましょうか？という事で、このあたりから、設計の話になってくるので、微妙トークとなってしまい、これ以上書くことが出来ません。。。

長々と書いてしまいましたが、こうした問題点が要件定義の段階で握れれば、WFでも実装してしまってよいかと思います。

ワークフロー以外の採番タイミングとして、申請フォームで採番するという方法（要件）もあると思います。
この場合は、フォームの中に、下記の様なUIを作成し、JavaScriptで、番号管理リストにアクセスを行うといった考え方になるかと思います。

フォームの場合においても、上記の重複の問題は同じように起こります。ただ、エラーになったらもう一度ボタンを押してもらえばいいですね。このあたりがWFとは事情が異なる点と思います。

フォーム実装で問題となるのは、採番された後で、申請を行わずそのままフォームを閉じてしまう場合がある点です。しかしこれは防ぎようがありません。せめてもの策として、上図のようにボタンクリックで採番するような、申請者が明示的に番号を採番するようにUIを工夫する等はありますね。

如何でしょうか、自動採番と言っても、それほど簡単ではないということがご理解いただけるかなと思います。

って、もはや全然Ninexと関係ない話になってしまいました。

前回の承認ルートも同様ですが、こちらもよくある例としてテンプレート化しています。もしご興味があれば、Nintexと合わせてご紹介することもできますので、下記からお問い合わせいただければ！
http://www.infoshare.co.jp/contact.php

ではまた。

皆様こんにちは、インフォシェアの小高です。

Nintexの連載記事Season2です。

今回は承認ルート（決済ルート）について考えてみたいと思います。
非常によく聞く話なのですが、中々難儀な話でもありまして・・・

連載記事（Season2）の目次はこちらから。
連載記事（Season1）の目次はこちらからになります。

———————

ワークフローというキーワードで想像する場合、多くの方は申請書や稟議書を申請して、承認の印としてハンコをもらうイメージがあると思います。（この手の仕組みはワークフローシステムの中ではヒューマンワークフローと呼ばれます。）

こうしたイメージでワークフローの話をする場合、
・複数のステップを経て最終承認される
・各ステップに承認者が存在する
・承認者は1人とは限らない（合議、多数決）
・金額等の条件によって、承認者が変更になることがある
・差し戻し、引き戻しをおこないたい
など、（他にもあります）が話の共通点でして、質問の多くはこのような設定はできるの？となります。

そして恐らく、質問者の方はこんな感じの設定をイメージされているのでは？と思います。
最初の承認者は誰で、次の承認者は誰で、と言った形で設定を行っていくような感じです。
こういうのを、ここでは承認ルート（マスタ）と呼びます。

※こちらは弊社でも取り扱っておりますが、NextSetの組織ワークフローの設定画面の1つです。

この承認ルートですが、SharePointの世界で考えた場合、質問者の方がイメージしているような、承認ルートマスタが最初から用意されているわけではありません。

SharePoint＆Nintexの世界の場合、こうした仕組みはもちろん実現可能です。ただ、自分で用意する必要があるんですね。

-----------------------------------
これはSharePointのワークフローがヒューマンワークフローに特化してないためです。
SharePointのワークフローは、情報システム間のフローを処理する、いわゆるシステムワークフローとしての機能も併せ持ちます。こうした話は、以下の記事が詳しいです。
ASCII.jp：アドインで活きるSharePointのワークフロー (1/2)｜今さら聞けないSharePoint超入門

Nintex Workflowは、SharePoitのワークフローをそのまま拡張したような製品となるため、申請承認に特化した機能だけ見ると、上にある承認ルートマスタのような、それのみを設定すれば、そのまま使用できるようなものとは少し事情が異なります。
-----------------------------------

すみません、前置きが長いですね。。。

じゃあ、SharePoint＆Nintexでどのような設定をするの？と言う話ですね。
この設定を全部乗せるのはさすがに厳しいので要素を紹介します。

例えば、こんなリストを用意してみます。

ワークフローの細かい説明は省きますが、例えば上記の承認ルートを取得してループしながら設定された承認者に承認タスクをアサインしていくようなワークフローを組みます。当然ですが、この設定が絶対解ではありません。別にループすることが唯一の正解じゃないですからね。

申請書自体には、起票時に申請書の下部に、以下のような承認ルートを表示してもよいですね。必要なら変更できるような感じです。

もちろん、表示しないで、ワークフローの中で承認ルートを判断してもよいと思います。

話がどんどん細かくなりますが、申請書の上部に↓のような、現在のステップを表示したり、採番機能を設けてもよいですよね。

多分他にも、色々な要件があると思いますが、重要なのは、承認ルートマスタは自分で設定する必要があるかわり、その他の色々な細かい要望を反映することができますってことです。

こうした考え方は非常によくある話ですので、インフォシェアでも申請承認のよくある例としてテンプレート化しています。
もしご興味があれば、Nintexと合わせてご紹介することもできますので、下記からお問い合わせいただければ！
http://www.infoshare.co.jp/contact.php

ではまた。

皆様こんにちは、インフォシェアの小高です。

Nintexの連載記事Season2です。
Nintex Formsは、昨年Enterprise Editionがリリースされ、その中の機能の一つにフォームをPDF出力する機能が追加されました。

連載記事（Season2）の目次はこちらから。
ちなみに連載記事（Season1）の目次はこちらからになります。

では、行ってみましょう！

———————

残念ながら、SharePointのリストには、印刷画面をどうこうする機能はありません。
普通にブラウザの印刷機能を使用する形になります。
そして、この状況はNintex Forms であっても同様です。

とは言え、Nintex Formsは使用する場合、承認申請をおこなうさいの申請フォームをデザインするといった目的が明確になっている事が多く、印刷の話になることが少なくないのです。

その場合ですが、Nintx FormsではCSSを適用することが比較的平易にできますので、そちらでの対応を考慮することになります。

例えば、こんな感じです。
フォームの設定の中にカスタムCSSがありますので、ここに直接記載します。
今回は赤枠部分として、通常時には表示、印刷時には非表示と記載しています。

この赤枠部分のクラスをコントロールのCSSクラスにセットします。

今回セットしたのは、フォームの上部にあるこの部分です。実際はパネルコントロールです。
※パネルコントロールは、複数のコントロールをまとめて１つにすることができるコントロールです。

普通に表示すると↓ですが、

印刷（プレビュー）次には↓のように枠（パネルコントロールですね）が表示されます。

印刷時には必要のないボタンなんかは非表示でもいいですよね。
下は印刷プレビューですが、ボタン（閉じるボタン）を非表示にしてみました。
※本当は画面下部にボタンが存在してるんです。

さて肝心のPDF出力機能ですが、フォームのリボンにボタンが存在します。

上記のCSSも加味されたPDFがダウンロード可能です。

また、こんなコントロールも追加されました。

こちらをフォームにドロップすると、↓のようにページ区切りガイドとして機能する形になります。ここで改ページをすることが可能ですね。

もちろん、この機能があれば、印刷がALL OKになるような魔法があるわけではなく、前述したCSSを含めて印刷の考慮をする必要はあります。とは言え、申請時のエビデンスを残すと言う意味でPDFを出力する機能は、よく引き合いになるお話です。

もし、ご興味のある場合は、下記からお問い合わせいただければと思います。http://www.infoshare.co.jp/contact.php

では、また！