新機能

更新24B

改訂履歴

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

この表には、ドキュメント変更の時系列リストが含まれています。

概要

アイデアはありますか。

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

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

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

免責事項

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

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

機能のサマリー

フィールド・サービス

管理

自動構成検証

フォームまたは標準処理画面を構成する場合、アプリケーションは「公開」ボタンをクリックすると、更新された構成を自動的に検証します。 検証エラーがない場合は、構成が公開され、ユーザーに配布されます。 ただし、エラーが発生した場合、アプリケーションはそれらを表す画面を表示し、戻ってエラーを修正するか、構成の変更をそのまま意識的に公開するかのいずれかのオプションをユーザーに提供します。

フォームのプレビューにナビゲートする場合も、同じ方法が使用されます。 ダイアログに、検出された検証エラーと、それらを修正するオプションまたはプレビューを表示するオプションが表示されます。

標準画面の構成のメニュー

「公開」ボタンは、常に画面ヘッダーに表示されます。 「ユーザー・タイプにコピー」、「クリア」、「検証」の各処理は、「処理」コンテキスト・メニューの下に配置されます。 「元に戻す」ボタンは、この操作を実行できるときに表示されます。

フォームの構成のメニュー

「プレビュー」ボタンと「公開」ボタンは、常に画面ヘッダーに表示されます。 「クリア」&「検証」アクションは、「アクション」コンテキスト・メニューの下にあります。 「元に戻す」ボタンは、適切なときに表示されます。

• パブリッシュする前に構成の更新をより適切に制御
• コンフィギュレータのユーザー・エクスペリエンスを簡素化

有効化のステップ

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

構成UIの改善の表示

「表示」画面のビジュアル表現が、Redwoodアプローチと連携するようになりました。 画面は2列のレイアウトに再構築され、すべての機能が維持されます。

環境のタイムゾーンを選択すると、リスト内の各タイムゾーンの名前とコードがアプリケーションに表示されます。 ユーザーは、特に同じ名前を持つゾーン間で、必要なタイム・ゾーンを識別できます。

• Fusionアプリケーション全体で一貫したユーザー・エクスペリエンスを提供します。
• Fusionとのタイム・ゾーン統合におけるミスの減少。

有効化のステップ

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

ヒントと考慮事項

「時間入力」設定は非推奨になり、アプリケーションから削除されました。

拡張タイムゾーン・サポート

24Bの更新により、OFSにはInternet Assigned Numbers Authority (IANA)データベースからの追加のタイムゾーンが含まれるようになり、現在サポートされているタイムゾーンのリストが拡張されました。 これらのタイム・ゾーンが存在し、OFS内でリソースまたはアクティビティを作成するために必要なバックエンド・システムとの統合を効率的に維持します。

• グローバルまたは複数のタイム・ゾーンで事業を展開する企業にとって、様々なタイム・ゾーンの包括的なサポートが不可欠です。 これにより、レンダリングされるサービスが、対応するタイム・ゾーン料金および請求サイクルに従って正確に請求されます。
• アポイントメント・ベースのサービスを提供する企業は、アポイントメントを正確にスケジュールし、様々なリージョンにわたってリソースの空き状況を管理するために、タイム・ゾーンをアクティビティおよびフィールド・リソースに割り当てる必要があります。

次の表に、IANAタイム・ゾーン・データベースによって現行とみなされるタイム・ゾーンを含む、追加されたタイム・ゾーンの包括的なリストを示します。

ビジネス上の利点

• タイム・ゾーンが存在し、OFS内でリソースまたはアクティビティを作成するために必要なバックエンド・システムとのスムーズで正確なデータ同期を保証します。

• ユーザーがインタフェースをパーソナライズし、タイム・ゾーンを特定のロケーションに調整できるようにすることで、ユーザー・エクスペリエンスを向上させます。

有効化のステップ

「構成」>「表示」画面で使用可能な「会社のタイムゾーン」セクションにアクセスして、タイムゾーンを環境に追加できます。

統計キー構成の最適化

アクティビティおよび移動所要時間を正確に推定するには、アクティビティおよび移動所要時間キーが、キー値によって生成されたものが特定しすぎたり広すぎたりしないように構成することが重要です。 キー値が特定しすぎると、各キー値の所要時間を推定するのに十分なレポート・データがありません。 一方、キー値が大きすぎると、推定の精度が損なわれる可能性があります。

たとえば、構成済の移動キーによって特定すぎる移動キー値が生成される場合、各移動キー値は、小さな地理的領域のみを対象とします。 これにより、各移動キーにアクティビティ・ロケーションが少なすぎて、異なる移動キーのペア間でレポートされるデータがほとんどなくなる状況が発生します。 すべての異なる移動キー・ペア間の正確な移動推定の生成にはかなり時間がかかります。また、各移動キーに十分なアクティビティ・ロケーションおよびレポートされた移動データがないため、デフォルトの移動所要時間も頻繁に使用されます。

一方、構成された移動キーが広すぎる場合、各移動キー値は地理的に広い範囲をカバーします。 これにより、ある移動キーから別の移動キーへのレポートされた移動データが大きく変化します。 この差異は、移動推定の全体的な精度に影響します。

アクティビティ所要時間キーが具体的すぎるか広すぎる場合にも、同じことが言えます。

構成されたアクティビティ・キーまたは移動期間キーが特定すぎるか広すぎて正確な所要時間推定を提供できない場合、管理者に通知されるようになりました。 構成されたキーが特定すぎるか広すぎるキーを生成していることが判明した場合、バナー・メッセージがメイン構成画面に表示されます。 「構成」ボタンをクリックすると、統計構成画面が表示され、ユーザーはキーを適切に変更できます。

同様のバナーが「統計」構成画面にも表示されます。

ノート: 構成されたキーが特定しすぎるか広すぎるかを判断するためのチェックは、日次統計計算の一部として自動的に行われます。または、管理者が「統計構成」画面から構成の変更を手動で適用することを選択した場合に行われます。

修正処理の詳細が、構成されたキーのすぐ下に表示されます。

ノート: キーが具体的すぎるか広すぎるかを判断するためのチェックは、「アクティブ」アクティビティ期間キーに対してのみ行われます。 非アクティブなものはチェックされません。

また、鍵を最後に変更した管理者も、構成された鍵が最適でないことを通知する通知タブに表示されます。

キーが最適でないとみなされる条件

アクティビティ期間キー

• アクティブ・アクティビティ所要時間キーは、一意のアクティビティ所要時間キー値が5個以下になる場合、幅が広すぎるとみなされ、同じキー値に属するアクティビティについて、レポートされた所要時間の変動も大きくなります。
• 40%を超えるアクティビティに、所属するキーに対して十分なレポート・データ(少なくとも25のアクティビティ)がない場合、キーは特定しすぎるとみなされます。

移動所要時間キー

• 40%を超えるアクティビティで非常に大きいキー(200平方キロ・メートル/75平方マイルを超える)を使用する場合、移動時間キーは広すぎると考えられます。
• アクティビティの40%以上が、所属するキーに対して十分なレポート・データ(少なくとも15のアクティビティ)がないキーを使用する場合、移動期間キーは特定しすぎるとみなされます。

