クラウド・レディネス / Oracle Field Service Cloud
新機能
Expand All


  1. 更新23D
  1. 改訂履歴
  2. 概要
  3. 機能のサマリー
  4. フィールド・サービス
    1. 管理
        1. アクティビティ・バンドル・ルール
        2. アクティビティ・トラベル・キーの自動検出
    2. コア・アプリケーション
        1. 環境をリフレッシュするためのインスタンスの再作成の名前変更
        2. チームワーク - 在庫インストールを元に戻す処理のストレージ・ロケーション選択
        3. 証明書の更新によるSAMLメタデータ更新のアラート
    3. 統合
        1. Fusionからの品目カタログの直接使用
    4. ルーティング
        1. 一括ルーティングでアクティビティ開始日よりX日前の在庫が必要
  6. 重要な処理および考慮事項

更新23D

改訂履歴

本書は、既存の項の変更と、新規情報の追加に伴って、今後も引き続き更新されます。 これまでの更新内容は次の表のとおりです。

日付 モジュール 機能 ノート
2023年10月23日     初版作成。

概要

アイデアはありますか。

私たちはここにいて、聞いています。 クラウド・サービスを改善する方法に関する提案がございましたら、一歩先を行き、オラクルに伝えてください。 Oracle Customer ConnectのIdeas Labなど、アイデアを送信するにはいくつかの方法があります。 機能名の後にこのアイコンが表示される場合は、アイデアの1つが提供されたことを意味します。

フィードバックをお寄せください

本書の内容改善のため、ご意見やご提案をお待ちしております。 フィードバックは、oracle_fusion_applications_help_ww_grp@oracle.comまでお送りください。

免責事項

この文書に記載された情報には、オラクルの製品開発プランに関する説明文が含まれていることがあります。 オラクルの製品開発プランと、今後の製品リリースの本質および時期に対し、様々な要因が大きく影響を及ぼします。 したがって、この情報はあくまで情報として提供されるものであり、マテリアルやコード、機能を提供することのコミットメント(確約)ではないため、購買決定を行う際の判断材料になさらないでください。 記載されている機能の開発、リリースおよび時期については、オラクルの単独の裁量により決定されます。

この情報は、オラクルおよびその子会社や関連会社との契約を構成するものではありません。 特にこの情報についてオラクルは一切の責任を負いかねます。 詳細は、法律上の注意点および使用条件を参照してください。

機能のサマリー

列の定義:

レポート = 新規または変更済の、オラクル社提供の実行可能レポート。

UIまたはプロセスベース: 小規模 = これらのUIまたはプロセスベースの機能は、通常、フィールド、検証またはプログラムのマイナーな変更で構成されています。 したがって、ユーザーに対する潜在的な影響は最小になります。

UIまたはプロセスベース: 大規模* = これらのUIまたはプロセスベースの機能には、より複雑な設計が含まれます。 したがって、ユーザーに及ぼす影響は大きくなります。

無効状態で提供される機能 = エンド・ユーザーがこれらの機能を使用できるようにするには、処理が必要です。 これらの機能は提供時には使用不可になっているため、機能を使用可能にするかどうかおよび使用可能にする時期を選択してください。 たとえば、a) 新しいまたは展開されたBIサブジェクト領域は最初にレポートに組み込む必要があり、b) 新しいWebサービスを利用するには統合が必要になり、c) ユーザーが機能にアクセスできるようにするには、それらの機能をユーザー・ロールに割り当てる必要があります。

エンド・ユーザーがすぐに使用可能
(機能が使用可能な状態で提供)

レポートと小規模UIまたはプロセスベースの新機能が更新後にユーザーに与える影響は最小限です。 したがって、顧客受入テストでは、大規模UIまたはプロセスベース*の新機能に焦点を当てる必要があります。

エンド・ユーザーの使用前に顧客による処理が必要
(機能は使用不可として提供されます)

これらの機能を使用可能にするために処理が必要になるため、中断されません。 利用することを選択する際には、テストと展開のタイミングを設定します。

機能

レポート

UIまたは
プロセスベース:
小規模

UIまたは
プロセスベース:
大規模*

フィールド・サービス

管理

アクティビティ・バンドル・ルール

アクティビティ・トラベル・キーの自動検出

コア・アプリケーション

環境をリフレッシュするためのインスタンスの再作成の名前変更

チームワーク - 在庫インストールを元に戻す処理の保管ロケーション選択

証明書の更新によるSAMLメタデータ更新のアラート

統合

Fusionからの品目カタログの直接使用

ルーティング

一括ルーティングでアクティビティ開始日よりX日前の在庫が必要

>>重要な処理および考慮事項についてはクリック

フィールド・サービス

管理

アクティビティ・バンドル・ルール

この機能を使用すると、顧客は複数のバンドル・ルールを構成できます。このルールは、次の2つの目的で使用できます:

  • 情報交換
  • ワークロード最適化

特定のバンドル・ルールを介していずれかの目標を達成することも、両方の目的に同時に使用することもできます。

構成済ルールに基づいて、関連するアクティビティが自動的に識別され、それらの間でデータが共有されるか、またはアクティビティ割当が最適化されます。

この機能では、構成領域、ユーザー・インタフェースおよびREST APIの変更が導入され、構成からユーザー・アクション、および外部システムとの統合まで一貫性が保たれます。

用語

次の内容では、この機能の主な用語について説明します。

バンドル・ルール

バンドル・キー、フォームおよびワークロード最適化パラメータの組合せにより、アプリケーションは次のことを行います:

  • 関連アクティビティのビルド・バンドル(グループ)
  • バンドルのアクティビティ間で必要なデータを識別して共有
  • フィールド・リソースのワークロードを最適化

バンドル・キー

関連アクティビティを自動的に定義および結合するためにアプリケーションで使用されるシステム・フィールドとプロパティの組合せ。

