2022.05.17バージョン更新-製品5月更新の概要
1.今回の製品能力最適化マップ
私たちは4月にいくつかの製品の基礎能力のアップグレードを行い、重点をカバーした安定性、パフォーマンス、機能体験関連。

2.製品最適化更新:
2.1ビジネス関連ルールの最適化
シナリオ1: ログリストの遅延のない表示
業務ルールの内容がログリストの時効に表示されます
最適化前 | 最適化後 |
表示に遅れがあり、2回目か数分後に表示されます ![]() | ログには、実行されたものがすぐに表示されます ![]() |
シナリオ2: 失敗したビジネスルールは再試行をサポートしています
失敗ルールは再試行をサポートしています
最適化前 | 最適化後 |
失敗後は再試行できません ![]() | 失敗したタスクの場合、ビジネス・ルール・タスクは再試行ボタンをサポートし、成功すると現在のこの件のログが自動的に更新されます ![]() |
シーン3: ワンクリックでターゲットインスタンスを表示します
ワンクリックでターゲットインスタンスのページ変更明細を表示します
最適化前 | 最適化後 |
ビジネス関連ルールでは、ターゲットテーブルの結果表示はサポートされていません ![]() | 業務関連ルールでは、ターゲットテーブルの結果表示はサポートされていません ターゲットテーブルに自動的にジャンプ-詳細ページ-変更記録、自動トリガーをサポートする関連する使用説明 ![]() ![]() |
シナリオ4: ログは未実行タスクの公開をサポートしています
実行ログのサポート未成功実行明細
最適化前 | 最適化後 |
複数業務ルールグループの途中のノードが失敗した後、後続ノードの業務ルールが見えず、再試行はサポートされていません ![]() | ビジネスルールの非同期実行ステータス: 成功と失敗を除いて、「未実行」ステータスを追加し、ルールの実行番号を明らかにして、ビジネスのピークを解決するステータスの自己調査。再試行ボタンと連携して、失敗したタスクリストを一括再実行できます。 ![]() |
シーン5: 作業通知の邪魔防止最適化
作業通知の最適化
最適化前 | 最適化後 |
一部の無効な失敗作業通知が多すぎて、お客様に一部の場面で迷惑をかけすぎてしまう | システムのジッタによる一括通知が最適化され (自動再試行に合わせて成功) 、お客様を邪魔しない 同時に、お客様はビジネスルールの実行ログで自主的に表示できます ![]() |
シナリオ6: 異常タスクの後続操作の終了をサポート
途中タスクノードが失敗した後、後続タスクの終了をサポートできます
最適化前 | 最適化後 |
複数業務ルールグループの途中のノードが失敗すると、スイッチを制御できません ![]() | 複数業務ルールグループの途中のノードが失敗した後、サポートスイッチは後続ルールグループの実行を継続する必要があるかどうかを制御する (後続タスクの終了は本来サポートされていない)。 ![]() |
2.2インポート/エクスポートの最適化
シナリオ1:「インポート・エクスポート」のパフォーマンスが大幅に向上しました
インポート手順:
- 当前状态:普通のフォームは完全で、バージョン制限がなく、新旧のストレージアプリケーションがサポートしています
- 通常フォームのインポート性能の向上🔝 32倍(インポートは5000件を例にしています)
- フローフォーム関連シーンは一時的に上書きされていません一括開始プロセスは引き続き最適化されます
エクスポートの説明:
- 当前状态:完全に公開されました
- 通常/フローフォームのエクスポートのパフォーマンスが向上しました🔝 24倍(エクスポートは例として5000件)
注意:
- インポート/エクスポートの最適化は1.0と2.0のアプリケーションをカバーしていない
- 通常のフォームとビジネス関連ルールは、ビジネス関連ルールの影響でインポート/エクスポートが遅くなります。
シナリオ2:「インポート/エクスポート」は、一般的なインポート失敗率が高く、データが正確でない問題を解決します
次の一般的なシナリオの問題を修正して解決します
- システムアーキテクチャのジッタ/タイムアウトなどによるインポート失敗の問題
- 大容量一括インポートタイムアウトによる一部のインスタンスのインポート失敗の問題
- システムアーキテクチャのジッタ/タイムアウトなどの原因でユーザーが一括インポートしたデータは削除されたが、データ管理ページに問題がある
- 一括インポート時にデータが重複する問題を修正します
2.3プロセス関連機能の最適化
シーン1:「プロセス返品」新規設定モード
最適化前 | 最適化後 |
承認返品の発起人は階層的な承認が必要で、小さな変更点のユーザーは現在の承認者ノードに迅速に戻りたいが、実現できない | 構成化により、プロセス設計者はノードのロールバック制御を行うことができ、プロセスが効率的になりますリフト90% |
|
![]() |
シナリオ2:「プロセス表示/コメント機能」
最適化前 | 最適化後 |
🚫プロセス参加者は、所属するノードの承認詳細のみを表示できます 🚫プラットフォーム/アプリ管理者のみコメント権限を持っています 🚫コメントエリアの添付ファイル数は2つに制限されています 🚫コメントはppt形式の添付ファイルのアップロードをサポートしていません | ✅ 查看及评论权限:プロセス参加者は、プロセスの開始後にプロセスを表示でき、すべての参加者がコメントを表示および送信する権限を持っています ✅ 评论中附件数量上限提升:5個に引き上げる ✅ 新增附件种类:コメントエリアの添付ファイルは、元のフォーマットに基づいてpptフォーマットのサポートを追加します |
2.4公式の最適化が望ましい
シーン1: フローフォームのロールバック時のexist関数の最適化
プロセスフォームの承認フローは、取り消しと返品をサポートできます。この時点で、フォームのデータはすでにシステムにダウンしています。
Exist ()関数の役割: フォームデータと落庫データに存在するかどうかを検証します。
最適化前 | 最適化後 |
取り消しまたは差し戻し後の「プロセスフォーム再送信」は、exist検出ルールを起動します ![]() ![]() | スマート検査が必要です。返品後の「プロセスフォーム再送信」の場合、exist検査ルールは自動的にスキップされます ![]() |
シーン2: フォームの送信、保存時に、実行が完了していない式の計算を検出します
最適化前 | 最適化後 |
フォームが保存または送信操作を行うまで、実行中の式計算は検出されません | 実行中の数式計算がある場合は、ユーザーにプロンプトが表示されます ![]() ![]() |
2.5統合 & 自動化機能の最適化
シナリオ1: 自動化された連続トリガ能力の向上
複数のフォームには統合自動化された更新トリガが配置されており、3層連動のデータ連続トリガに対応している。
最適化前 | 最適化後 |
Aフォーム>> bフォーム ![]() | Aフォーム>> bフォーム>> cフォーム>> dフォーム ![]() 上限説明: 一回の連続ループトリガで、最大影響500条統合自動化インスタンス |
シナリオ2:「統合 & 自動化」機能と「ビジネス関連ルール」ステータスの相互運用
- 「統合 & 自動化」と「ビジネス関連ルール」は、適切なrpa実装形式です。
- 「統合 & 自動化」は「業務関連ルール」のより使いやすい可視化アップグレード版として、業務関連ルールをカバーするほか、より多くのトリガーイベントとデータ連動能力をサポートしている将来的には、主に推進すべきrpa機能案となる。
- 今回の「ビジネス関連ルール」機能の最適化では、「統合 & 自動化」機能の要約情報が追加され、フォーム・デザイナーに公開され、作成リンクにガイドの説明も追加されました。
最適化前 | 最適化後 |
フォーム: 「業務関連ルール」が設定されています。 「統合 & 自動化」も設定されており、「ビジネス関連ルール」設定で「統合 & 自動化」に関する情報を見ることはできません2種類以上のタスクがトリガーされた実行タイミングを効果的に制御できない | 同じフォームが自動参照に統合されている場合、情報の相互運用が可能です。今後、同じフォームで2セットのrpa (「ビジネス関連ルール」と「統合 & 自動化」) 機能の混在使用は推奨されません。「統合 & 自動化」機能で関連するニーズを実現することをお勧めします。 ![]() |
2.6 openapiインターフェイスで新しい
ホッチキス開放プラットフォームは3つ追加して開放インターフェースに乗るべきである
シナリオ1: プロセスのすべてのコメントを照会します
インタフェースの詳細は、をクリックして確認してください一括照会はフォームインスタンスのコメントに合うべきです
シナリオ2: プロセスの変更記録を照会する
インタフェースの詳細は、をクリックして確認してください承認記録の取得
シナリオ3: 承認タスクの一括実行
インタフェースの詳細は、をクリックして確認してください一括実行には承認タスクが必要です
2.7関連フォームコンポーネントのアップグレード
- 関連フォームは、値を割り当てることができ、関連フォームに入力することができ、数式/ビジネスルール内での使用をサポートします。
- データ連動条件ルールは、数値コンポーネントに対して論理子より大きい、小さい
最適化前 | 最適化後 |
データ入力、データ関連付けなどのすべての連動性「関連フォームフィールド」は使用できません関連フォームコンポーネントと他のフォームのテキストフィールドは「等しい」接続を確立できません、同じフィールドにテキストコンポーネントを追加する必要があり、関連するフォームコンポーネントが入力すると、多くのデータが冗長になります。 | ✅関連フォームが開きますデータ入力後、充填条件の設定、現在のフォームフィールド内で「現在のフォームの関連フォームコンポーネント」への選択をサポートしています関連フォーム設定を参照する主な情報フィールド ![]() ✅ データ連動コンポーネントのサポート、現在のフォームの条件ルール値フィールドは、現在のフォームの関連フォームコンポーネントの選択をサポートしています関連フォーム設定を参照する主な情報フィールド ![]() ✅ 数式内関連付けられたフォームフィールドを参照できます (値のメタデータタイプは配列タイプです) ✅ ビジネスルール内は関連フォームフィールドを参照できます 既存の式を通過することでGet arrayitem/Getオブジェクトフィールド関連フォームフィールドを直接参照します ![]() |
2.8プラットフォームの基礎能力の最適化
シーン1: ページナビゲーションの最適化を適用する
最適化前 | 最適化後 |
🚫アプリページナビゲーションはレベル2のみをサポートしています 🚫アクセス状態サブメニューには権限がありませんメインメニューはまだ表示されています ![]() | ✅アプリページナビゲーションサポートレベル3 ✅アクセス状態サブメニューに権限がないとメインメニューが連動して非表示になります ![]() |
シーン2: 添付ファイルを削除してストレージ容量を解放する
最適化前 | 最適化後 |
🚫アップロードした添付ファイルは、削除後、ストレージ容量が解放されません ![]() | ✅添付ファイル削除後のストレージ容量の解放 関連する添付ファイルポイント:
|
添付ファイル保存統計リアルタイム性の説明:
添付ファイルのアップロード、添付ファイルの削除がリリースされ、容量統計は約1時間程度の遅延がある
ストレージ容量リリース範囲の説明:
- 機能リリース (2022.5.30) 後にアップロードした添付ファイルを削除すると、自動的にストレージ容量が解放されます
- 機能公開 (2022.5.30)前にアップロードした添付ファイルは、機能公開後に削除します
- アプリケーションを削除すると、アプリケーションに含まれる添付ファイルのストレージ容量が自動的に解放されます
- フォームの削除、インスタンスデータの削除、添付ファイルの直接削除は、リリースをサポートしていません
- 機能リリース (2022.5.30)前に削除された添付ファイルは、ストレージ容量の解放をサポートしていません
2.9既知のバグ修正
修复統合 & 自動化「データの追加」ノードは、使用時にフィールドに値がない場合、デフォルトでコンポーネントが一意に識別するバグを渡します。
修复統合 & 自動化「承認の開始」ノードに必要なフィールドがプロセス開始ノードの構成と一致しないバグ。
修复モバイル側プロセスフォームが送信されると、システムは自動的に送信されたバグを繰り返します。
修复単一行テキスト、複数行テキスト、詳細アドレスのフォーカスフィルタリング前後のスペースは、フィールドにスペースがないようにし、データ連動ができない。
--------- 最新情報を入手して、私たちに注目してください ---------


