ビジネス上の利点

• 構成されたキーが正確で意味のある結果を生成するのに十分でないかどうかを簡単に識別できます。
• システムによって提供される提案に基づいて修正処理を実行します。
• 所要時間キーの品質が良好であるため、より正確なアクティビティおよび移動所要時間の見積りが保証されます。

有効化のステップ

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

ヒントと考慮事項

• 構成されたキーが最適ではないという通知が出たらすぐに、提案に基づいて修正処理が行われていることを確認し、それに応じてキーを変更します。

API

予約APIレスポンスへのタイム・ゾーンの差異

24Bの更新により、容量関連の予約操作にレスポンスのタイムゾーンの違いが含まれるようになりました。 この機能により、関連するタイム・ゾーンの夏時間(DST)の変更を考慮して、特定の日のタイム・スロットのバリエーションを容易に識別できます。

次に、スケジュールに使用可能な日付とタイム・スロットを検証する際に、統合でタイム・ゾーンの変更を正確に処理する必要性を示す様々なシナリオを示します。

• 複数の国またはリージョンで営業している会社は、戻された日付とタイム・スロットが、関連するキャパシティ・エリアに割り当てられたそれぞれのタイム・ゾーンに従って正確に表示されるようにする必要があります。 これにより、異なるロケーションにいる顧客やユーザーの混乱を回避できます。
• 法令またはコンプライアンスの問題に対処する統合では、期限を満たすために返された日付のタイムゾーンの変更を正確に処理するか、エラーや矛盾なく可用性を確認する必要があります。
• ポイント・スケジューリング・プラットフォームでは、異なるリージョンのユーザーが予約したポイントの日付とタイム・スロットの確認時にタイムゾーンの違いを考慮し、ポイントが両端で正確にスケジュールされるようにする必要があります。

予約オプションが定義されている容量領域では、activityBookingOptionsおよびshowBookingGrid APIメソッドの両方のレスポンスに、timeZone文字列フィールドに加えて、'timeZoneDiff'整数フィールドが含まれるようになりました。

• timeZoneDiff (optional): 整数

タイトル: タイムゾーン差分

摘要: UTCとリソースのローカル時間の差異(分単位で表示)。 たとえば、 -180は、リソース時間がUTCより3時間遅れていることを意味します。

ビジネス上の利点

• 夏時間(DST)の変更に従った様々なリージョンでの予約管理の効率が向上します。

• 予約ワークフローでさらに処理するために、ISO 8601標準に従って時間情報をマッピングする必要がある外部システムとの統合を容易にします。

有効化のステップ

REST APIガイドのRESTサービス定義を確認して、活用してください(Oracle Help Center > 「関心のあるアプリケーション・サービス領域」 > 「API &スキーマ」から入手できます)。 OracleのRESTサービスを初めて利用する場合は、クイック・スタートに関する項から開始してください。

主なリソース

• Oracle Field ServiceのCapacity REST API。

OAuth 2.0認証を使用した外部 / Fusion APIへのアクセスの保護

Oracle Field Serviceでは、外部サービスのAPIにアクセスするためのOAuth 2.0認証がサポートされるようになりました。 OAuth2.0を使用すると、フィールド・サービスから他のアプリケーションを接続しながらユーザーを伝播できるため、外部アプリケーションの同じユーザーにかわって外部サービスのAPIをコールできます。 フィールド・サービスは、Oracle IDCSまたはサード・パーティのOAuth 2.0認可サーバーからアクセス・トークンをリクエストできます。 アクセス・トークンは、外部システムへの安全なコールに使用できます。 たとえば、フィールド・サービス・プラグインを使用してサードパーティのモバイル・アプリケーションを開くと、OAth2.0アプリケーションを使用してより安全になります。 Oracle Identity Cloud Service (IDCS)からトークンにアクセスするオプションを使用すると、フィールド・サービスからFusion APIなどのアプリケーションAPIにアクセスできます。

Oracle Field Serviceでは、構成ページでアプリケーション「REST/SOAP APIを使用するアプリケーション」を登録することで、フィールド・サービスRest APIにアクセスするためのOAuth 2.0認証がすでにサポートされています。 このアプリケーションは、フィールド・サービスから外部APIにアクセスするためのOAuth2.0認証をサポートするように拡張されています。

Oracle Field Serviceは、外部 / Fusion APIのOAuth 2.0認証をサポートしています。OAuth2.0アプリケーションを使用すると、OFSユーザーのかわりにフィールド・サービスからサードパーティ・アプリケーションにアクセスできます。 OAuth 2.0認証を使用するには、最初にアプリケーションをOracle Field Serviceに登録する必要があります。 「構成」>>「アプリケーション」ページに移動し、「REST / SOAP APIを使用したアプリケーション」オプションを選択します。

APIアプリケーション1

「アプリケーション構成の追加」画面で、「フィールド・サービスAPI」、「OAuthユーザー・アサーション」または「OAuthクライアント資格証明」を選択できます。

フィールド・サービスAPI - サードパーティ・アプリケーションからのフィールド・サービスAPIへのアクセスを許可するように、認証および認可を構成できます。

OAuthユーザー・アサーション - OAuth2.0権限付与タイプは、フィールド・サービスからユーザー資格証明を公開せずに外部APIサービスにアクセスする場合に使用できます。 OAuthユーザー・アサーションをサポートするアイデンティティ・プロバイダによって発行されたトークンを受け入れる外部APIサービスにアクセスできます(たとえば、Oracle Identity Service (IDCS)に接続してFusion APIにアクセスできます)。

OAuthクライアント資格証明-外部システムでクライアント資格証明の付与をサポートするOAuth 2.0トークン・エンドポイントが実装されている場合、OAuth 2.0権限付与タイプを使用して外部APIサービスにアクセスでき、クライアントIDおよびクライアント・シークレットを使用するのではなく、ユーザーのかわりにサービスにアクセスする必要がありません。

APIアプリケーション2

Field Service APIでは、ここで説明するように、フィールド・サービスAPIの認証/認可構成ページに移動します。 「OAuthユーザー・アサーション」オプションを使用すると、認可サーバー・エンドポイント、クライアント資格証明およびトークン・エンドポイントを格納できます。 これは、許可付与およびOAuth2.0トークンを取得するために使用できます。

表1

「外部API」オプションを使用すると、外部アプリケーションAPIアクセス用のOAuth 2.0資格証明を格納できます。

APIアプリケーション3

表2

提供された構成に基づいて、新しいアプリケーションを「構成」ページに追加できます。 アプリケーションには、変更または削除するオプションがあります。 Fusion APIの場合、アプリケーションUIから認証証明書をダウンロードするための追加オプションを使用できます。

アプリケーションAPI 4

このアプリケーションは、クライアント資格証明の付与をサポートするOAuth 2.0トークン・エンドポイントを実装する外部システムとの互換性を提供する、OAuth 2.0クライアント資格証明の付与認証フローを採用しています。 また、クライアント資格証明(client_id / client_secret)は、認可ヘッダー内で送信されます。