関連付けられたフォーム

同じバンドルから異なるアクティビティを処理している間に、様々なユーザーが取得した一連のフォームが、バンドル内のすべてのアクティビティで使用可能になります。

仕組み

情報交換について

様々なユーザーが収集した関連フォームのデータは、ルールにバンドルされているすべてのアクティビティ(アクティビティ・セグメント)で使用可能になります。 情報は、様々な日またはシフトに割り当てられたアクティビティまたはセグメントに使用できます。

ワークロードの最適化

アプリケーションは、同じ日に同じ技術者に割り当てるアクティビティのバンドルを将来作成します。 これは、ルーティングによる自動スケジューリングを使用するか、割当アシスタントを介してアクティビティを手動で割り当てることによって実行できます。 これにより、同じサイト・アクティビティの所要時間を短縮し、リソースの使用率全体を改善できます。

両方の目的に合わせて

両方の目的でアクティビティ・バンドルを同時に使用できます。 同じサイト/同じ技術者/同じ日の概念が適用されます。収集されたフォームの結果データは、ルールによってバンドルされたアクティビティに対して公開されますが、同じ技術者および同じ日に割り当てられます。

構成方法

新しい「バンドル・ルール」画面

構成領域からアクセスできる新しいバンドル・ルール画面があり、バンドル・ルールが構成され、それらのパラメータを表示できます。 この画面へのアクセス・レベルは、表示条件によって指示されます - 'ReadWrite'アクセス権を持つユーザーはバンドル・ルールを作成および更新できますが、'ReadOnly'アクセス権を持つユーザーはルールの構成設定のみを表示できます。

各ルールは、最も重要なパラメータを含むタイルとして画面に表示されます:

  • すべてのルールの名前、ラベルおよびステータス
  • 情報交換に使用されるルールに使用するフォームの数
  • バンドルされたアクティビティの期間。ワークロードの最適化に使用されるルール

 

ルールの追加/編集

新しいバンドル・ルールを作成するには、バンドル・ルールの追加ボタンをクリックします。 バンドル・ルールの詳細を追加するポップアップ・ウィンドウが開きます。

バンドル・ルールを編集するには、ルールのキー詳細を示すタイルをクリックするか、タイルのコンテキスト・メニューから編集アイテムを選択します。 バンドル・ルール構成画面が開きます。

一般設定

新しいバンドル・ルールを追加する場合は、名前とラベルを定義し、ステータス(アクティブまたは非アクティブ)を選択する必要があります。

アプリケーションでは、ステータスがアクティブのルールのバンドルのみが計算され、ステータスが非アクティブのルールは処理されません。

バンドル・キー

バンドル・ルール・セクションの下のキーの追加をクリックして、フィールドまたはプロパティをバンドル・キーとして追加します。 バンドル・キーを追加する画面が表示されます。

次の製品フィールドをバンドル・キーとして選択できます:

  • appt_number
  • caddress
  • ccity
  • czip
  • customer_number
  • aworktype

'string'、'enum'および'integer'タイプのプロパティは、バンドル・キーとして選択することもできます。

短いフィールドの値全体を取得チェック・ボックスは、バンドル・キーとして選択されたフィールド/プロパティの値から取得される最大文字数制限を設定します。

長さは、チェックボックスの選択を解除し、'長さ'パラメータを更新することで変更できます。 最大長は、バンドル・キーとして選択されたフィールド/プロパティの長さです。

キーの詳細を定義したら、追加ボタンをクリックして新しいバンドル・キーを作成します。

ノート: 大/小文字を区別しない関数は、すべての新しいバンドル・キーにデフォルトで適用されます。

各キーとともに表示される2つのアイコンにより、ユーザーはそれらを編集または削除できます。

情報交換用のバンドル・ルールの構成

関連フォームの構成

情報交換にバンドル・キーを使用する場合は、「情報交換に使用」>「関連フォーム」セクションで「フォームの追加」をクリックして、共有するフォームを選択できます。 フォームを追加する画面が開きます。

フォームを選択するには、「フォーム」フィールドをクリックし、リストからフォームを選択します。 このリストは、「フォームズ&プラグイン」画面で構成されたフォームを反映しています。

フォームを選択したら、追加ボタンをクリックして、バンドル・ルールに追加します。

フォームを削除するには、フォームの横に表示されている削除アイコンをクリックします。

ワークロード最適化のバンドル・ルールの構成

同じサイト・アクティビティを訪問にグループ化チェック・ボックスをクリックして、このルールをワークロードの最適化に使用するように指定します。 次に、訪問でのアクティビティの最小/最大所要時間の比率を定義します。 このパラメータは、同じサイト・アクティビティを訪問にグループ化が有効になっている場合に表示されます。

その他の訪問の変更

訪問構成の移行

訪問バンドル・キーの構成は、ビジネス・ルール画面からアクティビティ・バンドル画面に移行されます。 これで、「訪問」バンドル・ルールとして表示されます。

以前に訪問バンドル・キーが構成されている場合は、訪問ルールがアクティブになり、次の非推奨および削除の項に記載されているパラメータを含め、すべてのパラメータが保持されます。 非推奨および削除された機能を示すバンドル・キーは更新できませんが、これらのキーは削除できます。

23Dでの非推奨および削除

次の機能は非推奨になり、23Dで削除されます:

1) バンドル・キーに対して次の機能を構成する機能:

  • 大/小文字を区別
  • 大/小文字を区別しない
  • 最初の単語の大/小文字を区別
  • 最初の単語の大/小文字を区別しない

2)ルールの追加/編集の項で説明されている以外の製品フィールドを構成する機能。

訪問の自動作成

訪問ルールは、無効ステータスで自動的に作成され、次のキーで事前構成されます:

  • 住所 [caddress]
  • 郵便番号[czip]

