Purpose

The purpose of this guide is to outline the custom development process for Release 2 and 4.

Overview

Custom development process will be categorized into 2 phases: Request and Build and Jira will be used to manage the request and build process.

Custom Development Request Process

  1. Raise request using Jira.
    1. See Creating Request for details on how to use Jira.
    2. See Request Instructions  on how to fill up the form. 
  2. Technology team will monitor the request under "Ready for Tech Review" and will initiate the discussion with the consultant. 
  3. Once Tech review is completed, the tech review will move the card to "Ready for DA Review"
  4. On a weekly basis PMO will consolidate the requests and add them to DA's agenda.

Creating Request

  1. Login to Jira. The link should take you to SyWay project. 

  2. From here you can create a request by clicking the "Create" blue button.


  3. This will launch the following form. Please take note of the following:
    1. Under work type select "Request" to raise a request (do not use Epic).
    2. Please remember to choose the release or you will not be able to see your request on the board. 
    3. If you do not see the correct fields as shown below. Click on the 3 dots → "Configure fields" → Choose all fields.
    4. Fill up all the fields under "Overview" and "Supporting Information" tab
    5. If you do not have all the information, you can still click create. The request will be added to the draft column and you can update it later.
  4. After filling up all the details, change the status to "Ready for Tech Review" or move the request to "Ready for Tech Review" column. Please note, as a requestor you only have permission to move the request to "Ready for Tech Review" and "Draft". subsequent status update will be managed by technology team and DA.

Alternatively, you can also click on the "+ create" under the draft column. This will create a card, choose "Request" work type, enter the title and hit enter. This will launch the request.

Request Instructions 

For instructions on how to populate each field, place your cursor over the tooltip.

The table below lists down the different types of development and description.

Type of DevelopmentDescription
Application JobCreating a batch job.

Adobe Form

Interactive Adobe forms are editable PDFs which provide a data capture mechanism for users who may be offline or not have access to an SAP system. Users open the PDF in Adobe Acrobat Reader, enter data, and save the form as a PDF file. Data can be programmatically retrieved from the PDF file later. This development should NOT be used as the technology is outdated and problematic. No developments will be built using interactive Adobe forms. 

Conversion (Load only)

Program or process used to load data into a system, potentially via LTMC, IDocs, or another suitable method. 

Conversion (Transform + Load)

As above, but with added transformation steps

Enhancement

Enhancement of standard SAP functionality using SAP-provided extension mechanisms for ABAP code (e.g. BAdI, User Exit, Enhancement Spot), Fiori apps (In-app extensibility), Integration Flows (Groovy), etc. The code implementing the enhancement is executed in the same environment and context as the standard code; side-by-side extensibility patterns should use a different Type

Form (Output)

Static, non-editable output PDF forms for printing or electronic distribution. 

HANA CDS View

HANA view combining tables or SAP-delivered CDS views, and potentially adding additional logic. Useful for certain reporting applications, or extensions of certain Fiori apps. 

Integration Process (custom)

Integration processes connect the System Interfaces of two or more separate systems. A custom Integration Process requires Syensqo to develop the integration, including adapters and transformations such as mappings, from scratch rather than use vendor-delivered code in the 'standard' type. 

Integration Process (standard)

Integration processes connect the System Interfaces of two or more separate systems. This type uses vendor-provided code such as Integration Flows for BTP Integration Suite to implement the connection. The development effort here will focus on implementation, potential configuration, monitoring, and documentation of vendor-provided code. 

Mobile App

Native (iOS/Android) or hybrid (native 'container' app which loads a web app into a browser container) mobile app. 

Modification

Modification of SAP-provided code without the use of enhancement mechanisms. This typically requires an object repair key to be issued. Not upgrade-safe; modified code will be reset back to standard during an upgrade. Generally not allowed. 

Program

An executable program used for background jobs, system housekeeping tasks, or other non-interactive work. Syensqo will not be developing Dynpro 'report programs' or custom transactions. 

Report/Analytics

Broad category covering BI reports for management or regulatory reporting, operational reporting cockpits, dashboards, fixed-format reports, etc. Generally retrieving data from multiple tables, views, or pre-aggregated data sets. 

System Interface

An API for integration with a system. This could be an OData API, SOAP web service, RESTful HTTP API, IDoc - any interface which allows another system to insert or retrieve data, or trigger processing inside a system, is considered a System Interface. Two applications may directly interact by having their respective System Interfaces talk to each other, or the interaction may be intermediated by an Integration Process to connect them. 

User Interface

Browser-based user interfaces such as Fiori apps in S/4HANA, extension apps in BTP with UI5, etc.

Workflow

Stateful workflows developed either using a system-internal workflow engine (e.g. Business Workflow in ABAP, Employee Central workflows in SuccessFactors, etc.), or an external workflow engine for cross-system orchestration (e.g. SAP Build Process Automation)

System Interface vs. Integration Process

System A provides a System Interface shown in red. System B provides a System Interface shown in blue.
An Integration Process deployed in middleware system M is used to connect to both interfaces and translate between them, thus effecting the integration. This should be the default approach to system-to-system integration. 

System B provides a System Interface shown in blue. System A directly consumes this interface using a System Interface shown in red, without the use of middleware. 
Such point-to-point integration should not be the default approach to system integration but can be appropriate where System B publishes a well-known standard API consumed by many other systems in a landscape, and where the use of middleware would add no value.