• OAuth2.0は、Oracle Field Serviceから外部サービスAPIにアクセスするための安全で標準的な方法です。 これで、プラグインなどのOFS機能を使用して、アプリケーションにユーザー資格証明を送信または格納する必要なく任意のAPIをコールできるようになりました。
• ファイングレイン・アクセス制御 - ユーザーIDがわかっていると、外部システムは、このユーザーが実行しようとしているアクションを実行する権限があることを確認できます。
• 監査 - アプリケーションを構成するときに、「ログインに基づいてユーザーを識別する」を選択できます。 これにより、外部システムは、静的ユーザー(フィールド・サービスなど)ではなく、APIにアクセスした実際のユーザーを記録できます。
• ユーザーレス統合は、多くの場合、広範囲にわたる権限を使用して構成されます(たとえば、「フィールド・サービス」APIクライアントは、フィールド・サービスのほとんどの個人ユーザーが必要ない機能にアクセスできる外部システムに登録できます)。

有効化のステップ

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

コラボレーション

チャット・グループ制限

管理者は、特定のコラボレーション・グループのメンバー間でチャットを制限できます。 一度制限されると、グループのメンバーは、グループの他のメンバーとのチャットを検索または開始できなくなります。 既存のチャットも制限され、権限が取り消されると、ユーザーはチャット会話を続行できなくなります。 同じことが既存の会議にも当てはまります。

また、コラボレーション構成はRedwoodスタイルに基づいて再設計されました。

この新機能は、プライバシと制御を確保しながら、コミュニケーションのダイナミクスを強化することを目的としたさまざまなユースケースに対応しています。

• 制限は、グループ内で共有される特定の議論または情報の機密性に関する法的または規制要件に準拠するために実施できます。

• 管理者は、グループ外での参加者間のやり取りを防ぐために制限を構成し、ディスカッションが企業関連のタスクに集中するようにできます。

コラボレーション・グループの場合、「このグループのメンバー間のチャットを許可」というラベルの付いた追加のチェック・ボックスがあります。 このチェック・ボックスは、新規および既存のグループに対してデフォルトで有効になっています。 チェックマークを外すと、このグループ内のユーザーは、他のメンバーを検索したり、チャットを開始することはできません。ただし、オプションが有効になっている別のグループに属したり、「グループとのコラボレーション」構成に基づいて表示できるなど、他の構成を介して表示が維持されている場合を除きます。

進行中の1対1チャットでは、次のいずれかの状況では、ユーザーは相互に会話を続行できません:

• ユーザーが属するグループの「このグループのメンバー間のチャットを許可」チェック・ボックスの選択を解除して、表示権限を取り消します。

• 「グループとのコラボレーション」構成から各グループの関連付けを解除します。

• コラボレーション・グループの非アクティブ化。

• いずれかのユーザーの非アクティブ化。

コラボレーション・ユーザーの1人が新しいメッセージを送信しようとすると、メッセージは送信されず、両方のユーザーが「この連絡先とチャットする権限はもうありません」とチャットする権限がなくなったことを示すメッセージが表示されます。

進行中の会議では、会議内に、他のどのユーザーとも表示できないユーザーが少なくとも1人いる場合、会議は動作不能になります。 このような状況が発生し、ユーザーが新しいメッセージを会議に送信しようとすると、そのメッセージは送信されず、その会議のユーザーは次のメッセージを受け取ります。権限が変更されたため、そのカンファレンスでメッセージを送受信できなくなったこと。

ユーザーは、そのユーザーを表示できる場合にのみ、引き続きメンバーを作成して会議に追加できます。

「このグループのメンバー間のチャットを許可」オプションを変更しても、既存のブロードキャストやヘルプ・デスクの会話には影響しません。 オプションが無効になっている場合、ユーザーは、チャット権限を持たないユーザーとの将来のブロードキャストおよびヘルプ・デスク・リクエストを開始できなくなります。

ビジネス上の利点

• カスタマは、特定のニーズおよびワークフローに従ってチャット機能を調整できます。

• ユーザーが公式コミュニケーション・チャネルを使用して無関係な会話を開始できないようにすることで、会話がグループの目標に関連していることを確認することで、生産性を向上させます。

• コミュニケーション・チャネルにおける不要な注意を最小限に抑えます。

• フィールド・リソースによる不当なブロードキャストは、フィールド・リソースのグループにヘルプ・デスクのみにアクセス権を付与できるため、防止できます。これにより、このようなシナリオではヘルプ・デスクの会話のみを開始できます。

• 企業が安全な通信環境の維持を目的としたセキュリティ対策を実施できるようにします

有効化のステップ

• 「このグループのメンバー間のチャットを許可」は、新規および既存のグループに対してデフォルトで有効になります。

• 既存のグループに対して「このグループのメンバー間のチャットを許可」を無効にするには、「構成」>「コラボレーション」> (group_name)に移動

ヒントと考慮事項

進行中の1対1のチャットまたは会議は、「このグループのメンバー間のチャットを許可」オプションが無効になっているか、「グループとのコラボレーション」構成が更新された場合に、通信を失うことによって影響を受ける可能性があります。 既存のコラボレーション・グループの構成に対する変更を実装する前に、その機能に対する潜在的な影響を十分に評価することが重要です。

生産能力

割当画面の改善

この機能では、機能変更のリストが視覚的な改善とともに表示され、「割当」画面の新しいルック・アンド・フィールが提供されます。 要約すると、変更内容は次のとおりです:

• タイム・スロットおよび時間間隔ベースの予約アプローチの「統合目標」画面ビュー。
• タイム・スロット・アプローチにおけるキャパシティ・カテゴリとタイム・スロットの割当レベルの統合ビュー。
• 「残りの割当」値を計算する列が追加され、ユーザーは特定の日、キャパシティ・カテゴリまたはタイム・スロットに使用可能な残りの割当を表示できます。
• 「表示」ドロップダウン・メニュー内のドラッグ・アンド・ドロップ機能を使用して列を並べ替える機能。
• アクティブなユーザー・セッション内のキャパシティ・エリア間で列選択オプションを保持します。
• 「目標画面」表内の拡張キーボード・ナビゲーション。
• 「繰返し自動入力」オプションが有効になっているセルのビジュアル・インジケータ。

簡素化された表示とナビゲーション

タイム・スロット・ベースの割当の「表示」コンポーネントですべてのオプションが結合され、データをフィルタして同じ画面に表示できるようになりました。 キャパシティ・カテゴリまたはタイム・スロットの異なる画面表示を切り替えるかわりに、必要なすべてのオプションを一度に選択して「割当」画面の包括的なビューを取得できるようになりました。

目標日ビューは引き続き個別に表示され、繰返し自動入力によってこのレベルで自動計画が可能になります。

ユーザーは、セル、行および列間を移動したり、特定のキーの組合せを使用してデータを選択および編集したり、ExcelやGoogleスプレッドシートなどのスプレッドシート・アプリケーションにある使い慣れたキーボード・ショートカットをミラーリングできます。

もう1つの重要な機能拡張は、アプリケーションでビュー要素内で選択された列と順序が保持されるようになったため、キャパシティ領域間を移動するときに列と順序を繰り返し選択する必要がなくなります。 これらの設定は、アクティブなユーザー・セッション全体で保持されます。

残りの目標を表示

