[RPA]PC自動化技術総合スレ[効率化] Part.6
■ このスレッドは過去ログ倉庫に格納されています
mailItems.Where(item => item.Subject.Contains("abc"))
量が多いならSQLを書け >>155
触ったことも無いのに
嘘言うのは止めたら?
ログにどこでこけたのと
こけた原因出てるし
本気で分からないのなら
RPAじゃなくて、その担当がダメ >>160
"@SQL=" & Chr(34) & "urn:schemas:httpmail:subject" & Chr(34) & " Like '%検索キーワード%'"
ネットで見つけたのは↑のヤツです。
何か送信ができなかったので、部分的に全角文字にしています。
一応これでもできたけど、Likeの箇所の文字列を変数にしたいと思っているのですが、セレクターでの'" & 変数名 & "'とすればいいのかと思って入力したけど、エラーになってしまいました。 >>162
プログラムをろくに知らない素人ではログを読むのは難しいのでは?
というかログを見るという発想すらないかもしれない
プログラムの勉強をすると自然と身につくものだけどね >>163
String.Format("@SQL=""urn:schemas:httpmail:subject"" Like '%{0}%'", hensuu.Replace("'", "''")) 具体的な話になればなるほど、プログラムそのものやんけ。
何が簡単だよ。 そんな物おばちゃんが使える訳がない。 >>167
現場サイドで作るよりも専門部隊(情シスの一部門)組んでやった方が良いっていう感じになってきてるな
・現場の人に現業務と並行してツールの学習&シナリオ作成は無理
というより現業務優先になるから結局RPAを触らなくなる
・ロボット作るにも作法(安定稼働/エラー処理への対応)があり
高品質なものを作ろうとすると時間がかかる
・ボトムアップだとロボットの管理がし辛い
おばちゃんの片手間は幻想と化してきてる ここの過去スレで俺が予言した通りに進みつつあるな
RPAは素人じゃできない
ベンダーロックインして専門家を送り込むのが真の目的
従来通り開発費を取られてメンテナンスで骨までしゃぶられる 前スレで出てたnalgo-botというのが事務のおばちゃんでも使えるぽい。 >>171
それって今までとどう違うのか……
クソベンダーのクソシステムが
クソベンダーのRPAになるわけで >>163
Chr(34) とは、"(ダブルクォーテーション)の事か?
& で、文字列を連結してるのか?
最初・最後の、" を削除すると、
「@SQL="urn:schemas:httpmail:subject" Like '%検索キーワード%'」
こんな文字列になるけど、シングル・ダブルクォーテーションの両方が存在するのか? >>167
若宮正子さんみたいなおばちゃんだらけなら使えるんだけどな。 >>154
プログラム的ではないが
いったん秀丸に本文コピペして
整形すると折り返しに改行コード入れてくれるから
それ再コピペしたら? >>175
Oracleとかだと…
ダブルクォーテーションは項目名(テーブル名や列名)を意味する、普通はなくてもいいけど項目名に空白とか括弧等を含む場合とかには必須
シングルクォーテーションは文字列とかを意味する Ruby なら、%q( ) 記法で、'(シングルクォーテーション)をエスケープする必要がなくなる。
"(ダブルクォーテーション)も、そのまま書ける
p は、文字列の両側を、" で囲んで、文字列内の" は、\" と表示するが、
puts は、文字列の内容を、そのまま、print する
p str_1 = %q(" ') #=> "\" '"
puts str_1 #=> " '
p str_2 = %q(@SQL="urn:schemas:httpmail:subject" Like '%検索キーワード%')
#=> "@SQL=\"urn:schemas:httpmail:subject\" Like '%検索キーワード%'"
puts str_2
#=> @SQL="urn:schemas:httpmail:subject" Like '%検索キーワード%' 結局いいツールがあっても中小には無理だよ
キャパがない
大企業であれば準IT人材達が勝手にやるよ 中小の 1%くらい(適当)は、やればできると思うな…
知らない、様子見、全員がやる気なしなだけで
uipathなら無料版もあるし なんでも自動化できたら
人間要らないでしょ?
温かみが無いんだよねこういうの 大体の作業は人間が「ちょっと」判断することが必要
そこが自動化できないんじゃないのかなあ EXCEL(VBA)とACCESS使えば一日でツール作れるものを、何日もかけてロボ作らないといけないなんて、お前らどんだけ馬鹿なんだよ
少なくともうちは ITの会社でお前らプログラム開発担当だろうが
ホントCOBOLしか書けないようなバカは辞めてくれ >>177 何じゃそりゃ、自動化とは程遠い。
>>154 だから、少しは何でも良いからプログラムを勉強しろって。 >>186
みずほ銀行のシステムってコボルなんだろう? >>188
昔々はPL/Iでした(全部かは不明)
いまCOBOLあるかも不明 >>165
ありがとうございます。
無事、変数で件名のフィルター使えました。 >>186
1日で解決してしまったら頑張ったアピールが出来ない。
時間をかけたものの方が評価されやすいのだから
作業効率を落として生産性アップに取り組むのが
末端労働者として正しい選択。 >>187
秀丸だろうがなんだろうが
使う方が正しい
RPAで簡単にできんことを
複雑怪奇なシナリオ組む方が愚か
自動化から程遠いって
今までの、えすい〜が実現なかった難所だったんだろ
たから後半には同意
Uipathに拘るのは頭の体操的には楽しいが
難しいなら他の手を考えたほうがいいよな >>191
ですよね
多スレッドでCPU使い切るようなロボットの作り方でも研究しながらやります
(ん?、そんなアクティビティあったような… なら、GPGPUも混ぜてやったる) >>192 は? 秀丸でマクロ組んで叩くのか?それしか思いつかない人間はそれが楽だと思うかもしれないけど、RPA人には意味不明だろ。
SE? プログラムならお茶の子さいさいだよ。何をやるにしてもいろんなツールの得手不得手くらいは少し勉強した方が良いと思うけどな。
全てを自分でやれとはいわない。
あれを使えば簡単そうだなと思うだけで良い。 得意そうな人に相談すれば良い。 >>187
だからプログラム的ではないと前置きしてんだろボケが。
複数のソフトを利用するのがRPAだし
文字整形は秀丸なりエクセルなりにやらせて
変数にぶっこみゃいいんだよ RPG人とかプログラム的とか造語を量産するのやめたら
まさかプログラム関連の板なのに
雰囲気で分かるだろ、とか間抜けなこと言いまくるつもりか
まぬけ的なアホ人だから? 造語バカに感化されて誤字を書いちゃったよ
かっこ悪い >>194
秀丸の文末改行はマクロいらんぞ?
マクロなんて誰が言ったんだ? >>198
194が脈絡も無く言ってるだけ
煽る前に
書き込みくらい読めばいいのに
そうしたら
誰が言ったかすぐ分かる 膨大な反復処理があるのに振る舞いが非決定的なウィンドウシステムをかませるのは設計方式を誤っている
高い信頼性が必要な場合は参照透過性の強いAPI方式を採用すべきだと思う 隙あらばRPAvsプログラムwww
非プログラマー向けにわざと陳腐化してる主旨を
理解する脳はないのか? >>200
それはもう決着済み
自動化したいシステムに
APIがないから
RPAでやってるだけ APIがなければ整備すればいい
既存コードがあるとすごく簡単
サードパーティのアプリならほどんどapiあるけど
ないならプログラミングで再利用しやすいクラスを作る
rpaは再利用しにくいからね >>38 これってどういう意味?
3つのソフト作成にその言語が使われてるってこと? >>204 各々のRPAの機能拡張をしたいときに使える言語
例えば UiPath で何か複雑なことをやりたい場合には VB.net やC#が使えるよと言う話。
PowerShell VBAもRPA共通の機能拡張として使えるという話。 素人がWindowsの返す振る舞いのパターンを捌き切るのは不可能だろう
私ならラッパーをかませてRPAプログラマとミドルウェア開発者に分担させる プログラマに何か恨みでもあるのか?気持ち悪いスレだな >>202
1スレ前から見ているが私と同じ趣旨の書き込みは見つけられなかった
結論に至る過程を勉強したいので場所を教えてもらえる? >>203
自動化したいのは
大半がベンダー製のシステムの話と思うけど >>208
読んでもないのにレス読んだとか
勉強したいとか
えらい嘯いて煽りまくってるが
そもそも
APIがないシステムがある
という発言がそんなに気に入らないの? uipathで質問があります
webのデータスクレイピングで、各セルの値が inputタグの value属性で表示されているため値が取得できません
メタデータ抽出に追加記述等で取得できるようなら教えて下さい
今のところスクレイピング一発では諦めて、テーブル要素に対して、各セルループで getvalueまたは、getattributeするしかないのかなと思ってます >>212
メタデータ抽出に書けるタグ一覧(extract、row、webctrlなど)も、どこかにあれば教えて下さい
ググり方が悪いのか探せません >>204
uipath触ってるけど、複雑じゃなくともvb.netのメソッドは普通に使うよ
ファイルダウンロードして、そのファイル編集しようとしたらもう必要。 >>212
javascriptのほうが簡単ですよ >>206
PageObjectのようなライブラリを開発する人とシナリオスクリプトを開発する人で分業することも出来ますね >>210
Windowsデスクトップは他の様々なリソースを制御している関係で
ソフトウェアがそれを含んでしまうと非決定性に汚染されてしまうという点、
繰り返し処理になるなら信頼度計算は直列モデルになるのでその設計方式では致命的だという点を指摘している
この観点で>>40から再度読み直したが君の言っている文章はやはり見当たらない
「デスクトップ」「ウィンドウ」で検索をかければすぐ分かる
勉強したいのは本心なんだがどうして私が煽りまくってる事になるんだ? API方式という書き方が悪かったのかもしれないが
もっと確実性の高いシステム間結合方式に置き換える必要があるという事だ
データベースから抜き出すなりファイルに吐き出すなりミドルウェアを挟むなり、
何らかの信頼性の高いインターフェイスを構築するのは絶対条件 RPAが前提だからRPA以外の案を出すなという意見は技術者としてナンセンスだし何の役にも立たない >>219
確実性の高い(絶対確実だとは言っていない)システム間結合方式の必要がある
ということを承知の上で(承知していなくても)
確実性がそれなりで労働時間を削減できるのがRPAのポテンシャル ポテンシャルはあるのは同意するけど
業者が謳ってるような誰でも出来るもの
ではないし、手軽にやれる値段でもないから
あと1〜2年で終わると思う。 >>223
ベンダーロックインして骨までしゃぶられるから終わらないよ >>218
>>49があなたの求める答えでしょうに
できるなら確実な方法でやる。無いからRPAでやってるだけ
>>68の後半とあんた自身が書いた>>206
高いシステム間結合方式に置き換えれるなら、やってる
できないからRPAでやってるだけ
技術者としてナンセンスというならば
概念しか言わず、具体策を示さないあんたと
不確実性を含んでもRPAで自動化を実現している技術者と比べたら
明らかにあんたのほうがナンセンスでしょうに
それともあなたの比較対象は
不確実性を含んでいるがゆえに自動化を実現できない技術者のみ
の限定的な話?
少しでもスレ読んだらRPAvsプログラム論争は不毛だって分かる
分からないのは、してもいないことをさもしたかのように
読んだ、読んだと貴方が嘘を言ってるから そもそもRPA陣営に勝ち目などないのだから確かに不毛といえば不毛だ
高い金を払って手間暇をかけて苦労して不安定で遅い低品質なツールを作る
全くもって理解しがたい >>223
RPA化する業務の洗い出しはRPAベンターの仕事、
RPAロボの作成はPGの仕事、
普及するわけ無いな >>225
分かった。
話が通じそうにないので終わりにしよう。 勘違いしがちだけどRPAの費用って
現行システムの改修/追加よりも遥かに安上がりなんよ
というか現行システムに改修依頼だしてもベンダーが実際に対応できるかどうかって言われると
予算見積もったタイミングでぽしゃる事が多い
なのでRPAで外付けで自動化するしか無いんよ、金が無いから
正直な事言ったら小回りの利くシステム開発が理想形だけどそれが出来る企業は全くない 外付けと改修は違うものなので金額を比べても無意味
同じことやるならプログラミングのほうが遥かに安上がりだよ あげあしとり
同じことやるならプログラミングのほうが遥かに安上がりだよ
外付けと改修は違うものなので金額を比べても無意味 システム化でペイできる→システム化
API用意できる→API使う
自動化対象がブラウザアプリ→Seleniumとか使う
上記全てに当てはまらない→RPA 若しくは Spy++とかで頑張る
これでFAっしょ… >>230
>外付けと改修は違うものなので金額を比べても無意味
残念ながら「こういう事を実施したい」っていうユーザー要望の観点から見ると
外付けでも改修でも(ほぼ)同じ結果が得られる場合、金額が安い方が評価されちゃうんよ
実際には保守性や拡張性も考える必要あるけど、予算に限りがある以上、どうしても妥協点を模索する事になる
>同じことやるならプログラミングのほうが遥かに安上がりだよ
残念ながら現実はそうじゃない
よくRPA業務の例で「システムへの繰り返し登録処理を行って○○時間削減!」ってよくあるけど
これは「システム側でインポート機能による一括登録機能を実装したらいいんじゃないの?」って言う事も出来る
が、後者の方法を実装する場合は
システムベンダーに問い合わせて、見積もり金額と改修期間の概算取得
見積もり結果から費用対効果が十分得られるかの検討、承認が下りてやっと要件定義からスタート……
で、結局費用対効果が出ないって判断されたら、そこで話が終わる
だからRPAで費用対効果が出るギリギリのラインで自動化するんだよ >>229
> 正直な事言ったら小回りの利くシステム開発が理想形だけどそれが出来る企業は全くない
説得力のある意見だな この箇所って結構ポイントだと思うわ
実現方法は色々ありそうだけど ベンダーが小回り利かすとか(まぁこれは難しいか)、RPA会社がテンプレートみたいなのを作るとか、安価で簡易なプログラマ派遣サービスができるとか
RPAがダメならこっちの方向にいくかもしれんね >>212-213
「html input value 取得」で検索! >>233
だから違うものを比較してどうすんだよマヌケ
システムへの繰り返し登録とやらをプログラミングで実装すりゃいい
品質やテストもRPA基準のゆるゆるでOK
プログラミングのほうが安くなった
RPAが安いというか印象はやるべきことを省略したから安いんだよ
プログラミングでもやるべきことを省略していいなら当然安くなる >>236
何か勘違いしてるかもしれんけど、RPAもテストフェーズは別に緩くないぞ
データのパターンテスト(全分岐の網羅)、
異常系テスト(異常データが来た時に想定通り停止するか)
RPAの性質上必要な安定性(最後まで安定して完遂するか、できれば複数回実行して測定)
このぐらいは普通のプログラミングと一緒で、最低限の品質が担保できてるか、仕様通りにできてるかは検証する
そもそもRPAはコーディング部分の負担を減らすだけであって
要件定義、設計、テスト辺りの工程はプログラミングの考え方と変わらんぞ
コーディング部分をさっさと作れるから全体的な工数が少なくなるだけだし >>237
それこそ素人には無理なのでエンジニアを雇うしかない
エンジニアを雇うならオモチャじゃなくちゃんとした道具を使ったほうが遥かに効率がいい
つまりRPAもプログラミングもキッチリやる前提ならやっぱりプログラミングのほうが安い >>237
というかコーディング部分の負担はRPAの方が増えてる
キーボードでサクサク打ち込むのと愚鈍なマウス操作じゃ勝負にならん
オブジェクト指向サポートはじめとして機能も貧弱
リンターやリファクタリングツールなどエコシステムもくそ雑魚
マルチプロジェクト管理すらできない冗談みたいな製品すらある始末 >>237
横からすまんが、そんなキッチリとテストやるもんなん? RPAのメリットを消しかねないのではと思うが 本部側がガッツリ作り込むやり方の話なのかな >>240
テストだけはしっかりやった方が後が楽になる
ある程度の長期稼働をやるなら安定性が高くないと話にならない
特に削減時間の効果が高いものは止まった時のインパクトもデカくなっちゃうしね
止まったらら原因調べて必要なら改修して……っていうのが積み重なるとそっちに工数を取られる
だからしっかりテストして品質は確保した方が良い >>239
IDEが絶望的に死んでるのを筆頭に
型システム コレクション ジェネリクス
インターフェイス オーバーロード ポリモーフィズム
名前空間 スコープ制御 アクセス修飾子
アサーション ガード節
コールバック 遅延評価 畳み込み 継続
マクロ マルチスレッド ロック
この辺りも息をしていない ところでなぜRPA厨はム板にやって来てマの洗礼を受けるという自傷行為を続けているのですか?
宣伝なら商売敵のいない別の板でやればいいと思いますよ。 >>240
やらないよ
rpaは業務やってる人自身がアジャイル型で開発して使うだけ
作業補助ツールに近い >>240
RPAシナリオ作ってるけどガッツリテストするよ >>243
マ板原住民、顔真っ赤勝利宣言www
おちょくった奴土下座しろwww >>237
マニュアルに落とし込んでユーザーにやらせられればベストだけど、現実は >>238
RPAを一括管理できるモニタリング体制を堅牢に構築した上で、
テストの必要性も含めて、製作も運用も業務部に任せるのが本来の使い方だと思うが >>235
ありがとうございます
>>186とも関連してて、別案もあるし htmlから別途引っこ抜くやり方もわかっているんですが、学習も兼ねてるのであくまでスクレイピング一発でできないかということです
<value attr='value'>
みたいにメタデータ抽出に追記できたらいいのになって感じです
(上記書いてみたけどだめでした。エラーにもならなかったのが(@@)ですが) >>247
本来の使い方は使い捨てツールだよ
プログラマでいうと使い捨てのスクリプトとかワンライナーがイメージとして近い
しっかり管理するなら専門家に外注するべき(そして専門家が使いにくいのでrpa は採用しない) >>212
>>235
社内から朗報が届きました
各列取得方式(?)にして、
attr='text'
を
attr='value'
でいけるとのこと
あの位置に書かれてるのが影響するとは想像できんかった…悔しい(T_T)
テーブル一括の場合のに追記ではできなかったそう(別の書き方があるかも) uipath、201908にアップデートされた。
イミディエイトが追加…されたのかな?
前からあった? >>241
>>245
なるほどー、テストしっかりやるんだね そうすると情シスなり趣味グラマなりスキル持ちのみが作成して、末端に使わせる形なのかな? 単に個人的に気にしてるだけ? 作成からテストまで末端にやらせる?(だとしたら内部統制がすごいな)
要はどういう運用体制なんだろう? どこにRPAのメリットを見出してるのか気になる コーティングが楽って書いてくれてるけど、ここで話題になるのって(スキル持ちにとっては)htmlの要素指定くらいだよね >>251
あと、vbTabとかが補完候補に出るね
しかしいきなり更新して
不具合出たら企業の担当はたまらんな
商用のは止められるのかな?
まだPOCの段階だからこういうことされると心配 >>237
よし、じゃあ正しいRPAのテストの仕方を詳しく書いてみてくれ
添削してやろう >>253
商用は止められます
うちは、バージョンアップで動かなると困るという理由のみで 18.3で固定確定、新機能放棄まで明言された。
ありえん… orz >>237
なんや外注さんか
ROAは受注すんなよ >>254
横からすまんが
うちのテストのやり方を添削してくれ
実行環境で1回動かして終わり
真面目に、これ プログラミング環境ならバージョン固定もアップデートも簡単なのになあ
自動テストエコシステムが充実してるからバージョンアップ時のバグも素早くリリース前に検知できる >>257
うちもそうですね
今のところ直接お金に関わらない部分しかやってないからかも
そもそもuipathで自動テストどうやるか誰も知らないw WinActorの試験を受けさせられる事になったから
過去問の電子書籍買ったらオンラインでしか読めなくて
テキスト検索もできないゴミだった。 >>254
ほとんど書いた通りだけど
・パターンテスト
絶対にやる
システムを触ると場合、データによってポップアップの表示とか、ボタンの活性/非活性などので挙動を変える必要があるので
その辺りが想定通り動くか見ておく
パターン自体が多かったり、ページ送りとかのロジックも見る場合は
担当システムの保守チームに頭下げて良い感じのデータを見繕って貰うかデータをセットアップして貰う
・異常系
入力元データがどうやって作られるかによる
@人の手で作成/または編集がする場合
→RPA側でチェック処理を実装しておかないと、人のミスで止まるのでチェック処理の実装&テスト対象になる
A既存システムから吐き出されたデータを直接入力する場合
→既存システム側でチェック処理自体は行われているはずなので、テストの対象外で良い
・安定性テスト
これはRPAやるなら絶対やった方が良い
できるだけデータパターンを用意してひたすら動かす
動的な待機処理をちゃんと入れてない場合、ちょっとした遅延が発生するだけで上手く動作せずに異常終了……
というのがザラに起きる(待機時間を固定ディレイばかりにしていても、待機時間が足りずに誤動作したり)
(特にショートカットキーを使って操作する場合、無条件でキー操作は発火しちゃうので
アプリの状態によっては空振りが発生する)
最低でも5回、できれば10回ぐらいは動かして完遂するか見た方が良い
動作用の端末を用意してひたすら動かしながら後は放置できるとベスト ■ このスレッドは過去ログ倉庫に格納されています