この機能は、次の場合に有効です:

  • 新しくプロビジョニングされた環境
  • 訪問が以前に構成されていない既存の環境

使用方法

「フォーム送信済」画面へのアクセス

フォームのヘッダーに「フォーム送信済」ボタンが表示されるようになりました。 バンドル・ルールに属していない通常のフォームの場合、このボタンは既存の「フォーム履歴」画面につながり、このリリースではこのアクティビティに対して発行されたフォームに名前が変更されました。

画面には、特定のアクティビティに対して送信されたフォームのリストが表示されます。

関連するforms(forms configured for a rule)の場合、Forms Submittedボタンは、次の2つのオプションを含むドロップダウン・メニューに変換されます:

  • このアクティビティ用
  • 関連アクティビティ用

関連アクティビティ用を選択すると、ユーザーは画面にナビゲートされ、他のユーザーが送信したフォームのリストが、バンドルの他のアクティビティまたはアクティビティ・セグメントで作業中に表示されます。 このリストには、このバンドル・ルールに対して構成された「関連フォーム」のフォーム提出のみが含まれます。

同じ訪問キーを共有する同時アクティビティの警告

同時に開始するアクティビティが同じ訪問キー値を共有する場合、アラートが表示されます。これは、同じバンドルのアクティビティが1つずつ開始され、オーダーがバルク・ルーティングによって強制されるためです。 アクティビティが意図的に同時にスケジュールされていることをシステムに通知するには、「同時に開始」リンクを使用してアクティビティ・リンクを作成するか、両方のアクティビティに同じ「通信済ウィンドウ」または「サービス・ウィンドウ」を設定して、アラートを効果的に防止し、オーダーの実施を確保します。

REST API

APIメソッドを使用すると、送信されたフォームがバンドルの最大1000アクティビティに対して返すことができる、アクティビティまたはアクティビティbundles.Noteに関連する送信済データをすべて取得できます。 この制限は、この機能の潜在的な不適切な構成に対する保護として機能します。

GET /rest/ofscCore/v1/activities/{activityId}/submittedForms?limit=100&offset=0&scope=bundles&bundle=bundle_label

問合せパラメータ

scope (optional): string. アクティビティのみに関連する送信済フォームを返すか、またはすべてのバンドル済アクティビティに戻すか。 値が'activity'の場合、アクティビティに関連するすべての送信済フォームのすべてのデータが返されます。 値が'bundles'の場合、構成済アクティビティ・バンドルに関連する発行済フォームが返されます。  指定できる値[ activity, bundles ].Default: バンドル

bundle (optional): string. このパラメータでは、返されるデータをフィルタするバンドルのラベルを指定できます。 特定のバンドルに関連する発行済フォームのみがレスポンスに表示されます。 パラメータが指定されていない場合、スコープ・パラメータの値が'activity'Defaultの場合、すべてのバンドルに関連するすべての送信はreturned.Thisパラメータになりません: アクティビティに関連するすべてのバンドルに関連するすべての提出が返されます

limit (optional): integer. レスポンスで返されるアイテムの数。 指定できる最小値は1で、指定できる最大値は100です。 指定した値が100、0(ゼロ)より大きい場合、または値を指定しない場合は、デフォルトで100に設定されます。

offset (optional): integer. 取得が開始されるレコード番号。 値が指定されていない場合、デフォルトでゼロに設定されます。 値ゼロは、取得がコレクションの先頭から開始されることを示します。

レスポンス

hasMore: boolean. Trueの場合、連続したページング・リクエストを使用して取得できる結果が増えます。 falseの場合、結果がなくなり、これが最終ページになります。

totalResults: integer. リクエストに一致する送信の合計数。

limit (optional): integer. リクエストに使用された実際の制限値。 (リクエスト・パラメータで指定された形式が異なる場合があります)。

offset (optional): integer. リクエストで指定されたオフセット値。

items (optional): array. アクティビティまたはバンドルに関連する送信済データの収集。

time: string. フォームが送信された日時(UTC)。 たとえば、2016-04-25 12:36:11などです。

user: string. フォームを送信したユーザーのユーザー識別子(ログイン)。

bundles (optional): array. 送信済フォームが関連付けられている構成済バンドルのラベルのリスト。 リクエスト・パラメータ'scope'が'activity'の場合、この値は存在しません。

formIdentifier: フォームのラベルおよび送信済フォームの一意のID。

formSubmitId: integer. 送信済フォームの一意のID。

formLabel: string. 送信済フォームのラベル。

formDetails (optional): 送信済フォーム・フィールド値を含むレコード。

activityDetails: 送信済アクティビティ・フィールド値を含むレコード。

レスポンスの例