「残、分」および「残、%」列が割当表に追加され、特定の日、キャパシティ・カテゴリまたはタイム・スロットの残りの割当にアクセスできます。 これにより、予約に使用できる割当を決定するための計算が不要になります。

繰返し自動入力ステータスのビジュアル・インジケータ

繰返し自動入力機能を使用すると、将来の日の目標パラメータ値のコピーをスケジュールできます。 これらのパラメータの例には、特定のキャパシティ領域の構成に応じて、「割当」、「予約停止時の%」、「日次割当て、%」などがあります。

「繰返し自動入力」オプションにアクセスするには、変更するセルを右クリックし、「繰返し自動入力」メニュー項目を選択します。

「繰返し自動入力」が有効になっているセルには、小さな「カレンダ」アイコンが表示され、元の情報と、それらを変更するかどうかの決定に役立ちます。

「目標クローズ時間」でのユーザー・エクスペリエンスの強化

割当クローズ時間機能を使用すると、1日、タイム・スロットまたはキャパシティ・カテゴリのクローズ時間を設定できます。 セルの終了時間を設定することも、条件が一致する場合は、特定の作業ゾーンの終了時間を定義することもできます。

この画面へのナビゲーションは、「繰返し自動入力」の場合と同じです:

1. 変更するセルを右クリックします。

2. 「クローズ時間」メニュー項目を選択します。

3. 締め時間パラメータを定義します。

4. 構成が完了したら、「変更」ボタンをクリックして選択内容を確認します。

5. 変更を保存するには、「割当て制限」画面で「保存」ボタンをクリックします。

目標ステータスの変更に対するユーザー・エクスペリエンスの強化

ステータスは、1日、タイム・スロットまたはキャパシティ・カテゴリの予約を許可または無効にするために不可欠です。 この機能により、ユーザーは最小クリック数でステータスを簡単に変更できます。

割当ステータスを更新するには:

1. 変更するセルを右クリックします。

2. プリファレンスに応じて、メニューから「目標のオープン」または「目標のクローズ」オプションを選択します。

3. 変更を保存するには、「割当て制限」画面で「保存」ボタンをクリックします。

作業ゾーン別に割当ステータスを更新するには:

1. 変更するセルを右クリックします。

2. 「作業ゾーン別ステータス」メニュー項目をクリックします。

3. 更新する作業ゾーンの識別: 作業ゾーンのリストを視覚的に検査するか、検索フィールドを使用して更新する作業ゾーンを検索してプロセスを迅速化します。

4. 選択した作業ゾーンがオープンのままにしておく作業ゾーンであることを確認しますが、未チェックの作業ゾーンはクローズ済とみなされます。

5. 「変更」ボタンをクリックして選択内容を確認します。

6. 変更を保存するには、「割当て制限」画面で「保存」ボタンをクリックします。

一括移入の視覚化の向上

「一括移入」画面には、操作のすべての設定をより直感的に定義するために、フィールドが論理的な順序で表示されます。

ビジネス上の利点

• シンプルで一貫性のあるユーザー・エクスペリエンスにより、ユーザーは目標をより効率的に管理できます。
• 再発自動入力オプションが有効になっているセルを迅速に識別し、残りの割当て値に基づいて潜在的な問題のある領域を認識できるようにすることで、より効率的なディシジョン・プロセスを促進します。 これにより、外部ツール(スプレッドシートなど)内で反復的なタスクや計算を実行する必要がなくなります。
• 表画面内のデータの選択および編集にキーボード・ショートカットを使用するユーザーのニーズに対応することで、アクセシビリティを強化します。

有効化のステップ

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

ヒントと考慮事項

• 予約間隔は、予約が予約間隔に基づくキャパシティ・エリアの表に組み込まれています。 これは、「割当構成」画面の「日別割当」セクションで「営業時間プランの%としての目標の入力」設定が選択されている場合に有効になります。
• セルをロックする機能は、24A更新で非推奨と発表され、「割当て制限」画面で使用可能なすべてのビューから削除されました。

コア・アプリケーション

「Where's My Technician」画面のバナー

24Bの更新により、企業はWhere's My Technicianのテーマに最大5つのバナーを追加できます。 この新機能は、顧客エンゲージメント戦略の改良を目指す企業にとって多彩な機会を提供します。 補完的な製品のプロモーションから、タイムリなアップデートや顧客との対話的なエンゲージメントまで。

• バナーは、補完的な製品やサービスを促進するために利用でき、手頃な価格のアップグレードや関連サービスを検討するよう顧客に促します。

• 企業は、情報バナーを使用して、更新、お知らせ、または重要な通知を顧客にタイムリに提供できます。

• クリック可能なバナーを使用して、顧客をインタラクティブにエンゲージし、詳細な情報を確認したり、アンケートへの参加をガイドしたり、提供されたサービスに対する満足度を表現できます。

• 企業はバナーを活用して、自社の製品やサービスの新機能や利点、機能について顧客を教育し、顧客維持と満足度を向上させることができます。

• バナーを戦略的に配置して、「Where's My Tech」画面の視覚的な魅力を高め、より魅力的なユーザー・エクスペリエンスを提供できます。

複数のバナーが同じ画面に追加されると、5秒ごとに動的に回転します。 モバイル・デバイスでWMT URLにアクセスするユーザーは、バナーをスワイプできます。 デスクトップ・デバイスでは、ユーザーは左右の矢印ボタンをクリックしてバナーを変更できます。このボタンは、ユーザーがバナー領域の上にカーソルを置くと表示されます。

ビジネス上の利点

• マーケティング・キャンペーンにインタラクティブな要素を使用して、ユーザー・アウトリーチを拡大する機能を提供します。

• クロス・セルおよびアップセルの商談を作成します。

• 特徴的なバナー・デザイン、インパクトのあるブランド・メッセージ、インタラクティブな機能など、WMT画面に追加の要素を組み込むことで、ブランド認知度を向上させます。

• クリック可能なバナーを統合することでユーザー・エンゲージメントを向上させ、顧客満足度調査およびレビュー・リクエストによるインサイトの収集を促進します。

• 企業が、既存の規制やポリシーに関する顧客の重要な発表や更新をエンド・カスタマと共有できるようにすることで、効果的なコミュニケーションを促進します。

有効化のステップ

「Where's My Technician」画面でバナーを構成する方法

1. 「構成」>「テーマ」>「Where Is My Technician」セクションで、「Where Is My Technicianテーマ」画面を開きます。

2. 「バナー」タブをクリックして、バナー構成画面を開きます。

3. 新しいバナーを追加するには、「バナーの追加」ボタンをクリックします。

4. ポジション : 「上」または「下」のいずれかを選択します。 選択したオプションは、WMTテーマ用に構成されたすべてのバナーに適用されます。 テーマにロゴがアップロードされていない場合は、かわりに画面上部のバナーを使用することもできます。

5. バナー: ローカル・デバイスからアップロードするイメージを選択します。

   ノート: 推奨バナー高さは48px、幅は768pxです。 携帯電話のサイズに基づいて、高DPI (Retina)画面のスケール・アップ・バージョンを使用して320px.Considerに切り捨てることができます。

