You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Purpose

The guiding principle for programming standards and guidelines at Syensqo is to use what is generally accepted by the industry as “best-practice”, rather than defining a bespoke set of rules. By adopting this approach, it is more likely that developers engaged by Syensqo are already familiar with the “best-practice” approach and can work effectively in the Syensqo environment immediately.

This document’s purpose is to provide developers with the standards and guidance required to develop in Syensqo’s landscape.


Assumptions

All tools required to develop best-practice based are available.

Since SAP development tools and approaches are evolving so does this document.

The SAP Development Approach has been understood.



SAP Cloud Integration/SCPI/HCI

Tools (pending figaf)

automated testing

itelliJ integrated with SCPI/eclipse integration

inline iflow editor


Error handling/Alerting (FEH ? AIF ?)

Pending Business requirements/NFR's, standard alerting should be in place

  • exceptions should be handled in all cases

Async 

Retry based on business requirements and data/message criticality

IDOC post ALEAUDIT with error messages

Catch exceptions for alerting (if not posting  error to another application system).

Sync

All return appropriate errors to calling system - be as informative as possible

Security

Authentication (endpoints)

Certificates > oAuth > Basic

Data at Rest

Integration should NOT maintain data at rest

Credentials Storage

Stored in secure store

Web based tools and LLMS

DO NOT ! including JSON/XML formatter of data, LLM based coding agents (is there a co-pilot sanctioned by Syensqo ?).

AI tools need to be used as per current IT policy - https://thehub.syensqo.com/en/syensqoai/introducing-syensqos-ai-usage-policy-key-milestone-our-ai-journey?check_logged_in=1







Documentation

Inline

ALWAYS document Iflow sender and receivers


ALWAYS Iflow Description


ALWAYS give descriptive name to flow steps, including sender and receiver default system and internal integration processes (do not leave as default)- 

example

should be

Confluence

As build with reference to MAPPING/FUNC SPEC/TECH OBJECT in SCPI


Logging

MUST use logging -     messageLog.addCustomHeaderProperty("LABEL", "INFO like IDOC_NUM/MATNR/KUNNR");


Naming Standards

Iflow

Externalised Variables


General Integration Principles

  • standard > custom
  • simple > complex
  • timers are bad
  • data caches are bad
  • ????




API Management

Policy Design/Minimum security standard

When Authentication is available -

oAuth + api-key


When oAuth or basic auth isnt available -  

ipwhitelist + api-key




  • No labels