(BluePrism)スケーリングしやすいプロセス設計(案)
こんばんは、おむおむです。
比較的サクっと作ったロボちゃんが
当初の試算より大幅な削減効果が出そうでウキウキです。
ウキウキ過ぎて雨季になりました。(？)
自分用のメモ用に記事を殴り書きしてみます。
概要
・自動化対象処理のケース数に波がある。 ・繁忙期には1台では足りない、でも閑散期は何台も必要ない。 ・スケジュールでちまちま同時実行数を増減したくない。 ・なるべく手をかけずスケーリングしたい！
こんなこと、思ったことありませんか。
ありますよね(圧)
そんなときのために、ちょうどよさそうな実装方法を考えました。
※考えただけなのでちゃんとした運用はしてないです。
自己責任でよろ☆
実装イメージ
こんな感じです。
順を追って説明していきます。
保留中のケース数を取得する
まず、処理対象のデータを格納したワークキューから
保留中のケース数を取得します。
これは特に問題ないでしょう。
パラレル実行するかどうかを判定する
ミソはここです。
予め、数値型の環境変数を作成しておきます。
この環境変数は、
「プロセスをパラレルで実行する必要があるかどうか」
という判定を行うための基準となる数値です。
ワークキューでは1ケースあたりの平均処理時間を
自動的に算出してくれるので、
「SLAを満たすためには、XX件以上のときはパラレル実行が必要」
という計算が比較的に容易にできると思います。
環境変数として外に出しておくことで、
いちいちプロセスを開かなくても
容易にスケーリングの条件を調整することができます。
環境ロックを取得する
もう一つのミソが、環境ロックです。
説明するまでもないと思いますが、
Blue Prism には排他制御を行うための
環境ロックという機能が存在します。
この機能を使用することで、単一のランタイムリソースだけが
このプロセスの後続の処理を実行できるように
制御をかけることができます。
ロックが取得できなかった場合は、
フラグ型のグローバルデータアイテムなんかを用意して
メインページで終了に流すようなフローにするなどがよいでしょう。
スケジュールの作成
スケジュールはこんな感じ。
1つのタスク内に複数のセッションを張ってあげるだけで、
処理件数が規定数以上なら自動的にパラレル実行してくれます。
やったぜ☆
まとめ
・デフォの機能を組み合わせるだけで柔軟なスケーリングが可能
・まだまだBlue Prism の可能性は無限大☆
今の現場での稼働も残りわずか。
有終の美を飾るぞ～
(BluePrism)Utility - Windows Compressed Fileが日本向けじゃない件
ご無沙汰しております。おむおむです。
年末年始で公私ともにバタバタしており、
なかなかアウトプットの時間が取れず。。。
引っ越しって面倒だなぁ(詠嘆)
Utility - Windows Compressed Fileとは
その名の通りファイルを圧縮したり、展開するためのVBOです。
v6.5から導入されたやつです。
パスワード付きZipの操作はできません。
そんな面倒な運用してんじゃねぇ！という
英国からの圧を感じざるを得ません(違う)
v6.10現在、使用できるアクションは以下の通り。
処理内容は、まあ、名前のまんまです。
・Add File to Zip ・Create Zip from Folder ・Delete File from Zip ・Extract All from Zip ・Extract File from Zip ・Find File in Zip ・Get Zip Contents
使ってみると・・・？
例として、「Extract All from Zip」アクションを使って
Zipファイルを展開してみます。
テスト用に、Cドライブ直下に「temp」というフォルダを作り、
その中に「test.zip」というZipファイルを用意します。
中身はこんな感じです。
アクションの入力パラメータは、
Zipファイルのフルパスと展開先のフォルダパスです。
シンプル。
Cドライブのtempフォルダ配下に
そのまんま「test」という名前で展開しましょう。
はいできました。
中身見てみましょう。
文字化けしてるじゃないですかﾔﾀﾞｰ
ちなみに、他のアクションを使用しても
ファイル名にダブルバイト文字が含まれていると
同様に文字化けが発生します。
原因を考える
恐らく文字コードが違うからでしょう(ｽﾞﾊﾞﾘ)。
今までファイルの中身の文字化けについては
何度か遭遇したことがありますが、
ファイル名の文字化けはあまり見かけませんでした。
Lhaplusとか7-Zipとか使ってると
自動的にいい感じにアレしてくれてるからでしょう(雑)
が、このVBOで使用されているZipFileクラスは
特に指定しない場合UTF-8でデコードしようとするみたいです。
そのため、Windowsのシステムロケールが日本になっていると
ファイル名にShift-JISが使われるため
文字化けが発生する、ということだと思います。
たぶん。おそらく。知らんけど。
というか、Windowsのファイル管理システムのNTFSは
Unicodeでファイル名を保存しているので
そのまんま使えばいいものの、
システムロケールでShift-JISが指定されていると
WindowsのAPIか何かでANSI(Shift-JIS)に変換されるのでしょうか？
マジでわからないので誰か教えてください...
docs.microsoft.com
解決法
原因は、まあ、さておき。
解決方法を以下に書いていきます。
もちろん自己責任でお願いします。
方法1. 外部の圧縮ファイル操作アプリケーションを使用する
これが一番手っ取り早い気がします。
7-Zipとか、Lhaplusとかです。
だいたいこれらのようなアプリケーションは、
コマンドラインから操作できるようになっているので、
Utility - EnvironmentのRun Process Until Endedを使用することで
比較的容易にZipファイルの操作が可能です。
例えば7-Zipを使用する場合、入力パラメータはこんな感じ。
(7-Zipはデフォルトのインストールフォルダにある前提です)
・Application : C:\Program Files\7-Zip\7z.exe ・Arguments : x -o<展開先のフォルダパス> <Zipファイルのフルパス> ・Working Folder : 指定なし ・Timeout : MakeTimeSpan(0, 0, 0, 30)
便利ですね。Igor Pavlovさんに感謝です。
そのほかのオプション(パスワード付きZipの作成とか)は
7z.exe -?とかで調べてくださいな。
方法2. VBOのコードステージを書き換える
ここからは推奨しないので読み飛ばしてOKです。
だって実装めんどいし！
何をするかというと、コードステージを書き換えて
Shift-JISに対応させる、ただそれだけです。
まずはVBOを別名保存します。
Utility - Windows Compressed File - Extendedとかでいいと思います。
次に、初期化ページから名前空間にSystem.Textを追加します。
あとは各アクションでShift-JISを使用するように書き換えるだけです。
書き換える「だけ」、といいつつも、
引数だけでなくメソッドを変更するものもあるのでご注意を。
例えば、「Extract All from File」の場合は
ZipFile.ExtractToDirectory(sourcePath, destinationPath)
↓
ZipFile.ExtractToDirectory(sourcePath, destinationPath, Encoding.GetEncoding("shift_jis"))
と第3引数を追加するだけで済みますが、
「Get Zip Contents」の場合は9行目を
Using archive As ZipArchive = ZipFile.OpenRead(path)
↓
Using archive As ZipArchive = ZipFile.Open(path, 0, Encoding.GetEncoding("shift_jis"))
とする必要があります。
面倒だね☆
方法3. システムロケールを変更する
最後は、システムロケールを変更する方法です。
ゴリゴリに非推奨です。
要はファイル名にShift-JISが使われなければいいので、
そこを変更してしまおう、ということです。
まずはコントロールパネルの「地域」を選択し、
「管理」タブの「システムロケールの変更」から英語圏などを選択する、
もしくは「ベータ版: ワールドワイド言語サポートでUnicode UTF-8を使用」
にチェックを入れ、端末を再起動します。
注釈にもある通り、端末内のユーザ全体に影響が出るので
おすすめしないです。
特にバッチファイルを現役で使用しているような環境では
影響出まくりハマグリだと思います。
チェックボックスの項目がベータ版なのは、
多分コードページをUTF-8(CP65001)に変更することによる
影響等を完全にはチェックできてないから、とかそんな理由でしょう。
多分。知らんけど。
まとめ
・7-Zipは有能
・早くShift-JISから脱却したい
・今日のコメダ珈琲はちょっと暑い
今さらながらパラサイト 半地下の家族観ました。
心がしんどくなったのでお寿司でも食べよう。。。
(RPA)今年の振り返り
どうも、おむおむです。
師走とはよく言ったもので、
師ですらない下っ端の私でさえ忙しいです。
ぴぃ。。。(鳴き声)
さて、普段はBlue Prismに関することを書いていますが、
今年もあと3週間足らず、ということで、
今年1年を振り返ってみようかなと思います。
そして、RPAについて思うこと、諸々ありますので、
その辺も書いてみようと思います。
まじめだなー自分。
今年のお仕事
新卒2年目というペーペーではありますが、
お客様先でのRPAの導入支援をさせていただきました。
いやマジで色々やらせてもらいました。。。
RPA担当の方に作成いただいた要件定義書をもとに詳細を詰めて、
業務担当者の方からヒアリングして、
設計して、実装して、テストして、運用保守して・・・
圧倒的成長！とまではいかなくても、
ぼちぼち成長できたんじゃないかな、と思ったり。
環境が人を育てるとは本当なんだなぁとしみじみ思いました。
でもまだまだ！
もっと頑張ります☆
今年のお勉強
こちらも、いろいろやりました。
枚挙にいとまがないです。
(言ってみたかっただけ)
ざっくりと列挙すると、、、
▼言語 ・VBA ・VB.NET ・C# ・Transact-SQL ・Google App Script ▼API ・REST - Twitter - Slack - Trello - Poke API ・SOAP - Blue Prism ▼ミドルウェアとかインフラとか ・SQL Server ・Squid ・Active Directory ・AWS - EC2 - RDS - VPC - WorkSpaces - Directory Service - Route53
年末とか来年はCとかC++とかやります。
あとDockerとかHyper-Vも勉強します。多分。
RPAについて思うこと
今年の振り返り、といいつつ、本題はここだったりします。
RPAを生業として1年半以上が過ぎましたが、
当然、考えも変わってくるわけで。
だいぶ長くなってしまう予感がしますが、
ちょっと頑張って書いてみようと思います。
RPAは簡単？
この1年で、RPAは幻滅期に入ったと言われていますが、
「ITに明るくない人でもお手軽簡単に作れます☆」
ということが、今も変わらず営業トークの中で使われているかと思います。
・・・ほんとでしょうか？
多分、この謳い文句、正しくは
「ITに明るくない人でも
(とりあえず動くものであれば)
お手軽簡単に作れます☆」
ではないでしょうか。
もちろん、実際に作成の容易さにフォーカスした製品も増え、
必ずしも間違っているわけではないとは思いますが、
どのツールにおいてもある程度の品質のものを作るためには
ユーザがしっかりと学習する必要があるでしょう。
「技術の民主化」や「市民開発者」といえば聞こえはいいかもしれませんが、
実装だけできる人が増えることに、
果たして意味はあるのでしょうか？
ウォーターフォール型開発モデルでいうところの、
「開発・実装」ができるようになりました！
でも要件定義や設計みたいな上流工程はできません！
運用保守のことも考慮してません！
みたいな人が増えたところで、
より混乱が生まれるだけでは・・・？
みたいに思ったり。。。
少なくとも、自分は「簡単」とは思ったことはないです。
ある程度、RPAに関する情報が普及してきたとは思いますが、
まだまだその難しさについては理解されていないような気がします。
RPAはVBAと変わらない？
よくSNSなんかでも、「RPA不要論」は定期的に出てきます。
(最近は減ったかもしれませんが。)
多分この論が挙げられる理由として、
「VBAなどでできること以上の成果を出せていないから」
というのもあるのかなと、私は思っています。
それはそうですよね、
だって、大したことのない作業を自動化したところで、
先述した通り保守やリカバリ対応で工数が増大する可能性すらあるわけで。
そんなことであればVBAやPythonでやった方がいいですもん、
なんせ無料だし☆
でも私は、RPAはもっと抜本的に、
業務を変革できるだけの可能性があると思っています。
学習の難易度、アジリティ、耐障害性、セキュリティ、
動作の安定性、保守性、できることの範囲・・・
どれをとっても、業務の根幹に組み込めるだけの
ポテンシャルがあります。
RPAは重要な業務に適用できない？
では、なぜ成果を出せていないのか？
それは、「RPAを重要な業務に組み込んでいないから」ではないでしょうか。
そもそも論になってはしまいますが。
「RPAは不安定だから、重要な業務に組み込めないよ！」
という意見もあるでしょう。
でも、辛辣なことを言うようですが、
それは単に製品自体がショボいか、
実装者のスキル不足のどちらかが原因だと思います。
当たり前のことではありますが、
本当にRPAを使って業務改革をしたいのであれば、
十分な機能を持ったツールと、
十分な知識を提供してくれるベンダーを選定する。
そして、十分なお金をかけ、人的リソースを割り当てる。
これが大前提だと思います。
簡単に習得できて、片手間で効果を出せる。
そんな夢のような話はありません。
RPAは、既存業務を置き換えるだけでOK？
そんなわけないですよね。
いや、もちろん置き換えるだけでもいいんですが、
それだけだと自動化による効果には限界があります。
ではどうするか。
「RPAがある前提で業務を再設計する」
ということが必要じゃないか、そう思っています。
もちろん、企業によってRPAを導入する目的や、
期待している効果は違うかと思います。
「目先の単純作業を減らしたい」というのも、
もちろん立派な目的だと思います。
ですが、それならばRPAじゃなくてもいいと思います。
それこそVBAとはPythonとか。
年間ウン十万、ウン百万のライセンス費用と、
開発工数、運用保守の工数に見合うだけの
費用対効果を出したい！というのであれば、
根本的な業務の再設計、
いわゆるBPRというところから逃れることはできないはずです。
今まで人力だと工数がかかりすぎるからできていなかったり、
そもそもやっていなかったような、
人力だとできないことをRPAにやらせる、とかね。
RPAは内製化するべき？
「RPAは内製化するべき！」みたいな論調が、今も根強く残っています。
実際、RPAの強みとして、
システム開発・改修よりも柔軟に、敏捷に、そして安価に、
業務の自動化・効率化を図ることができるという点があります。
そしてこのメリットを活かすためには、
自社内のリソースで賄っていくことが必要だ、
外部のリソースを使ってしまうとコストがかさみ、
RPAを利用する意味がなくなってしまう、
というのがこの論調の趣旨となります。
うーん、なんか典型的な手段と目的の逆転というか。。。
内製化というのは、
RPAを運用していくための手段であり、
それを実現すること自体が目的とはならないはずです。
もちろん、その企業によって
RPAに対して求めていることや実現したいことが違うので
ひとまとめにして断ずるつもりはありませんが、
とはいえ内製化を無条件に目指したり、
推したりしているベンダーが多いなぁ、というように感じます。
何なら内製化なんてのは
RPAに限らずITソリューション全般において
最も難しい運用方法の１つであるはずなのに。。。
そういった風潮が、
「RPAって内製化できるほど簡単なんだ！」
という認識を持つ企業を増やしてしまっているのかな、
と感じています。
なんか身内にナイフを突きつけている気がしますが、
まぁ気にしないことにします。。。。
RPAはオワコン？
RPAはオワコンとか、
幻滅期だとか、
使えないとかいろいろな声が聞こえてきます。
そんなことはないと思います。
少なくとも私は。
RPA単独でできることもさることながら、
AIとの連携であったり、
クラウドサービスとの連携であったり、
単にPC操作の自動化にとどまらない、
テクノロジー全般を連結させるための
プラットフォーム的な、
そんな存在になれる可能性を十分に秘めていると思います。
iPaaSがあればRPAなんぞいらん～
みたいな話がありますが、
少なくともある程度の規模の企業では
APIだけでデータの連結なんて当面は無理でしょうね。。。
社内システムのAPIを公開するなんて
尋常じゃない工数がかかると思います、、、
RPAに携わって後悔してる？
長いっすね。
これで最後にします。
結論、まったく後悔はしていないです(ｷﾘｯ)
自分は大学が文系の学部で、
Excelすらまともに触ったことがない状態でした。
そんな素人が、
「ローコードだけど結局言語の知識必要やん！」
「問題の切り分けをするためにはRPA以外のツールの知識がないと！」
「あれ？OSとかネットワークのレベルで理解しなきゃじゃね？」
と、広く知識をつけよう！と思う
きっかけを作ってくれたのはRPAでした。
そしてBlue Prismのベストプラクティスを学ぶことで、
オブジェクト指向型の開発方法や、
最終的には組織構築論にまで着手して・・・
少なくとも、一般的なシステム開発の
SEやPGで経験できる、
もしくは興味を持つことがなかったような領域まで
キャッチアップできたんじゃないかな、と感じています。
ありがとうRPA！
ありがとうBlue Prism！
そしてこれからもよろぴく☆
はいおわり！
まとめ
・皆様、一年間お疲れさまでした！
・あと2週間、全力で駆け抜けます！
とやかく言ってきましたが、
RPAに関わることができてよかったなぁ(しみじみ)
と心から思っています。
引き続きお引き立てのほどよろぴくです☆