6. バナーのヒント: ユーザーがマウスでイメージの上にマウスを置いたり、アクセシビリティ・リーダーを使用したりしたときにイメージの説明として使用されるテキストを入力します。

7. 画面: 特定のバナーを表示する画面を選択します。 画面が選択されていない場合、バナーがWMT画面に表示されません。

8. Webページ: クリック可能なバナーに変換するには、ユーザーがバナーをクリックしたときに開くURLをwebサイトに追加します。

9. 追加のバナーを「追加」するには、「バナーの追加」ボタンをクリックします。

10. 構成画面の上部にある「プレビュー」セクションを使用して、エンド・ユーザーの構成済バナーの外観を確認します。 「プレビュー」画面をクリックして、構成したバナーを拡大およびスクロールします。 イメージをクリックして更新することもできます。

11. 変更を「保存」します。

ヒントと考慮事項

• ユーザーは、WMTテーマごとに最大5つのバナーを構成できます。

• 複数のバナーが構成されている場合、デフォルト設定では、イメージが5秒ごとに自動的に回転します。

• バナーは、最大サイズ150KBのJPEG、PNG、SVGまたはGIF形式のイメージをサポートします。

一括割当リスク確認

24B以降では、ドラッグ&ドロップで多数のアクティビティを割り当てると、明確な警告が表示されます。 ユーザーは、処理による潜在的な影響を確認した後にのみ、割当を続行できます。 ダイアログが表示されるタイミングを決定するロジックは変更されていません。

• 割当の潜在的影響のユーザー確認

有効化のステップ

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

作業手配コンソール活動リスト・ユーザー・エクスペリエンス

以前は、ディスパッチ・コンソールのリスト・ビューが画面の幅にあわせて調整されていたため、列幅が小さくなり、表示されない列になることがあります。 ディスパッチャがより多くのデータを表示できるように、動作が変更されました。

1. リスト・ビューに構成されたすべてのカラムが常に表示されます。 すべてのデータを表示する領域がない場合は、水平スクロールが表示されます。
2. 各列の幅は、ユーザーが調整し、セッション間で保持できます。
3. リスト・ビュー内に一度に表示されるように最大50列を構成できます。
4. 「列の管理」画面が「表示」メニューの下のページ・ヘッダーに移動しました。
5. リスト・ビューの行の高さは自動的に変更されなくなります。 複数行プロパティの最初の行がデフォルトで表示されます。 ユーザーは必要に応じて行の高さを調整できますが、これはセッション間で維持されません。
6. リスト内のデータを強調表示して選択する機能。

列ヘッダー・セパレータをドラッグするか、列ヘッダー・コンテキスト・メニューを使用して、列の幅を変更できます。 1つの列の幅変更は、別の列の幅には影響しません。

どのアクティビティ・プロパティを表に表示するか、どの順序で表示するかを管理できます。 「列の管理」画面は、ページ・ヘッダーの「表示」ボタンをクリックし、「列の管理」リンクをクリックすることで確認できます。 ダイアログが表示され、最大50列を選択できます。 次の2つの特別な列があります:

1. アクティビティ - 常に表示され、非表示にすることはできません。 アクティビティと移動時間を表すカラー・バーが表示されます。
2. リソース - は、「列の管理」画面で列が選択されている場合、「表示」ポップアップで「階層的に適用」チェック・ボックスが選択されている場合、およびリソース・ツリーで組織単位が選択されている場合に表示されます。 つまり、複数のリソースのアクティビティがリスト・ビューに表示されます。 ただし、この列を永続的に非表示にすることは可能です。

選択したカラムの順序と幅は、ユーザー・セッション間で保持されます。

表セルに複数行文字列が含まれている場合、1行目のみが表示され、2行目からの小さな部分が、複数の行があることを示すヒントとして示されます。 チェックボックスがある最初の列内で行セパレータをドラッグするか、コンテキスト・メニューを初期化することで、行の高さを変更できます。 行の高さは、セッション間、またはリソース・ツリーから別のリソースを選択するか、別の画面に移動する場合でも保持されません。

表の個々のセルのデータをコピーするには、コンテキスト・メニューを開き、「コピー」をクリックします。

1. アクティビティ・リスト・ビューの再構成の削減
2. 関連するデータのアクセシビリティの向上

有効化のステップ

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

近くのアクティビティAI推奨

アイドル時間を埋めるために追加の作業を提案することで、技術者の生産性を向上させます。 機械学習を使用して、OFSは、移動時間を含む複数のファクタに基づいて、リソースのルートに最適な最大3つのジョブを提案します。 ユーザーは、各ジョブの詳細、マップ上の予測および更新されたルート、および予定到着時間を含む次の計画アクティビティの詳細をレビューできます。

推奨によってルート上のアクティビティが危険にさらされたり、アクティビティが危険にさらされることはありません。 つまり、現在のルートからの他のアクティビティは、提案されたアクティビティが割り当てられた後、タイム・スロット、サービス時間枠、通信された時間枠またはSLAからプッシュ・アウトされません。 ルーティングされたアクティビティがすでに危険状態にある場合、推奨アクティビティが割り当てられた後はそれ以上影響を受けません。

現在のルートに適合する使用可能なアクティビティがある場合、アクティビティは「完了」または「未完了」処理の実行後に割当用に提案されます。 提案はオンライン・モードでのみ使用できます。

たとえば、技術者がオン・サイトに到着し、割り当てられた作業をスケジュールより30分以上前に完了するように管理している場合、または顧客がノー・ショーになり、直前の取消になった可能性があります。 このような状況では、特に次の顧客が現在スケジュールされている時間より早く予想していない場合、技術者のアイドル時間がすぐに発生する可能性があります。 技術者が現在のアクティビティを完了(または一時停止)すると、OFSはこの使用可能な時間を検出し、その領域で使用可能なすべての作業を評価して、技術者の制約内で完了できる他のアクティビティを特定します。 現在のロケーション、次のアクティビティの詳細、利用可能時間、必要な移動時間、アクティビティの制約などを含む複数のファクタに基づいて、その日の残りのルートに悪影響を及ぼすことなく、追加の作業をピック・アップするための推奨事項が技術者に提供されます。

近くの推奨事項

マップの詳細は次のとおりです:

1. 青色のマーカーは現在のリソースのロケーションを反映
2. 提案された活動。 1つのアクティビティが事前選択されています。
   • アクティビティは、他のマップ・ビューと同じマップ・マーカーを使用して表示されます。
   • 各アクティビティには、このアクティビティを追加した後のルートの変更方法、提案されたアクティビティの所要時間、およびロケーションにアクセスするために必要な追加の移動時間など、ルートへの影響を示すヒントが含まれています。
   • 選択したアクティビティのヒントのバックグラウンドが暗くなっています。
   • 濃い青のルート線は、現在のロケーションから推奨アクティビティへのパスを示します。
   • 明るい青のルート線には、提案されたアクティビティから次の計画済アクティビティへのパスが表示されます。
   • 灰色のルート線は、現在のロケーションから次の計画アクティビティまでの予測ルートを反映します。
3. 現在の日付にスケジュールされたアクティビティは保留中ステータスです。
4. 終了ロケーション

