Skip to content

Creating a Build Job

Create a build job for the selected application.

A build job merges both project settings, and build settings, such as signing profiles. Select the Create Build Job button to create a build job for Mobile Development Kit Client. For mobile card kit the button only appears if no build job is defined.

As a developer you can configure multiple Custom Mobile Development Kit Client configurations in parallel to experiment with branding and other build settings. You can switch between configurations, see the build job status, drill down to the build job details and executions logs, and experiment with installing the app on the device via QR Code. See Creating a Build Job for Customized Mobile Development Kit Clients for details.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/Hybrid or SAP Mobile Cards.

  2. Select an application, then select Cloud Build under Assigned Features (or add it first); or select Features > Cloud Build for mobile card kit.

  3. Select Create Build Job to create a new build job.

    For mobile card kit, only one build job is allowed, so the button does not appear if a build job already exists. You need to either edit the current build job, or delete it and create a new one.

  4. In Create Build Job, select a client type.

    Supported client types include the following:

    • Mobile Development Kit Client
    • Customized Mobile Development Kit Client clients
    • SAP Asset Manager
    • Mobile Card Kit Client (SAP Mobile Cards application only)

    For information about the different app types and required packaging details, see Supported Client Types, Packaging Details, and Build Options.

  5. Fill out the basic information for the selected client type. The fields are dynamic and appear depending on the selections you make.

    For information see Supported Client Types, Packaging Details, and Build Options.

  6. Fill out the platform information page.

    • (Mobile Development Kit Client)

      Under Android & iOS Builds, enter the URL Scheme.

      Under Android Builds, enter the Google Services JSON File, or browse to find it.

      Select Show Contents to view the contents of the JSON file. If it is not the right file, click Remove File and try again. Once saved, the JSON file is uploaded.

    • (SAP Asset Manager)

      Under Android & iOS Builds, enter the URL Scheme.

      Under Android Builds, enter the Google Services JSON File, or browse to find it.

      Select Show Contents to view the contents of the JSON file. If it is not the right file, click Remove File and try again. Once saved, the JSON file is uploaded.

  7. On the Multimedia page, identify the launch icon and splash screen icons, depending on the selected app type. You can use the default icon, Upload a new icon following the size guidelines, or click Reset to revert to the default. Click the image title to preview the icon.

  8. Provide the build options:

    • Platforms ‒ the platforms to build, such as Android and iOS.

      Note

      For Mobile Development Kit Client and SAP Asset Manager, both the Android and iOS platforms are supported.

    • Signing Profile ‒ the profiles for the Android and iOS platforms. See Create a Signing Profile

      To build an iOS mobile card kit client containing iMessage and Today Screen extensions, choose individual signing profiles for each extension.

      Note

      If an older signing profile reports a Null Object Exception, you must reload the profile.

    • Minimum Platform Version ‒ the minimum operating system version required for the Android and iOS platforms.

    • Build Options ‒ define the type of binary to build.

      • Create Debug-enabled Binaries

      For information about the different build options, see Supported Client Types, Packaging Details, and Build Options.

  9. Select Finish.

Creating a Build Job for Customized Mobile Development Kit Clients

Create a build job for a customized Mobile Development Kit client from SAP mobile service cockpit. The build includes functionality to run customized extensions, application resources, and onboarding; and to run demo mode in the Cloud Foundry landscape.

The custom Mobile Development Kit project ZIP file must be prepared in a valid format, and must be valid for the current Mobile Development Kit version available in the Cloud Build service, otherwise you may see build failures, or event failure while running the app. Following is an example of the core structure that follows validation rules, but is not an exhaustive representation of the supported content:

    template.mdkproject.zip
      └──xxxxx.mdkproject
         ├──App_Resources/
         │  ├── Android/
         │  │   ├── google-services.json
         │  │   └── src/
         │  │       └── main/
         │  │           └── assets/
         │  └── iOS/
         ├──BrandedSettings.json   (Required)
         ├──MDKProject.json        (Required)
         ├──demo/
         ├──extensions/
         └── metadata/

The Cloud Build service expects the uploaded file to contain one root folder (which includes the .mdkproject suffix). To do this, the developer must compress the local .mdkproject.

