【Pega】Pega8.5からCreate Stageができた
はじめに
PegaでCaseを作成すると、もれなくCreate Stageがデフォルトで作成されるようになったようです。
Capture initial data faster with the default Create stage (8.5) | Pega
上記公式サイトで言及されている通り、ケースのプロセスが開始される前に必要なデータをユーザが入力できるようです。
ケースライフサイクルが開始される前にユーザが入力できるビューを提供してくれるようですね。
ちょっといろいろ触ってみたのでブログに書いてみます。
さわってみた
Pega8.6でケース作成
DevStudioにて、TestCaseというケースタイプを作成します。
作成すると、デフォルトでCreateステージができています。
この状態でケース起票をしてみましょう。
まだSectionとか作成していないですが、下記のようなモーダルウィンドウが出てきます。
Cancelボタン、または右上の×ボタンを押下すると、保存して閉じるのか、このまま作業をつつけるのか、削除するのか選択できるようですね。
Save and closeボタンを押下すると、インスタンスが作成され、MyWorklistに表示されます。
Goボタンを押下すると、同様の入力画面が表示されますが、モーダルではなく、通常のケース入力画面になるようです。
※もうケース作成されているのにCreateボタンなんですね。まぁ個人的にはどうでも良いのですが、画面に変な拘りを持つ人は指摘しそうですね。
この画面からCancelボタンを押下すると、再度警告画面が表示されます。
Deleteボタンを押下してみましょう。
MyWorkListからは消えますが・・・
インスタンスは作成されているようです。
Resolved-Canceledというステータスになるようです。
ケースインスタンスはいつできるの？
ケース作成したらできます。
※↓このモーダルが表示されたらケースインスタンスは作成されている。
てっきり、このCreateStageはケースのライフサイクル開始前にデータを入力できるため、と公式サイトに記載があったため、CreateStageでCreateボタンを押す、もしくは明示的に保存をしない限りインスタンスは作成されないと予想していましたが、ケース作成したらインスタンスはできるようです。
Pegaのライセンス料を決める要因の一つに年間ケース数があるので、もしかしたらライセンス料節約につながるのかと思いきやそういうわけではないです。なんのためにあるんだこの機能…
プロセスルール、セクションルールを見てみた
次に、ケースタイプルールを見てみましょう。
Stageタブですが、8.5より前のバージョンと違い、Initialization Stageというのが追加されていますね。
Createステージの削除はできませんが、プロセスはゴミ箱アイコンがあるので削除できそうです。
試しに、Automatically Lanched processesを削除して保存してみましょう
削除すると、当たり前ですがモーダルは表示されず、ケースが作成されました。
次に、Automatically Lanched processesをもとにもどして、Processルールを見てみます。
Createステージのプロセスは、ScreenFlowになるようです。
FlowActionルールを見てみましたが、FlowAction自体はそこまで特徴はありませんでした。
次に、Createセクションルールを見てみます。
モーダル内部の項目を定義するだけのようです。
Cancelボタン等はどこのルールなんでしょうか？
Live UIで確認してみます。
pyCaseActionAreaButtonsセクションルールのようです。
以前のプロジェクトでもこのルールにはお世話になっており、オーバーライドを良くしていましたが、別物ですね。
まぁ、RSのバージョンが全然違うので当たり前ですかね。
キャンセルボタンと思われるボタンに、保存して閉じるのか、このまま作業をつつけるのか、削除するのかの選択ができる画面を表示させるためのLocalActionが設定されていました。
所感
正直不要な機能では？と思ってしまった。
CreateStageでケースインスタンスが作成されなかったらまだ納得だったけど、結局インスタンス作られるんかーい、という感じ。
また8.4以前のPega開発者からすると戸惑うかもしれませんね。
以上！
【Pega】Workgroup, Workqueue, OrganizationUnit, Workpartyって結局なんなん？
- はじめに
- OrganizationUnit
- Workgroup
- Workqueue (Workbasket)
- Workparty
- OrganizationUnit, Workgroup, Workqueueの関係性
- 結局どう使うの？
はじめに
Pegaの世界では、ユーザをグループ分けする仕組みがいくつか存在しますが、名前が似ていたり、各仕組の関係性がちょっとわかりにくかったりするので、整理してみました。
- Organization, Division, Unit
- Workgroup
- Workqueue (Workbasket)
- Workparty
OrganizationUnit
組織的な階層を管理するための仕組み。
Organization、Division、Unitという階層構造を持たせることができます。
例えば、以下のような設定ができます。
Organization・・・〇〇会社
↑ (従属)
Division・・・営業X部
↑ (従属)
Unit・・・YY課
Unitは、配下Unitを作成できます。
こんな感じです。↓
Pegaのユーザは、必ず特定のUnitに属します。
Workgroup
組織的な階層（上記で紹介したOrganizationUnit）とは別にグループ分けを行うための仕組み。
例えば、営業部A課に属しているAさんと、事務統括部B課に属しているBさんが、「新人担当グループ」にも属している、というように、Unitを跨いだグループ分けを表すのにWorkgroupが使えます。
Pegaのユーザは、0個以上のWorkgroupに属することが可能です。
Workqueue (Workbasket)
グループ分けに使われるものではありません。ケースアサインに使用されるものとなります。
Pegaの世界では、業務フローの一部分を抽象化したものケースと呼んでいて、特定のユーザにフロー内のタスクを割り当てることができます。
特定のユーザへの割当だけでなく、チームに対して割り当てることもできます。チーム全員が見れる未決箱、みたいなものをイメージするとわかりやすいと思います。
この「チーム全員が見れる未決箱」というのをWorkqueueと言います。以前のバージョンではWorkbasketと読んでいたようです。
Pegaのユーザは、0個以上のWorkqueueに属することが可能です。
Workparty
ケースのライフサイクルの任意のタイミングで、通知を行いたい連絡先情報を持つための仕組みであり、上記三つのようなユーザを分ける為の仕組みではありません。
Pega Academyだと、ユーザが申込完了したらマネージャーとかに通知送ることができるぜ的なことが書いてあった気がしますが、連絡先情報を格納できる仕組みなので、通知以外にも、参照権限のコントロールに使うなどいろいろ応用はできます。
OrganizationUnit, Workgroup, Workqueueの関係性
- Organization, Division, Unitの関係性については上記に記載した通りです。
- Unitについては多重階層を構成できるので、自身に対してリレーションを記載しています。
- Operatorは、1つのUnit、1つのWorkGroupに属する必要があります。また、必須ではありませんが複数のWorkqueueに属することができます。
※Workgroupの登録は複数できますがラジオボタンで選択する必要があるので実質一つのようです。ただデータの関連という意味では複数登録できるのでこのような記載にしています。
- WorkqueueはUnitとWorkgroupを紐づける必要があります。下記スクショのOrganization欄の部分が該当部分です。
- Workgroupの方にもひとつのWorkqueueを登録する必要があります。Pegaの説明ではこのWorkgroupがケース割り当てを探しにいくWorkqueueを指定するようですが、設計した処理の中で使わないのであれば登録値はなんでもよいと思います。
結局どう使うの？
作り方によるかな、と思います。
WorkqueueとWorkgroupの関係性がN:Nなのが少々ややこしいのですが、どう使うかは自由なので、それは要件にあうように設計すればよいかなと思います。
Pegaでアプリを作るということであれば、「あなたのタスク一覧」「未決箱内タスク一覧」のような一覧画面を作成するかと思います。その一覧を表示するロジックは自由に設計できるので、そこで要件通りの表示ができるようにこの仕組みを使えばよいと思います。（例えば、ユーザが属しているUnitからそのUnitに一致するWorkqueueを検索し、そのWorkqueueにアサインされているケースを表示する、とか。この場合はWorkgroupを全く使わないですがユーザは必ずどこかのWorkgroupに属さないといけないので、適当なworkgroupを作成しておいて全ユーザはそこに属するよう設定するようにすればよいと思います。）
同様に、ケースのルーティングも自由に設計できるので要件に合わせて使えばよいと思います。（ケースで回覧先と指定されたWorkGroupからWorkqueueを探す、OrganizationUnitからWorkqueueを探す等）
SQL Server で別サーバにバックアップしたい
やりたかったこと
Microsoft SQL Serverのバックアップを別ホストに保存したい。
開発サーバでの話です。
私が使っている開発サーバ(Windows Server 2019)は、用途別に複数の開発環境を仮想環境(Hyper-V)として稼働させています。ホスト側には開発環境を作っていません。
各仮想環境にはDBMSとしてSQL Serverを導入していて、DBのバックアップをホスト環境に接続している外部ストレージに保存したいなー、というのが今回の目的です。
前提条件
- バックアップはSQL Serverのメンテナンスプランで実施したい。
- メンテンナンスプランはSQL Server Agentサービスで稼働させる。
- メンテナンスプランでのバックアップ保存先に、別ホストのパスを指定したい。
- わけあって、保存先にしたいホストと仮想環境との共通ユーザ(例えばアクティブディレクトリやワークグループ配下のユーザ)は作成できない。
- サーバのログインIDとして個人を識別できるようにしろ、という会社側のポリシーに従うため、サーバは会社ドメインに属するようにして、社員IDでログイン可になるように設定。しかし上記4に記載した弊害が発生。※社員管理用のドメインには気軽にユーザ作成なんぞ出来ません・・・
SQL Server のメンテナンスプランは、デフォルトの設定だとSQL Server Agentサービスの実行ユーザで実施されることになります。
そのため、SQL Server Agentサービスの実行ユーザが、保存先への書き込み権限を保持していれば良いわけです。
しかし、上記4に記載した通り、仮想環境とホスト環境で共通したユーザを作成できないので、どうしたものかと悩んでしまいました。
解決方法
仮想環境のコンピュータ名に、保存先ディレクトリに対する書き込み権限を付与する。
解説
仮想環境がホストのフォルダにアクセスできるように、バックアップ先として指定したいフォルダを共有化します。
その際に、アクセス許可を仮想環境のコンピューター名に対して付与します。
ただし、この設定はホストも仮想環境も同じドメインに属している必要があります。手元の環境で実験した際、同じドメインに属していないとそもそもコンピュータ名に権限を与えることはできませんでした。
※ホスト名でアクセス許可を付与した場合、システムアカウントでのみ共有フォルダにアクセスできるようになるようです。SQL Serverのメンテナンスプランを動かすユーザは、SQL Server Agentのユーザであり、デフォルトだとシステムアカウントとなります。そのため、この設定で仮想マシンからホストのフォルダにメンテナンスプランでバックアップを取ることができるわけです。
手順
共有化したいフォルダのプロパティを開き、「詳細な共有」 をクリック
「アクセス許可」をクリック
「オブジェクトの種類」をクリックし
「コンピューター」にチェック。
こうすることで、コンピューター名をアクセス許可の設定に追加することができます。
試しに、「TESTSERVER2022」を追加してみました。
これで共有の設定は終了ですが、これだけだと「TESTSERVER2022」から書き込みできませんので、セキュリティ設定を変更します。
共有化したいフォルダのプロパティに戻り、「セキュリティ」タブからアクセス許可を編集します。
「編集」ボタン押下後の操作は上記の共有化設定と同じなので割愛します。
このようにコンピュータ名を追加できたので、アクセス許可で必要な権限を付与します。
以上で、指定したコンピューターに対してアクセス許可を与えることができました。
はじめまして。
自己紹介
はじめまして。
SIerに勤めるmobキャラ、迷走するSEと申します。
会社内の現チームでは、なぜか技術に詳しい人というポジションになりつつありますが、正直レベルが低くく、このままだと自分も含め堕落していくんじゃないかな～と漠然と思っています。
そんな迷走状態を抜け出そうとしている、迷走中SEです。
よろしくお願いいたします。
このブログでやること
迷走状態を脱するため、気になることはちゃんと勉強しようと思います。
そしてしっかり覚える為に、勉強した内容をアウトプットする場、として当ブログを利用しようと思います。
同じ内容で悩んでいる方にも見て頂けるようなブログになれるよう頑張っていきます。
今までやってきたこと
- 1年目
研修でJavaを学習。 - 2～5年目
某金融システム構築プロジェクト(サグラダファミリアではありません)に参画。
設計書作成、レビュー、顧客システム担当とのコミュニケーション、リリース、障害対応等、一通り経験しました。
1年目のJavaは半分くらい忘れましたが、多くの方と触れ合うことができて結構楽しかったです。 - 5年目～現在
Pegaシステム社のPega Platformを用いたソリューションを提供するチームにいます。 新規開発をやったり、保守で小規模開発をやったりしています。 アプリの設計、開発もやりますが、インフラの設計、構築作業もやってます。