ユーザーは、マップから異なる提案を選択できます。 このルートが再構築されると、選択したジョブの詳細がパネルで更新されます。

パネルの詳細は次のとおりです:

1. 選択した推奨アクティビティの詳細:
   • クリック可能な電話番号
   • 追加移動時間
   • アクティビティ期間
2. 次を含む次の計画アクティビティの詳細:
   • 予想到着時間
3. 「リストの表示」ボタンは、全ページ・リスト・ビューですべての提案を表示
4. 「スキップ」ボタンを使用すると、ルートへの推奨アクティビティの追加をスキップできます。 スキップ事由が構成されている場合(次を参照)、事由を選択する必要があります
5. 「ルートに追加」ボタンをクリックすると、選択したアクティビティがルート内の次の位置に追加され、「ルート途中」ステータスに切り替わります(この機能が有効になっている場合)。

リアルタイム・トラフィック・データの使用

移動時間は、ユーザー・タイプに対して「リアルタイム・トラフィック・データの使用」チェック・ボックスが有効な場合、リアルタイム・トラフィック・データを使用して推定されます。 これには、「超過移動時間」および「予想到着」フィールドが含まれます。 現在のリソース位置(ユーザーのデバイスによって収集)が移動の開始点として使用されます。 過去1分間にリソースのジオロケーションが収集されない場合、完了(または未完了)アクティビティの座標が移動の開始点として使用されます。

スキップ事由

「ビジネス・ルール」画面の「アイドル時にアクティビティをスキップする理由」セクションで「スキップ理由」が構成されている場合、推奨アクティビティを却下するときに選択することが必須になります。 選択できるのは、有効なスキップ理由のみです。 リストは事前構成されており、新規アイテムを追加できません。 特定の項目を有効または無効にすることのみ可能です。

ダッシュボード

新しいレポート「Additional Jobs Accepted」が追加されました。 選択した月のリソース当たりのアイドル時に提示された承認済アクティビティの合計数が表示されます。

• アイドル時間を埋めることで技術者の生産性を向上
• 技術者が追加のジョブをピック・アップできるようにします
• 計画作業を危険にさらすことなく、技術者がアクティビティを自分で割り当てることができます
• 最小限の移動時間でアクティビティを追加することで、移動時間を短縮
• アナリティクスによる継続的な改善と導入を推進

有効化のステップ

次のすべての条件が真の場合、アクティビティは「完了」および「未完了」アクションの後に提示されます:

1. ユーザー・タイプに対して「アイドル時にアクティビティを提案」権限が有効
2. 現在のアクティビティには、アクティビティ・タイプに対して「移動の計算」チェック・ボックスがマークされています
3. 現在のアクティビティに座標があります
4. ユーザーはリソース資格証明でサインインしています。 他のリソースのルートに移動する場合には適用されません。

ヒントと考慮事項

他の機能に関連する「ユーザー・タイプ」画面の権限が、'事業所別のアクティビティの提示'から'開始する同じロケーションのアクティビティの選択'に名前変更されました

メタデータAPI: マップ・レイヤー・アセットのサポート・ボタン

マップ・レイヤーAPIメソッド「カスタム・マップ・レイヤーの作成」、「カスタム・マップ・レイヤーの取得」、「カスタム・マップ・レイヤーの移入」および「カスタム・マップ・レイヤーの置換」がサポートされるように改善されました:

1. マップ・レイヤーのヒントのボタン
2. カラム'プラグイン/フォーム・フィールド'。 このプロパティの値は、開いているプラグイン/フォームに渡されます。

マップ・レイヤー

リクエストの例:

GET /rest/ofscMetadata/v1/mapLayers/{label}

フィールドが追加されたレスポンスの例:

レスポンス・ソースの縮小

{    

"label": "port",

"type": "internal",   

 "status": "active",    

"text": "port name",    

"translations":       [        

{            "language": "en",           

 "name": "port",            

"languageISO": "en-US"        

}    

],    

"shapeHintColumns": [        

{            

"sourceColumn": "CARGOWHARF",            

"defaultName": "cargo",            

"pluginFormField": "cargofields"        

}    

],    

"shapeHintButtonColumn":   {        

"actionType": "form",       

 "label": "mobile_inventory_request#24#"    

},    

"tableColumns"  [        

"ANCH_DEPTH",        

"CARBCHMOOR",       

 "CARGMDMOOR",        

"CARGODEPTH",        

"CARGOWHARF",       

 "CARGO_ANCH",       

 "CARICEMOOR",        

"CHAN_DEPTH",        

"WATER"    

],    

"links": [        

{            

"rel": "canonical",            

"href": "https://frontend.ofsc.team/rest/ofscMetadata/v1/mapLayers/port"        

},        

{            

"rel": "describedby",            

"href": "https://frontend.ofsc.team/rest/ofscMetadata/v1/metadata-catalog/mapLayers"        

}    

]

}

json

APIを介したマップ・レイヤーとの完全な統合をサポートします。

有効化のステップ

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

ルーティング

バンドル・アクティビティおよびリンク・アクティビティの一括ルーティングの改善

同じバンドル・キーを持つ特定のアクティビティのパラレル実行を許可

一般的に、ルーティングでは、同じバンドル・キーを持つアクティビティを重複する期間で実行できません。 ただし、複数のアクティビティを同時に実行できる場合があります。次に例を示します:

• 同時に開始リンクにリンクされているアクティビティ
• リソース制約が異なる開始-開始リンク・タイプにリンクされているアクティビティ
• サービスとCommunicated Windowsが重複しているアクティビティ(両方のアクティビティが制約違反なしでは収まらない)

アクティビティが並行して実行に適格であるとみなされる場合でも、最適化エンジンによって、選択した最適化目標に従ってより適切な最適化が提供される場合、最適化エンジンによって順序付けされる可能性があることに注意してください。

作成された動的チームに従うためのルーティング

「同時に開始」としてリンクされた一連のアクティビティに割り当てられた2つ以上のリソースは、「動的チーム」とみなされます。 ルーティングでは、一度作成した動的チームに従うことを希望し、同じリソースに類似リンクされたアクティビティの次のセットを割り当てます(その割当が選択した最適化目標に対してではない場合)。

事前割当済セグメントを含むセグメント化可能アクティビティの連絡済ウィンドウの尊重

セグメント化可能アクティビティの一部が割り当てられているかどうか(事前割当済セグメントか非配分済セグメントか)を追跡します。 セグメント化可能アクティビティの一部が割り当てられていない場合 - コミュニケーション・ウィンドウを適用し、存在する場合はサービス・ウィンドウを適用します。 システムの他の部分との互換性を維持するために、ルーティングでは、そのようなアクティビティに事前割当済セグメントがない場合のみ、最初のセグメントのセグメント化可能アクティビティ「連絡済ウィンドウ」に関する情報が使用されるようになりました。 1つ以上の事前割当済セグメントがある場合、新しく作成されたセグメントでは「連絡済ウィンドウ」の値は無視されます。

大量の事前割当済アクティビティがある場合に、相互リンク・アクティビティの割当を改善

割り当てられたアクティビティの数は、「同じ日」の制約があるリンクとともにリンクされている何千ものアクティビティを含むデータセットでかなり大きくなりました。

