10 Mobile Application (SOCS)

There are two mobile clients available.

  1. Oracle mobile application (MAF) platform based

    The mobile client provides all day-to-day transactional workflows within an Oracle Mobile Application Framework (MAF) platform. MAF is a hybrid-mobile platform that supports both iOS and Android devices. For more details, please see Oracle Retail Store Operations Cloud Service Mobile Guide.

  2. Oracle Jet mobile based

    There is a new Jet Mobile client available for both Android & iOS. The Android version can be downloaded as APK. The iOS version needs to be built from downloaded framework/library. For more details, please see Oracle Retail Store Operations Cloud Service Mobile Guide.

    The JET Mobile client can also be run in a Web browser (with scanning constraints).

Implementers are strongly encouraged to adopt the Jet Mobile client (over MAF based mobile UI) since Oracle has decided to sunset the Oracle MAF platform.

For more information, please see SIOCS JET Mobile Adaptation Reference Paper (Doc ID 2614551.1) in the Oracle Retail Store Inventory Operations Cloud Services Documentation Library.

Configure Manual Quantity Entry Mode

For MAF client, you need to set the numeric entry popup on MAF will have its mode defaulted to either scan mode or override mode.

For details, see the Oracle Retail Enterprise Inventory Cloud Service Administration Guide Configuration chapter.

Enable Mobile Functionalities

By default, the EICS application installer set following value as false.

input.sim.mobile.client.enabled = false

By disabling Access Execution UI, Mobile Client (SOCS) access on the following functional areas is disabled. If a customer has purchased SOCS subscription Mobile functionalities would be enabled during environment provisioning.

  • Access Item Basket

Mobile Device Management (MDM)

Retailers need to use their own MDM infrastructure to push mobile updates to each store/device.

Due to corporate guidelines, Oracle Retail SOCS is not permitted to be distributed via Google or Apple Play Stores.

We have concerns that any MDM (Mobile Device Management) tool that relies on Google Play Store – even when used in enterprise-managed-deployment mode — may also not be allowed as part of the contractual agreement.

Retailers should not be using any MDM tool that uses Google Play Store – either directly or indirectly. 

Examples of MDM tools that rely on Google Play Store are ManageEngine MDM, Microsoft Intune, Radix MDM, and Vantage MDM.

Note:

Please note that this list is not a complete list. There are 100s of MDM tools available, so Retailers need to do their own verification. 

In case your corporate already uses one of these MDM tools (that rely on Google Play Store) your options could be:

  • Explore the MDM administration, to see if it offers a configuration to use its own internal cloud storage for the application instead of using or indexing the Google Play Store.

  • Explore the MDM administration, to see if it offers a configuration that allows a different MDM tool to be used for SOCS Mobile — one that does not use Google Play Store.

  • Move away from such a MDM tool to another MDM that does not use Google Play Store directly or indirectly.

Working with Federated Security

What is out of the box deployment

  • As part of the SIOCS provisioning, IDCS applications are created by Oracle Retail.
  • The User setup is managed by Retailers.
  • Native IDCS Login is supported by default (Authentication of Users directly in Oracle Identity Cloud Service (IDCS) using credentials stored within IDCS).

What is in Retailer's/ Implementer’s control

  • Federated security setup
    • A federated security model is an approach for identity and access management that allows users to access resources across multiple domains using a single set of credentials.
    • Authentication happens through an external identity provider (IdP) such as Azure AD, Okta etc.
    • Identity Provider (IdP): This entity stores and verifies the user's credentials (like a username and password). It authenticates the user and issues a secure token containing verified information about them. Retailers can have any access management system, it can be OKTA or Microsoft Azure Active directory or any other system.
    • Service Provider (SP): This is the application or resource that the user is trying to access. It trusts the token issued by the IdP and grants access based on the information it contains, without needing to re-authenticate the user.

      Note:

      In this context it would be Oracle’s IDCS (identity management cloud service).
    • Since the Retailer controls and manages
      • IDCS Tenancy,
      • Internal Enterprise Identity System (OKTA or Azure AD or ..),
      • Federated Setup,
      • Mobile Devices,
      it is the implementer's and retailer’s responsibility to manage this aspect of deployment.

      Important:

      Oracle Retail will not be able to help or troubleshoot retailer-specific configurations.

      Implementers and retailers need to make sure that both Federated LOGIN and LOGOUT flows work correctly across all applications prior to go live.

    • Overview of Federated LOGIN steps via SAML setup
      • User accesses Oracle Retail application
      • Application checks for authN session; if none exists, it redirects user to Oracle IDCS (SP)
      • Oracle IDCS, configured as “SP”/ Service provider, recognizes that application is federated (SSO/single sign on) with IDP (Okta or Microsoft Azure AD or ..) and generates a SAML authN request to configured IDP.
      • The IDP presents a login page (if no active session exists) for user to enter credentials with or without MFA (multifactor authentication - if configured)
      • Upon successful authentication IDP generates SAML response and redirects back to IDCS
      • If the user profile exists, IDCS creates an authenticated session for the user and redirects the user back to original requesting application with security context
      • User is now authenticated and access is granted
    • Overview of user initiated LOGOUT (single logout attempt via SAML setup)
      • User initiates logout on Oracle Retail application
      • Application destroys local session and redirects to Oracle IDCS
      • IDCS initiates a SAML Single Logout (SLO) request to IDP (Okta or Microsoft Azure AD or ..) instructing it to end user session at IDP
      • IDP processes the logout request and ends user’s session for IDCS application and - if configured - terminates the associated SSO sessions
      • IDP redirects user back to IDCS with a logout response
      • IDCS / SP completes its own logout process and redirects user to configured post-logout re-direct URL