When the Mobile Development Kit project ZIP file is uploaded, the following validation is performed on the file:

  • The file must pass a virus scan, and report an error if it fails.

  • The file must be in a ZIP file format, and report an error if not.

  • The ZIP file content is processed iteratively to verify the following:

    • Your xxxxx.mdkproject is at the root of the ZIP file.

    • BrandedSettings.json is directly under the root folder xxxxx.mdkproject, and report an error (bad request) if not.

    • MDKProject.json is directly under the root folder xxxxx.mdkproject, and report an error (bad request) if not.

    • BrandedSettings.json and MDKProject.json can be parsed, and report errors (internal server error) if not well-formatted.

    • The above-parsed values are validated using the following rules:

      • AppName in MDKProject.json (required): only letters and digits are allowed in the name, and the name can be no longer than 80 characters.

      • AppVersion in MDKProject.json (required): must match one of the regular expressions:

        /^[1-9][0-9]{0,3}.([0]|[1-9][0-9]{0,1})$/

        /^[1-9][0-9]{0,3}.([0]|[1-9][0-9]{0,1}).([0]|[1-9][0-9]{0,1}$/

        • Must include either two or three segments, separated by periods (".")

        • Every segment contains only digits.

        • The first segment must start with a digit greater than 0, followed by 0 or 3 digits.

        • The second and third segments must include a number from 0 to 99.

    • UrlScheme in MDKProject.json (optional): must start with a letter, followed by letters, digits, plus sign ("+"), period ("."), or dash ("-"), and cannot be longer than 254 characters.

    • BundleID in MDKProject.json (required): must start with a letter, followed by letters, digits, period ("."), or dash ("-"), and can be no longer than 128 characters.

    • Google-services.json (optional): must be a valid JSON file, and BundleID in MDKProject.json must be one of the packages listed in google-services.json.

    • ApplicationDisplayName in BrandedSettings.json (optional): the length is checked, and can be no longer than 128 characters.

    • DetailLabelViewText in BrandedSettings.json (optional): the length is checked, and can be no longer than 128 characters.

To create the customized Mobile Development Kit client:

  1. Select Create Build Job to create a new build job.

  2. In Create Build Job, for Client Type select Customized Mobile Development Kit Client from the list.

  3. Fill out the basic information for the customized Mobile Development Kit Client.

    • For Build Job Name, enter a name to replace the default name.

    • For Mobile Development Kit Project ZIP File, provide the name of the project file to use, or browse to select it. You can also upload a new version of the project file, for example, after fixing a validation failure during upload.

    If the project file cannot be uploaded, check for error reports, and make changes until all validation checks can be completed successfully.

    If the project file is valid, Device App Name and the fields that follow are updated based on values contained in the ZIP file.

    Select Next to navigate to subsequent pages. For information about entries see Supported Client Types, Packaging Details, and Build Options.

  4. Provide the signing profile and minimum platform version information for the customized Mobile Development Kit Client.

    1. Signing Profile ‒ select signing profiles for the Android and iOS platforms. Note that if an older signing profile reports a Null Object Exception, you must reload the profile.

    2. Minimum Platform Version ‒ select the minimum operating system version required for the Android and iOS platforms.

    3. Create Debug-enabled Binaries ‒ create a binary version with debug tools enabled.

    For information about entries see Supported Client Types, Packaging Details, and Build Options.

  5. Select Finish. If all entries are valid, the new job appears in the build job list.

  6. (Optional) Check the Build Jobs tab to see the status of your build. Status values include:

    • Build Required ‒ the build job has been created. Select Build under Actions to run the build job.

    • Build Completed ‒ the build job ran successfully.

    • Build Failed ‒ the build failed. Investigate the cause, and then run the build job again.

Editing a Build Job

Edit a build job for the selected application.

  1. In SAP mobile service cockpit, select Mobile Applications > Native/Hybrid or SAP Mobile Cards.

  2. Select an application, then select Mobile Cloud Build under Assigned Features (or add it first); or select Features > Cloud Build for mobile card kit.

  3. On the Build Jobs tab, under Actions select edit to edit a build job.

  4. Use the Edit Build Job wizard to make changes to the build job. See Creating a Build Job for field definitions. The fields that appear on each page depend on the client type selected.

  5. Select Finish. The build job Status changes to "Build Required", and the new values are used the next time you run the build.

Enable Detailed Event Logging

Enable or disable detailed event logging for the Cloud Build standalone service on SAP mobile service cockpit.

When disabled, error logging continues but the detailed create, read, update, and delete operations are not included.

  1. In SAP mobile service cockpit, select Settings > Cloud Build.

  2. Select Enable Detailed Event Log in the upper right corner to start logging the initialization of default purge settings for cloud build. To see the detailed event log related to build process for the cloud build, you need to enable the detailed event log for cloud build feature at the application level (see Viewing Event Logs).

  3. At any time, select Disable Detailed Event Log to stop logging these operations. Error logging continues.

Purge Cloud Build Artifacts

Set up a schedule for purging cloud build logs and build output.

Purging is at the tenant level. Cloud build logs are kept for the number of days that you specify, and purged when the scheduler task runs. Output and artifacts are kept for the number of builds that you specify, and purged when the scheduler task runs.

  1. In SAP mobile service cockpit, select Settings > Cloud Build > Purge Settings.

  2. If Enable Purge Settings is disabled, select edit .

  3. Select Enable Purge Settings and edit the purge settings.

    Purge Settings

    Settings Description
    Clear logs of successful builds after Identify when to clear logs for successful builds ‒ Immediately, or after 1, 3, 7, or 30 days. Default is 7 days.
    Clear logs of unsuccessful builds after Identify when to clear logs for unsuccessful builds ‒ Immediately, or after 1, 3, 7, or 30 days. Default is 7 days.
    Keep output of last n successful builds per app Identify how long to keep the artifacts from the last 1-5 successful app builds. Default is 3 successful builds.
    Keep output of last n unsuccessful builds per app Identify how long to keep the artifacts from the last 1-5 unsuccessful app builds. Default is 3 unsuccessful builds.
    Last purge Shows the last successful purge in the YYYY-MM-DD HH:MM:SS format (local or UTC time zone).
  4. Select Save.

The data is kept until the scheduler task runs, typically every 12 hours, unless otherwise configured on the server side. A build with a PENDING status will not be effected by the purge settings.


Last update: August 16, 2021