ルーティング保証計算の向上

得られた解決の質をよりよく反映するために、保証計算のアルゴリズムが改良された。

ルーティングでは、特に、同じバンドルされたキー値を持つアクティビティまたは同じ日でリンクされたアクティビティを含むデータセットに対して、開始または同時アクティビティ・リンク・タイプのソリューション品質がさらに向上します。

有効化のステップ

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

HEREマップの一括ルーティングSLR

HEREマップのストリート・レベル・ルーティングが一括ルーティングでサポートされるようになりました。

HEREマップを使用した顧客向けルート・ソリューションの改善

有効化のステップ

一括ルーティングでのSLRの使用を有効にするには、一括ルーティング・プラン設定の「移動時間」セクションにある「SLRの使用」チェック・ボックスを選択します。

プラグイン・フレームワーク

プラグインでワークフローのサポートを改善

プラグインからアクティビティを開始する場合、OFSは、構成された条件に基づいて、関連付けられたワークフローを動的に決定します。これは、OFS内でアクティビティを直接開始する場合の動作に似ています。 ワークフローは、「保留」および「ルート途中」ステータスのアクティビティに対してプラグインによって設定することもできます。 以前は、プラグインは受信APIコールを介してアクティビティのワークフローのみを設定できました。

構成

最初のステップとして、顧客はアプリケーションを適切に構成する必要があります。 ワークフローを処理するプラグインの「使用可能なプロパティ」に「アクティビティ・ワークフロー」を追加する必要があります。

アプリケーションはこのフィールドを使用してワークフローのラベルを保存するため、アクティビティとワークフローの関連付けを維持します。

動的ワークフロー計算

この機能から利点を実現するには、クライアントは単にプラグインを使用してアクティビティを開始し、ワークフロー条件を構成する必要があります。 その後、アプリケーションは自動的に次のことを行います:

• アクションの実行時にプラグインから渡されたアクティビティ・フィールド、プロパティおよび更新の値に基づいてワークフローが計算されます。
• ワークフローは「開始済」に設定されているため、アクティビティに関連付けられます。

サポートされているアクション

プラグインAPIフレームワークを介した次のアクションがサポートされています:

アクティビティの開始

開始済アクティビティの作成

情報

「アクティビティ・ワークフロー」フィールド(この関連付けを保守する)が空の場合、アプリケーションはワークフローを動的に計算し、ワークフローへのアクティビティの関連付けを確立します。

プラグインからワークフローを設定

ワークフロー・ラベルはプラグインから直接設定できます。 そのためには、ワークフローを定義し、ワークフロー・ラベルをアプリケーションに渡すロジックを実装する必要があります。 他のAPIと同様に、アクティビティのワークフローを「保留中」および「ルート途中」ステータスに設定できます。

サポートされているアクション

プラグインAPIフレームワークを介した次のアクションがサポートされています:

アクティビティの更新

アクティビティの作成

アクティビティの開始

開始済アクティビティの作成

この機能は、アプリケーションの組込みの「コードなし」機能により、統合作業を減らし、ワークフローの「本番稼働までの時間」を短縮します。

この機能のもう1つの利点は、プラグイン内のワークフローに関連するロジックをカプセル化し、その結果、プラグインからワークフローを直接設定できることです。

有効化のステップ

この機能を有効にするには、プラグインの構成内の「使用可能なフィールド」に「アクティビティ・ワークフロー」フィールドを追加する必要があります。

フィールドが追加されない場合、ワークフローは動的に計算されるときも、プラグインから指定されるときも、アクティビティに関連付けることができません。

ヒントと考慮事項

アクティビティの「作成/更新」コマンド内でパブリックAPIを介してワークフローを設定する機能は、現時点では同じままです。 したがって、顧客は、新しいリリースへの更新時に統合を変更する必要はありません。

モバイル・プラグイン・フレームワークでのREST APIへのアクセスの簡素化

24Bリリースのお客様は、JWTアクセス・トークンを介してカスタム・プラグインからフィールド・サービスREST API、Fusion REST APIまたは外部APIにアクセスする機会を得ることができます。 プラグイン構成画面は、利用可能なアプリケーションを選択できる新しい「アプリケーション」セクションで拡張されました。 構成されると、モバイル・プラグイン・フレームワークは、すべての構成済アプリケーションを'init'ステージのプラグインに送信します。 新しいgetAccessTokenプロシージャは、直接APIコールの認可に使用されるJWTアクセス・トークンを返します。

企業は、JWTアクセス・トークンを介してカスタム・プラグインからフィールド・サービスREST API、Fusion REST APIまたは外部APIにアクセスする機会があります。 getAccessTokenプロシージャは、直接APIコールの認可に使用されるJWTアクセス・トークンを返します。 プロシージャは、"open"/"wakeup"メソッドで送信される"allowedProcedure"コレクションにリストされ、プロシージャが使用可能であることを示します。

{

"apiVersion": 1,

"method": "open"/"wakeup",

"entity": "...",

...

"buttonId": "...",

"openParams": {},

"allowedProcedures": {

...

"getAccessToken": true

}

}

initステージで、OFSは、特定のプラグインに対して構成されたアプリケーションのデータをinitメソッドで返します。

「resourceUrl」フィールドには、リソース・サーバーのURLが移入されます。 フィールド・サービスAPIアプリケーションの場合は、直接REST APIリクエストで使用するために、プラグインのURLが移入されます。 OAuthユーザー・アサーションまたはOAuthクライアント資格証明アプリケーションの場合は、「アプリケーションの変更」画面で構成されているものと同じように再チューニングされます。

initメソッド