{

"hasMore": false,

"totalResults": 3,

"limit": 100,

"offset": 0,

"items": [

{

"time": "2018-11-22 13:13:55",

"user": "login",

"formIdentifier": {

"formSubmitId": 19,

"formLabel": "",

"activityDetails": { .... },

"formDetails": { .... }

},

{ ... submit data 2 ... },

{ ... submit data 3 ... }

]

}

ビジネス上の利点

  • 複数のリソースまたはチームを必要とする長期間のジョブをより適切にサポートします。
  • さまざまな技術者が収集したデータに依存する並列アクティビティの処理を改善。

有効化のステップ

この機能は構成設定によって制御されます。

ヒントと考慮事項

  • ルールが情報交換とワークロード最適化の両方の目的で使用される場合、バンドル・ルールのタイルにバンドルされたアクティビティの期間パラメータが表示されます。

  • アプリケーションでは、最大5つのバンドル・ルールを作成できます。

  • ワークロードの最適化に使用できるルールは1つのみです。

  • バンドルのアクティビティの最大数は1000アクティビティを超えることはできません。 最大アクティビティ数が1000に達すると、アプリケーションはアクティビティを最新から最古にピック・アップし、停止してバンドルのビルドを開始します。

アクティビティ・トラベル・キーの自動検出

アクティビティ・トラベル・キーをシステムで自動的に検出するように設定できるようになりました。 この設定を選択すると、管理者が手動で決定および構成する必要はありません。 システムでは、機械学習を使用して、業務の国、市区町村およびアクティビティのロケーションの郵便番号に基づいてトラベル・キーを自動的に検出および構成します。 適用後は、レポートされたデータに基づいて、トラベル・キーおよびトラベル所要時間が学習され、更新されます。

構成上 - >統計画面の「アクティビティ・トラベル・キー」の下に、「アクティビティ・トラベル・キーを自動的に検出」という新しいチェックボックスがあります。

このチェックボックスをオンにすると、手動で構成された既存のキーは不要になるため、すべて消えます。

チェックすると、アクティビティのロケーションの国、市区町村および郵便番号に基づいてトラベル・キーが自動的に検出されます。 国コードが指定されていない場合は、「ビジネス・ルール」画面で構成されたジオコーディングのデフォルト国フィールドに指定されたデフォルトの国が使用されます。 トラベル所要時間は、新しく検出されたトラベル・キーに基づいて、レポートされたトラベル所要時間およびロケーション・サービスからのデータに基づいて推定され、継続的に学習されます。

検出された出張キーは、郵便番号を含む十分なデータがある場合、通常、国コードと郵便番号の一部の組合せになります。 郵便番号の長さは国によって異なり、トラベル・キーの地理的領域を最適化するために計算されます。 たとえば、郵便番号全体がトラベル・キーとして検出され、それで表される領域が小さすぎる場合、郵便番号の最初の文字のみが、より大きく、より最適な領域を表すとみなされます - したがって、より優れたトラベル推定を提供します。

十分なデータが存在する場合、国に基づいてシステムで使用される一般的なトラベル・キーは、次のとおりです:

国 Code トラベル・キー
アルゼンチン AR country_code, czip(4) 
オーストラリア AU country_code, czip(4)
オーストリア AT country_code, czip(4)
ベルギー BE country_code, czip(4)
バミューダ BM country_code, czip(2)
ブラジル BR country_code, czip(6)  
カナダ CA country_code, czip(5)
中国 CN country_code, czip(5)
チェコ CZ country_code, czip(6)  
ドミニカ共和国 DO country_code, czip(5)
エクアドル EC country_code, czip(5)
フィンランド FI country_code, czip(5)
フランス FR country_code, czip(5)
ドイツ DE country_code, czip(5)
イギリス/UK/イングランド GB country_code, czip(first word + 1 char)
ギリシャ GR country_code, czip(5)
グアテマラ GT country_code, czip(5)
ハンガリー HU country_code, czip(4)
インド IN country_code, czip(6)  
イタリア IT country_code, czip(5)
日本 JP country_code, czip(5)
メキシコ MX country_code, czip(5)
オランダ NL country_code, czip(4)
ニュージーランド NZ country_code, czip(4)
ポルトガル PT country_code, czip(4)
プエルトリコ PR country_code, czip(5)
ルーマニア RO country_code, czip(5)
シンガポール SG country_code, czip(2)
スペイン ES country_code, czip(5)
スウェーデン SE country_code, czip(6)
米国 US country_code, czip(5)

イギリス/UK/イングランドを除き、トラベル・キーの計算時に、表に記載されているすべての国のスペースおよび特殊文字が除外されます。 たとえば、値が40301-110の郵便番号は、40301110と同じとみなされます。 リストに含まれていない国の場合は、'(country_code, czip(5))'の書式がデフォルトで使用されます。 有効な郵便番号を持つアクティビティのロケーションの割合が重要でない場合は、国コードと市区町村の組合せがトラベル・キーとして使用されます。

「アクティビティ・トラベル・キーを自動的に検出」チェック・ボックスが選択されている場合、トラベル・キーのAPIオーバーライドは適用できません。 変更の適用画面で統計APIオーバーライドのみ適用オプションに対応するメッセージが調整され、これが表示されます。

「アクティビティ・トラベル・キーを自動的に検出」チェック・ボックスが選択され、変更が適用されると、手動で構成されたキーに関連する以前の学習済統計およびオーバーライドがシステムから削除されます。 ただし、以前の構成は保持されるため、「アクティビティ・トラベル・キーを自動的に検出」チェック・ボックスの選択が解除されている場合は、以前に手動で構成されたトラベル・キーが表示されます。 この場合、変更が適用されると、「構成変更の適用」オプションを選択することで、以前に構成したキーに基づくトラベル見積を夜間または即時に適用できます。

変更が保存されておらず、まだ適用されていない場合、変更がまだ適用されていないことを警告するメッセージが表示されます(現在の動作と同様)。 これは、チェック・ボックスを選択したり、チェック・ボックスの選択を解除する場合に適用されます。

自動的に検出されたトラベル・キーに関連するデータは、トラベル統計レポートおよびトラベル統計に関連するGET APIで表示できます。 トラベル統計レポートの組織の列には、自動的に検出される出張キーの全組織が表示されます。

システムによって自動的に検出されるトラベル・キーは、統計の収集やキー・レベルでのトラベル時間に基づく航空会社の距離の見積りなど、手動で作成されたトラベル・キーと同様に機能します(そのように構成されている場合)。 これらのトラベル・キーは組織からも独立しており、運用国によってのみ異なります。

APIの変更

トラベル・キーを自動的に検出するようにシステムが構成されている場合、APIを介したトラベル期間の上書きはサポートされていません。 さらに、「アクティビティ・トラベル統計の更新」および「航空会社距離ベースのトラベルの更新」操作では、上書き試行の場合に適切なエラー・メッセージとともにステータス・コード・エラー'HTTP 409'が返されます。

トラベル・キーが自動的に検出されると上書きは追加できないため、'Get activity travel statistics'および'Get airline distance based travel'操作では、レスポンスで上書きに関連するデータは返されません。 同様に、トラベル・キーが自動的に検出されると、トラベル・キーIDフィールドは使用されません。 統計構成で「アクティビティ・トラベル・キーを自動的に検出」が選択されている場合、GET APIリクエストではパラメータ'keyId'は無視されます。 また、トラベル・キーが自動的に検出された場合、GET APIリクエストのレスポンスで'keyId'および'org'パラメータは返されません。

アクティビティ・トラベル統計の取得レスポンスの例

{             

"tkey" :  "us79764" ,             

"fkey" :  "us79763" ,             

"avg" :  11 ,            

"dev" :  1 ,             

"count" :  5 ,            

 "region" :  "xyz_enterprise" 

}

航空会社ベースの出張レスポンスの取得の例

{             

"key" :  "us32771" ,             

"data" : [                 

{

"distance" :  1 ,

"estimated" :  16 

}                 

{                     

"distance" :  50 ,                     

"estimated" :  68                  

}             

]         

}

GET activityBookingOptionsおよびGET容量API操作では、トラベル期間を推定するために、APIリクエストの各ロケーションの国コード、郵便番号および市区町村を渡すことをお薦めします。

ビジネス上の利点

管理者は、システムで使用される最も最適なトラベル・キーを調査、分析および特定する必要がなくなります。 この新機能により、トラベル・キーを自動的に検出し、トラベル・キーのサイズを最適なレベルに保ち、学習速度とトラベル推定精度とのバランスを改善することで、このタスクが実行されます。 この機能により、手動で構成する最適なキーが少なくなる可能性も減り、トラベル推定と見返りが向上し、ルートが改善され、ETA予測が改善されます。

有効化のステップ

この機能を有効にするには、構成内の「アクティビティ・トラベル・キー」- >「統計」で「アクティビティ・トラベル・キーを自動的に検出チェック・ボックス」を選択します。

ヒントと考慮事項

  • トラベル・キーを自動的に検出する場合は、最も正確なトラベル見積を取得するために、すべてのアクティビティおよびリソース・ロケーションの国コードおよび郵便番号を指定することをお薦めします。
  • 国コードがロードされていない場合は、ビジネス・ルール画面で定義された地域コードのデフォルト国フィールドに指定されたデフォルトの国が考慮されます。 アクティビティに十分な郵便番号がない場合、郵便番号のかわりに市が使用され、トラベル見積の精度が低下する可能性があります。
  • トラベル・キーを自動的に検出するようにシステムが構成されている場合、トラベル期間のAPIオーバーライドはサポートされません。
  • 自動的に検出されたトラベル・キーは組織に依存せず、運用国によってのみ異なります。
  • GET activityBookingOptionsおよびGET容量API操作を使用する場合、トラベル期間を推定するために、APIリクエストの各ロケーションの国コード、郵便番号および市区町村を渡すことをお薦めします。

コア・アプリケーション

環境をリフレッシュするためのインスタンスの再作成の名前変更

Oracle Field Serviceと他のOracle Fusionアプリケーションの連携の一環として、「インスタンスの再作成」の名前がFusionアプリケーションで使用される用語に変更されました - "Refresh Environment". 同じように、製品内の「インスタンス」のすべての言及は、Fusionで使用される「環境」に置き換えられています。

ただし、この変更はAPIには適用されないため、顧客が設定した既存の統合には影響しません。

ビジネス上の利点

  • Oracle Field ServiceおよびOracle Fusionアプリケーションで用語を調整すると、ユーザーにとってエクスペリエンスの一貫性が保たれます。

有効化のステップ

この機能を有効化するうえで必要な操作はありません。

チームワーク - 在庫インストールを元に戻す処理のストレージ・ロケーション選択

チームの一員である技術者が誤った在庫を取り付けたことに気付いた後、または部品が機能しないことに気付いた後、次に取付けを元に戻すアクションを実行する必要があります。 これにより、正しくない部品または破損した部品が、チームの一部であるバンまたは別の技術者に返されます。 23Dアップグレード後、技術者は「インストールを元に戻す」画面に新しい「ストレージ・ロケーション」フィールドが表示され、チームの一員である使用可能なすべてのストレージのロケーション(他の技術者またはバン)が表示されます。

  • 「インストールを元に戻す」画面で、新しいストレージのロケーション・フィールドを使用できます。
  • フィールド保管ロケーションは、フィールド・リソースが他のリソース(フィールド・リソースまたはバン)を持つチームの一部であり、リソース・タイプでチーム作業での在庫の共有機能が有効になっている場合に使用できます。
  • シリアル番号付きインベントリの場合、部品が取得されるストレージ・ロケーション(フィールド・リソースまたはバン)がデフォルトで選択されます。 シリアル管理されていないインベントリの場合、ルートが開いている「ストレージのロケーション」(リソース)がデフォルトで選択されます。 どちらの場合も、技術者はリストから他の使用可能なストレージのロケーションを参照できます。
  • プラグイン・フレームワークは、「undo_install」インベントリ・アクションの新しい「inv_pid」パラメータで拡張されており、カスタム・プラグインを通じて「ストレージのロケーション」を選択できます。

プラグインAPIの変更点

「インストールを元に戻す」アクションを使用して、インベントリが戻される「プロバイダ」プールを持つリソースの'ID'を設定する機能が存在するようになりました。 これは、インベントリまたはinventoryListコレクションの'inv_pid'プロパティを更新するか(直列化されたインベントリの場合のみ)、または'undo_install'インベントリ・アクションの'inv_pid'パラメータを設定することで実現できます。

'undo_install'インベントリ・アクションの新しいパラメータ

パラメータ名

必須

 タイプ 説明

inv_pid

No

文字列

次のいずれか:

  • 現在のリソースのID
  • リソース・タイプ構成でチーム作業での在庫の共有オプションが有効になっているチーム作業メンバーのID

'inv_pid'パラメータがない場合:

  • シリアル管理在庫は、在庫がインストールされたリソースの「プロバイダ」プールに戻されます
  • 非シリアル管理在庫は、現在選択されているリソースのプロバイダ・プールに返されます

在庫処理に関連する更新済エラー・コード

Code 処理が原因 原因
TYPE_ACTION_PARAM
CODE_ACTION_INVENTORY_PID_INVALID

デインストール

次のいずれか:

  • 'inv_pid'パラメータ値が、現在のリソースまたはそのチームメイトのIDと等しくありません
  • 'create'アクションに対して'inv_pid'パラメータが送信され、'invpool'が'customer'

更新されたエラー・コード

Code 発生時期
TYPE_ENTITY_PROPERTY
CODE_INVENTORY_PID_INVALID

次のいずれか:

  • インベントリの' invpool 'は' 「顧客」 'で、' inv_pid 'の値は「空ではない」です
  • インベントリの'invpool'は'「デインストール」'で、'inv_pid'の値は'inv_pid'の「現行」値と等しくなく、現在の「選択したリソース」またはそれらの「チームメイト」の'pid'と等しくありません
  • インベントリの' invpool 'は' 「インストール」 'または' 「デインストール」'で、発行' inv_pid'の値は' inv_pid'の「現行」値と等しくありません
  • インベントリの'invpool'の現在の値と新しい値は'「プロバイダ」'であり、新しい'inv_pid'値は'inv_pid'の「現行」値と等しくありません
  • インベントリの' invpool 'の現在の値は' 「インストール」 'で、' invpool 'の新しい値は' 「プロバイダ」 'で、' inv_pid 'の新しい値は、現在の「選択したリソース」の' pid 'と等しくないか、またはリソース・タイプ構成で'Share inventory in teamwork'オプションが有効になっている「チームメイト」の1つではありません

ビジネス上の利点

  • チームに属するフィールド・リソースの拡張された在庫処理フロー。
  • 正しくない取付けまたは不良在庫の後に返品された在庫の関連リソース選択。

有効化のステップ

この機能を有効化するうえで必要な操作はありません。

ヒントと考慮事項

ストレージ・ロケーション・フィールドはリソースIDを使用するため、リソースIDフィールドをインストールを元に戻す画面に追加することはお薦めしません。 これにより、画面上のフィールドが重複し、ストレージ・ロケーションで選択したリソースが保存されません。

証明書の更新によるSAMLメタデータ更新のアラート

SAML認証セキュリティ標準の実装中に、Oracle Fusion Cloud Field Serviceはデジタル証明書を使用して、OFSから開始されたリクエストのアイデンティティを確認します。 顧客のアイデンティティ・プロバイダ(IdP)は、公開キーを使用してこれらのリクエストを検証し、さらに処理します。 このキーはOFSメタデータの一部として存在し、IdPによってOFSへのSAML認証を確立するために使用されます。

現在の証明書は2023年12月6日に失効します。ログイン・ポリシー構成ページから新しいOFSメタデータXMLをダウンロードし、IdPで置き換えて、これらのSAMLログイン・ポリシーを使用してユーザーのOracle Field Serviceへの認証を保持する必要があります。

構成画面の通知

OFS環境でSAMLタイプのログイン・ポリシーが少なくとも1つ使用されている場合は、環境がバージョン23Cサービス更新6または最新の23Dリリースに更新されるとすぐに、構成画面の上部に通知が表示されます。 この通知は、OFSメタデータ・ファイルをダウンロードし、2023年12月6日までにIdPで置き換える必要性について、ログイン・ポリシー構成画面に対する適切な権限を持つユーザーに通知します:

通知内のログイン・ポリシー・ボタンをクリックすると、ユーザーは対応する画面にナビゲートします。

すべてのSAMLログイン・ポリシーに必要なアクションが完了すると、構成画面の一般的な通知は表示されません。

OFSメタデータを置き換える必要があるSAMLポリシーの理解

「ログイン・ポリシー」画面で、注意が必要なSAML「ログイン・ポリシー」を識別できます。この警告メッセージは、SAML「ログイン・ポリシー」のタイルに表示されます:

すべての推奨アクションが実行され、新しいOFSメタデータXMLがIdPにすでに適用されていることを確認すると、各タイル内の警告メッセージがタイルから消えます。

ビジネス上の利点

シームレスなユーザー・アクセス・エクスペリエンスを確保し、デジタル証明書の有効期限に達した後でも中断のないサービスを維持します。

有効化のステップ

新しいOFSメタデータXMLをダウンロードして適用する手順

  1. IdPにアップロードされたレガシー・メタデータ・ファイルをバックアップします。
  2. ログイン・ポリシー・タイルのコンテキスト・メニューを開き、編集をクリックします。 ログイン・ポリシーを編集する画面が表示されます。
  3. IdPのOFSメタデータを置き換える必要性を通知する、画面の上部に表示される警告に注意してください。 その方法に関する簡単な説明が通知の下に表示され、「新しいメタデータのダウンロード」ボタンが使用可能になります:

  1. IdPからOFSにリクエストをリダイレクトするために使用するドメインを選択し、送信をクリックします。このアクションにより、ファイルのダウンロード・プロセスが自動的に開始されます。

    ノート: このポリシーに以前に選択された環境ドメインは、デフォルトで自動的に選択されます。

  1. 新しいメタデータXMLファイルをIdPにアップロードします。
  2. 新しいOFSメタデータがアイデンティティ・プロバイダにアップロードされた直後に、「新規メタデータ(次の10年有効)」設定を選択し、画面の下部にある「更新」ボタンをクリックします。
  3. SAMLを介してOFSにサインインできること、および正しくサインアウトできることを確認します。

現在使用されているOFSメタデータを示す警告および設定は、ログイン・ポリシーが新しいメタデータに切り替えられてから5日間画面に表示されます。 この余分な時間により、問題が発生した場合に簡単に変更をロールバックできます。

変更をロールバックする方法

SAML認証が突然機能しなくなった場合は、次のステップに従って変更をロールバックできます:

  1. 古いOFSメタデータをIdPにアップロードします(更新中にバックアップしました)。
  2. 変更するログイン・ポリシーを開き、「レガシー・メタデータ(2023年12月6日SSL証明書失効)」設定を選択して、画面の下部にあるUpdateボタンをクリックします。
  3. サインインおよびサインアウト操作が成功したことを確認します。

ヒントと考慮事項

  • レガシーOFSメタデータ・ファイルをアイデンティティ・プロバイダの新しいOFSメタデータ・ファイルに置き換える前にバックアップします。 これにより、適用された変更時にSAML認証で問題が発生した場合にロールバックを実行できます。
  • 新しいメタデータ・ファイルは、アプリケーションからのみダウンロードできます。レガシー・メタデータ・ファイルはダウンロードできなくなりました。

統合

Fusionからの品目カタログの直接使用

この機能により、FusionからOFSに部品カタログを同期する新しい方法が導入されました。 OICアクセラレータにより、在庫組織からの品目に基づくカタログを長時間作成できましたが、この機能では次の改善点が示されています:

  • Fusion品目カタログからのOFS部品カタログの作成と更新
  • Oracle Integration Cloudを使用せずにFusionと直接統合することで、部品カタログの統合の実装とメンテナンスにかかる時間を短縮し、OICによるAPIリクエストのプロキシによるエラー率を低下させます

この機能を利用するには、次の2つのアイテムが必要です:

  • Fusion環境の品目カタログ
  • OFSで構成された'Oracle Fusion Service and Service Logistics'アプリケーション

残りは自動的に行われます。 Fusionの品目カタログが定期的にチェックされ、それぞれ次のことが行われます:

  • Fusionへの到着時に、OFSで新しいカタログを作成
  • 品目カタログの変更に基づいて既存のカタログの更新をアップロード

新規カタログは部品カタログ画面に表示され、顧客はそれらをユーザー・タイプに割り当てて、カタログをフィールド・リソースで使用できるようにする必要があります。

OFSにアップロードされたFusionカタログは、構成済の言語に関係なく、割り当てられたユーザー・タイプのすべてのユーザーに表示されます。 言語パラメータは、Fusionからアップロードされた部品カタログのタイルには表示されません。

REST APIを使用して部品カタログを作成するときに言語制限を削除する方法

言語制限を削除するには、APIリクエストの'language'パラメータに'all'の値を指定します。 例: /rest/ofscPartsCatalog/v1/catalogs/my_catalog/all

ビジネス上の利点

  • Fusionから部品カタログを作成する柔軟性が向上します。
  • 部品カタログ統合のための時間とリソースを節約します。
  • ミドルウェアを使用せずにFusion Itemカタログに直接接続すると、より安定した統合が実現します。

有効化のステップ

アプリケーションの構成方法

'Oracle Fusion Service and Service Logistics'アプリケーションに対して、次のパラメータを移入する必要があります:

Oracle Fusionサービス・エンドポイント

  • URL
  • ユーザー名
  • パスワード

部品カタログ

  • Fusionカタログの使用(この機能の一部として追加された新しいパラメータ)

接続のテスト

'Test connection'関数は、Fusion環境およびOracle Integration Cloudへの接続を個別にチェックし、それぞれへの接続ステータスを表示します。

追加の変更

アプリケーションでは'OIC channel'パラメータが不要になりました。これは、これからは2つのニーズに対応するためです:

  • Oracle Integration Cloudによる統合 - この種の統合を使用する場合のみパラメータが必要ですが、Fusion環境のエンドポイントも必要です
  • Fusionとの直接統合 - Fusionエンドポイントのみ入力する必要があります

ノート: 統合チャネル・フィールドが移入されると、Oracle Integrationセクションの下のパスワード・フィールドが表示されます。 統合チャネル・フィールドが空の場合、パスワードは表示されません。

ヒントと考慮事項

Fusionサービスの部品について、次のパラメータが取得されます:

  • "CatalogId" 
  • "CatalogCode" 
  • "CatalogName" 
  • "CategoryId" 
  • "CategoryCode" 
  • "CategoryName" 
  • "ItemId" 
  • "OrganizationId" 
  • "Item" 
  • "OrganizationCode" 
  • "ItemDescription" 
  • "ItemClassId" 
  • "ItemClassName"

ルーティング

一括ルーティングでアクティビティ開始日よりX日前の在庫が必要

新規パラメータ・アクティビティ開始までの次の日数に在庫が必要があります: ルーティング・プラン・レベル。 このパラメータにより、ルーティングで事前にスケジュールされたアクティビティの在庫所要量を無視できます。 たとえば、値を7に設定すると、現在から1週間以内の日付にスケジュールされている必須在庫があるすべてのアクティビティは、手持在庫がある技術者にのみルーティングされます。 ただし、1週間以上後にスケジュールされたアクティビティは、必要な手持在庫なしで技術者にルーティングされる場合があります。これは、部品のオーダーおよび出荷に1週間が十分であると想定されるためです。 このフィールドのデフォルト値は0です。これは、本日から始まる日ごとに在庫が必要であることを意味します。これは23Dより前の動作です。

ビジネス上の利点

  • 計画メンテナンス・アクティビティの部品のオーダー・プロセスは、工順から独立できるようになったため、必要な部品があるかどうかに関係なく、アクティビティを事前にルーティングできます。 ただし、同じ機能では、アクティビティがスケジュールされているか、開始日より前に定義された時間を再スケジュールするために、在庫を厳密に必要にすることもできます。
  • もう1つの潜在的な利点は、最適化の使用を懸念している企業にとって、次のX日以内に在庫を厳密に必要とする活動や、将来ある時点で計画されていて在庫を必要としない活動を見逃さないことです。この新しい設定により、在庫要件に基づいてアクティビティが常に正しくルーティングされるようになります。

有効化のステップ

ルーティング・プランを作成または変更する場合は、在庫によるルーティングを有効にし、アクティビティ開始前の次の日数に在庫が必要という新しいパラメータの値を選択します。 たとえば、値を7に設定すると、現在から1週間以内の日付にスケジュールされている必須在庫があるすべてのアクティビティは、手持在庫がある技術者にのみルーティングされます。 ただし、1週間以上後にスケジュールされたアクティビティは、必要な手持在庫なしで技術者にルーティングされる場合があります。これは、部品のオーダーおよび出荷に1週間が十分であると想定されるためです。

ノート: アクティビティ開始までの日数は常に本日から計算され、ルーティング・プランが実行された日付から独立しています。

ヒントと考慮事項

必要な部品のオーダーと取得に必要な時間を収める方法で、必要な在庫間隔を選択することを検討してください。

重要な処理および考慮事項

置き換えられた機能または削除された機能

クラウド・サービスのセキュリティ、パフォーマンスおよび品質全体を向上させるために、ソリューションの機能および技術コンポーネントを削除または置換できます。 これが発生すると、機能またはコンポーネントの非推奨が事前に発表されるため、変更の予測および拡張された交換機能/コンポーネントへの移行に十分な時間がかかります。 非推奨が発表された後、非推奨の機能またはコンポーネントは、計画された削除日までソリューション内に残り、拡張や他の新機能との互換性はなくなります。

新しい廃止/ 削除

アプリケーション領域 削除される機能 削除予定 置換後の機能 置換時期 追加情報
訪問バンドル・キー
  1. バンドル・キーに対して次の機能を構成する機能:
  • 大/小文字を区別
  • 大/小文字を区別しない
  • 最初の単語の大/小文字を区別
  • 最初の単語の大/小文字を区別しない
  1. 「アクティビティ・バンドル機能」の「ルールの追加/編集」の項で説明されている以外の他のOFSネイティブ・フィールドを構成する機能。
 23D

この領域の新機能の詳細は、現在のリリースのアクティビティ・バンドル機能の項を参照してください。

 23D

これらの特定の機能は、最小限の期間または使用なしの期間が延長されたために削除されています。

以前に発表された非推奨

次に、このクラウド・サービスの新規および以前に発表された非推奨のリストを示します。

アプリケーション領域 削除される機能 削除予定 置換後の機能 置換時期 追加情報

日次抽出

日次抽出プロセスの一部としてプロパティ・ファイル・エンティティに関連するファイルをエクスポートする機能。

 23D
  • API関数'日付の日次抽出ファイルのリストを取得'は通常どおりファイルのリストを返しますが、プロパティ・ファイルのURLは、それぞれのエンティティからファイルの内容をダウンロードできる対応するAPI関数を指すように変更されます。
  • 日次抽出は、プロパティ・ファイルをアーカイブせずに生成されます。 つまり、プロパティ・ファイル・エンティティのexport_archive="zip"設定は、現在この機能を利用しているレガシー顧客に対してのみサポートされます。 新しい構成の日次抽出ファイルの作成では考慮されません。

22Aで発表
  • この拡張により、日次抽出作成時間が大幅に簡略化され、短縮されます。 一部の顧客では、日次抽出プロセスに数時間かかる場合があります(つまり、オブジェクト・ストレージからの数千個の添付ファイルのコピー、アーカイブ、Object Storage日次抽出フォルダへの移動など)。 また、アーカイブ・サイズは5 GB以上であるため、一部の顧客(ファイルのダウンロード、アーカイブの解凍、ファイルの処理など)ではこの処理に時間がかかりました。 この機能拡張により、日次抽出プロセスの時間が大幅に短縮されます(1時間以下)。
  • '日付の日次抽出ファイルのリストを取得'関数を使用するときに、各エンティティのプロパティ・ファイルをダウンロードできるように、コアAPI権限を更新する必要がある場合があります。

ユーザー・ログイン・ドメイン

https://login.etadirect.com URLスキームを使用した認証リクエスト

 23D

URLスキームhttps:// <instance_name>.fs.ocs.oraclecloud.comの使用

22Aで発表

この変更により、ターゲットのOracle Field Service環境が実行されている適切なデータ・センターにリクエストが転送されるようにすることで、認証時間が短縮され、データ・レジデンシに関連する政府および企業ポリシー規制に準拠します。

Oracle Field Serviceのすべてのバージョンで実行されているすべての環境では、更新23Dの一般提供日以降からログイン・ドメインはサポートされません。

詳細は、「Oracle Field ServiceログインおよびAPIドメインの非推奨」のトピックを参照してください。

APIドメイン

https://api.etadirect.com URLスキームを使用したAPIアクセス

 23D

URLスキームhttps:// <instance_name>.fs.ocs.oraclecloud.comの使用

22Aで発表

この変更により、ターゲットのOracle Field Service環境が実行されている適切なデータ・センターにリクエストが転送されるようにすることで、認証時間が短縮され、データ・レジデンシに関連する政府および企業ポリシー規制に準拠します。

APIドメインは、すべてのバージョンのOracle Field Serviceで実行されているすべての環境の更新23D一般提供日以降ではサポートされません。

詳細は、「Oracle Field ServiceログインおよびAPIドメインの非推奨」のトピックを参照してください。