{

"apiVersion": 1,

"method": "init",

"attributeDescription": {},

"buttons": [],

"applications": {

"ofs_rest_api": {

"type": "ofs",

"resourceUrl": "https:// plugins-0-ofsc-xxxx.test.fs.ocs.oc-test.example.com",

},

"fusion_rest_api": {

"type": “oath_user_assertion",

"resourceUrl": "https://fa-xxxx-pintlabfadev.fa.ocs.oc-test.example.com"

},

"external_rest_api": {

"type": "oauth_client_credentials"

"resourceUrl": "https://external-rest-api-url.example.com"

}

}

「プラグイン編集」画面で構成されていないアプリケーションを含むinitメソッド

callProcedureResultメソッド - 失敗ケース

コール・プロシージャのエラー処理参照用 - https://docs.oracle.com/en/cloud/saas/field-service/fapcf/c-errorhandlingcallprocedure.html#ErrorHandling-225CDFAF

プラグイン・コンフィギュレータに必要なAPIのキーおよびコメントを指定

開発者は、プラグインがAPIをリクエストするために必要なアプリケーションのキーおよびコメントを指定できるプラグインのXMLファイルを準備できます。 そのため、コンフィギュレータがプラグインXMLをインポートすると、「プラグイン編集」画面の「アプリケーション」セクションに、プラグインに割り当てて必要なAPI.Keyへのアクセスを提供する必要があるアプリケーションがプラグインのコードでハードコードされる可能性があります。 コンフィギュレータは、it.Commentに使用されるリストからアプリケーションを選択し、どのアプリケーションを選択するかの詳細をコンフィギュレータに提供します。

プラグイン構成画面

ホストおよび外部プラグイン用の新しい「アプリケーション」セクションが画面に追加されました。

この項の各アプリケーションには、次の属性があります:

• キー- フィールド・サービスの既存のアプリケーションに関連付けるプラグイン・コードで使用されるアプリケーションの識別子。
• コメント- このAPIの詳細を提供できる必要なアプリケーションの説明(例"Fusion SCMから在庫リストを取得するため")。

プラグインがXMLファイルとともにインポートされ、必要なアプリケーションがそこに指定されると、コンフィギュレータは「アプリケーション」セクションのリストにキーと説明を表示し、ドロップダウン・リストから適切なアプリケーションを選択できます。

アプリケーションが関連付けられていない場合、APIアクセスはプラグインに提供されません。 選択したアプリケーションがサポートされているタイプでない場合、モバイル・プラグイン・フレームワークはエラーを返します。

スクリーン1

プラグインがForms &プラグイン画面から追加された場合、「アプリケーション」セクションはデフォルトで空になり、コンフィギュレータは「追加」ボタンをクリックして「キー」フィールドにアプリケーション識別子を指定し、必要なコメントを追加することで、最初から追加できます。

スクリーン2

現在のユーザー表示に従ってフィールド・サービスREST APIコールを制御

JWTアクセス・トークンによるREST APIコールへのアクセスを現在のユーザーの表示に制限する場合は、「アプリケーション詳細」チェック・ボックスを有効にする必要があります。

REST APIコールが、現在のユーザーの「可視リソース」リストの外部のリソースからデータを取得しようとすると、そのデータは拒否されます。

スクリーン3

• フィールド・サービス、Fusionアプリケーションおよびその他の外部アプリケーションのREST APIへのアクセスの簡略化された構成。
• 他のOracle製品との連携の標準化。

有効化のステップ

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

サービス・ロジスティクス

Fusion品目カタログまたは組織を使用した部品カタログの登録

品目カタログまたは組織を使用して部品カタログを登録すると、(Fusion)品目カタログまたは組織から品目をインポートし、それらをフィールド・サービスの部品カタログとして使用できます。 登録時に、同期する特定のフィールドを選択して、将来の部品カタログの構造を定義できます。

説明機能は、「部品」「カタログ」画面を介して、(Fusion)品目「カタログ」または組織を登録し、その品目データをフィールド・サービスの部品「カタログ」として使用する機能を提供します。

カタログ

次に示すように、使用する品目のフィールドを構成することで、将来の部品カタログの構造を定義できます:

構成

カタログを登録すると、フィールド・サービス・システムによって定義済構成の部品カタログが作成され、関連品目を含むソース品目カタログまたは組織から品目データが自動的にインポートされます。

インポートが完了すると、部品カタログが定期的に更新され、新しい追加品目がソース品目カタログまたは組織に追加され、存在しなくなった品目も削除されます。

この機能により、既存の品目カタログまたは組織データからフィールド・サービスに簡単に統合でき、オフライン・モードでフィールド・リソースで使用できるようになります。 また、異なる構造の部品カタログを同じソースから登録し、適切なユーザー・タイプに割り当てることで、異なるユーザー・タイプ間でデータ・アクセスを分離することもできます。

有効化のステップ

機能を使用できる唯一の前提条件は、「Fusionカタログの使用」パラメータを有効にして、タイプ「Oracle Fusionサービスおよびサービス・ロジスティクス」のアプリケーションを追加して正しく構成することです。

ヒントと考慮事項

• データ項目の同期には時間がかかり、ソース品目カタログまたは組織のサイズによって異なります。

統合

フィールド・サービス・メンテナンス・ビジネス・アクセラレータでの倉庫機能のサポート

現在、Field Service Maintenance Cloud Acceleratorでは、車両またはバケット・タイプのリソースをOFSに格納しています。 24Aの特徴の導入を使って: フィールド・サービスで新しいリソース・タイプ・ロール「倉庫」が導入されたアクティビティ関連工程の倉庫のサポート。 この拡張の目的は、フィールド・サービス・メンテナンス・クラウド・アクセラレータの一環として、倉庫タイプのリソースに在庫を保存できるようにすることです。 これにより、フィールド・リソースは、アクティビティが割り当てられたときに倉庫から在庫を直接取り付けることができます。

フィールド・サービス - Maintenance Cloudアクセラレータは、トラック/バケット・リソースに加えて、Fusion在庫管理システムからフィールド・サービスの倉庫リソースへの在庫同期をサポートするように拡張されています。 この機能の主な側面は、Fusion在庫管理から在庫品目を取得し、フィールド・サービス倉庫に格納する機能です。 この機能では、Fusionインベントリ管理からのバルク&増分更新の両方がサポートされます。 フィールド・リソースがアクティビティに割り当てられると、倉庫リソースとして構成された在庫組織または保管場所が優先リソースとして追加されます。 これにより、フィールド・リソースは在庫にアクセスし、倉庫から直接在庫を設置できるため、フィールド・リソースとトラック・リソースの間のチーム・ワークで在庫を共有する必要がなくなります。 全体として、この機能により、Fusionインベントリとフィールド・サービスの間で在庫が効果的に管理され、デポ修理サービスなど、すべての在庫が利用可能な特定のロケーションで稼働する技術者にとって特に有用であることが証明されます。

有効化のステップ

高レベル・アーキテクチャ(論理ビュー)

作業指示の同期中に作業オーダー工程から供給保管場所を取得するように既存のメンテナンス・アクセラレータが変更され、対応するOFSが検索されて、優先倉庫として作業オーダー・アクティビティにリソースが割り当てられます。

技術設計(実装ビュー)

Oracle Maintenance OFS Upsertアクティビティ・ヘルパー統合は、新しいサブ統合Oracle Maintenance OFSウェアハウス・リソース・ヘルパーをコールして、有効な倉庫リソースを取得し、優先倉庫としてアクティビティ作成呼出しに渡されるように変更されました。

変更されたOIC統合:

• Oracle Maintenance OFS Upsertアクティビティ・ヘルパー - サブ統合を使用して有効な倉庫リソースを検索するために、アクティビティ作成の「リソース・フローあり」および「リソースなし」に新しいスコープが追加され、アクティビティの優先倉庫として倉庫リソースIDを渡すためにアクティビティ作成起動が変更されました
• Oracle Maintenance OFS Warehouseリソース・ヘルパー - これにより、作業オーダー工程に存在する各品目が反復処理され、次から有効な倉庫リソースが検索されます

OIC構成参照:

参照名: ORCL-BRT-MNT-OFS-CONFIG

Table

ヒントと考慮事項

デプロイメント・ビュー

作業指示をOFSに同期する前に、ビジネス・ケースに従って次のOIC参照値を構成する必要があります。

1. ORCL-BRT-INV-TYPE-MAPPINGは、在庫リソースをOFSの倉庫リソースとして同期するように構成する必要があります。
2. 参照名: ORCL-BRT-MNT-OFS-CONFIG

table1

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

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

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

新しい廃止/ 削除

以前に発表された非推奨