Merge pull request #541 from openBackhaul/ap_v2.n.m

AP v2.0.1_spec

.github/CODEOWNERS

@@ -1,3 +1,3 @@
           @openBackhaul
-/server/  @PrathibaJee
+/server/  @PrathibaJee @MartinSunal @DanaSunal @vanithavalluripalli9 @IswaryaaS
 /docs/    @openBackhaul @PrathibaJee @IswaryaaS @Rajithapitta

README.md

@@ -22,6 +22,7 @@ Its implementation is publicly available and can be copied into every individual
 The ApplicationPattern is base of the application layer running in the live network at Telefonica Germany.
 
 ### Resources
+- [Documentation](./doc/Main.md)
 - [Specification](./spec/)
 - [TestSuite](./testing/)
 - [Implementation](./server/)

doc/ElementsApplicationPattern/ElementsApplicationPattern.md

@@ -4,66 +4,74 @@
 ### Concepts
 
 **General Design Principles**
-* [API-First Approach](./Principles/ApiFirst/ApiFirst.md)
-* [RESTful](./Principles/Restful/Restful.md)
-* [Microservice](./Principles/Microservice/Microservice.md)
-* [CONFIGfile](./Principles/ConfigFile/ConfigFile.md)
-* **Idempotence**: In general, executing the same request (applies on Services and OaM) with the same set of attributes again, shall just lead to the same state. There shall be no error messages, which would indicate that no change has been made. This shall apply in general. Few exceptions might occur (hypothetical example: /v1/create-additional-instance), but not contradict the general principle.
+- [API-First Approach](./Principles/ApiFirst/ApiFirst.md)
+- [RESTful](./Principles/Restful/Restful.md)
+- [Microservice](./Principles/Microservice/Microservice.md)
+- [CONFIGfile](./Principles/ConfigFile/ConfigFile.md)
 
 **Functions**
-* [Structure of Services](./Functions/StructureOfServices/StructureOfServices.md)
-* [Concept of Profiles](./Functions/ConceptOfProfiles/ConceptOfProfiles.md)
-* [Concepts of Forwarding](./Functions/ConceptsOfForwarding/ConceptsOfForwarding.md)
+- [Structure of Services](./Functions/StructureOfServices/StructureOfServices.md)
+- [Concept of Profiles](./Functions/ConceptOfProfiles/ConceptOfProfiles.md)
+- [Concepts of Internal Forwarding](./Functions/ConceptsOfInternalForwarding/ConceptsOfInternalForwarding.md)
+- [Structure of Internal Forwarding](./Functions/StructureOfInternalForwarding/StructureOfInternalForwarding.md)
+- [Types of Internal Forwarding](./Functions/TypesOfInternalForwardings/TypesOfInternalForwardings.md)
+- [Substructure of Management of Internal Forwarding](./Functions/SubstructureOfManagementOfInternalForwardings/SubstructureOfManagementOfInternalForwardings.md)
+- [Concept of _CONFIGfile_](./Functions/ConceptOfConfigFile/ConceptOfConfigFile.md)
+- [Structure of _CONFIGfile_](./Functions/StructureOfConfigFile/StructureOfConfigFile.md)
+- [Concept of OpenApiSpecification](./Functions/ConceptOfOas/ConceptOfOas.md)
+- [Structure of OpenApiSpecification](./Functions/StructureOfOas/StructureOfOas.md)
+- [Concept of TestCases](./Functions/ConceptOfTestCases/ConceptOfTestCases.md)
+- [Structure of TestCases](./Functions/StructureOfTestCases/StructureOfTestCases.md)
 
 **Names and IDs**
-* [Structure of ApplicationNames](./Names/StructureOfApplicationNames/StructureOfApplicationNames.md)
-* [Structure of ServiceNames](./Names/StructureOfServiceNames/StructureOfServiceNames.md)
-* [Structure of Release Numbers](./Names/StructureOfReleaseNumbers/StructureOfReleaseNumbers.md)
-* [Structure of UUIDs](./Names/StructureOfUuids/StructureOfUuids.md)
-* [Structure of CallbackNames](./Names/StructureOfCallbackNames/StructureOfCallbackNames.md)
+- [Structure of ApplicationNames](./Names/StructureOfApplicationNames/StructureOfApplicationNames.md)
+- [Structure of ServiceNames](./Names/StructureOfServiceNames/StructureOfServiceNames.md)
+- [Structure of Release Numbers](./Names/StructureOfReleaseNumbers/StructureOfReleaseNumbers.md)
+- [Structure of UUIDs](./Names/StructureOfUuids/StructureOfUuids.md)
+- [Structure of Internal Forwarding Names](./Names/StructureOfInternalForwardingNames/StructureOfInternalForwardingNames.md)
 
 
 ### Underlying Information Model
 
 **Overview Information Model**
 
 **Classes**
-* [ControlConstruct](./InformationModel/ControlConstruct/ControlConstruct.md) 
-* [LogicalTerminationPoint](./InformationModel/LogicalTerminationPoint/LogicalTerminationPoint.md)
-* LayerProtocol
-* Profile
-* **ForwardingDomain**: The ForwardingDomain(FD) aggregates one or more ForrwardingConstruct(FC). Theoretically CC consists of a list of FDs. But practically a Microservice consists of a single FD instance. FDs are identified by a uuid.
-* [ForwardingConstruct](./InformationModel/ForwardingConstruct/ForwardingConstruct.md)
-* ForwardingConstructPort
-* NetworkControlDomain
-* Link
+- [ControlConstruct](./InformationModel/ControlConstruct/ControlConstruct.md) 
+- [LogicalTerminationPoint](./InformationModel/LogicalTerminationPoint/LogicalTerminationPoint.md)
+- LayerProtocol
+- Profile
+- **ForwardingDomain**: The ForwardingDomain(FD) aggregates one or more ForrwardingConstruct(FC). Theoretically CC consists of a list of FDs. But practically a Microservice consists of a single FD instance. FDs are identified by a uuid.
+- [ForwardingConstruct](./InformationModel/ForwardingConstruct/ForwardingConstruct.md)
+- ForwardingConstructPort
+- NetworkControlDomain
+- Link
 
 
 ### Basic Services
 
-* /v1/bequeath-your-data-and-die
-* /v1/start-application-in-generic-representation
-* /v1/register-yourself
-* /v1/embed-yourself
-* /v1/redirect-service-request-information
-* /v1/redirect-oam-request-information
-* /v1/end-subscription
-* /v1/inquire-oam-request-approvals
-* /v1/update-client
-* /v1/list-ltps-and-fcs
-* /v1/redirect-topology-change-information
-* /v1/update-operation-key
-* /v1/update-operation-client
-* /v1/inform-about-application
-* /v1/inform-about-application-in-generic-representation
-* /v1/inform-about-release-history
-* /v1/inform-about-release-history-in-generic-representation
+- /v1/bequeath-your-data-and-die
+- /v1/start-application-in-generic-representation
+- /v1/register-yourself
+- /v1/embed-yourself
+- /v1/redirect-service-request-information
+- /v1/redirect-oam-request-information
+- /v1/end-subscription
+- /v1/inquire-oam-request-approvals
+- /v1/update-client
+- /v1/list-ltps-and-fcs
+- /v1/redirect-topology-change-information
+- /v1/update-operation-key
+- /v1/update-operation-client
+- /v1/inform-about-application
+- /v1/inform-about-application-in-generic-representation
+- /v1/inform-about-release-history
+- /v1/inform-about-release-history-in-generic-representation
 
 
 ### Headers
 
-* user
-* originator
-* x-correlator
-* trace-indicator
-* customer-journey
+- user
+- originator
+- x-correlator
+- trace-indicator
+- customer-journey

doc/ElementsApplicationPattern/Functions/ConceptOfProfiles/ConceptOfProfiles.md

@@ -2,9 +2,10 @@
 
 
 ### Purpose of Profiles  
-Profiles are for holding configuration information.  
-Most the configuration information is for documenting traffic relationships (e.g. HttpServer, OperationClient).  
-Profiles are for configuration information that is not directly related to an individual interface.  
+
+_Profiles_ are for holding configuration information.  
+Most the configuration information is for documenting traffic relationships (e.g. _HttpServer_, _OperationClient_).  
+_Profiles_ are for configuration information that is not directly related to an individual interface.  
 Contained information could relate e.g.  
 * to all or a group of interfaces  
 * or to a process or calculation that is executed inside the application.  
@@ -14,67 +15,67 @@ Examples:
 - If there would be an application for calculating some value from input from the network, there could be one or several static parameters in that formular. Potentially, it would make sense to make these parameters available for configuration during runtime of the application.  
 
 Configuration information is not to be mixed with application data.  
-While data is entering the application through body or response body of services, configuration information is read and set through GET and PUT requests in the OaM section of the REST API.  
-Moreover structuring and storing of application data is implementation specific (could be e.g. a database), while structuring of configuration information is subject to specification and storing is happening in the CONFIGfile.  
+While data is entering the application through _RequestBody_ or _ResponseBody_ of services, configuration information is read and set through GET and PUT requests in the OaM section of the REST API.  
+Moreover structuring and storing of application data is implementation specific (could be e.g. a database), while structuring of configuration information is subject to specification and storing happens in the CONFIGfile.  
 
 
 ### Structure of Profiles  
-Every definition of a Profile has to contain:  
-* ProfileName for identifying the kind of Profile  
-* UUID for identifying the instance of Profile  
-* Set of additional attributes that are specific to the individual kind of Profile  
 
-Its independence from individual interfaces is also obvious from the core information model and the Profile class being separated from the LogicalTerminationPoint, respectively the LayerProtocol.  
+Every definition of a _Profile_ has to contain:  
+* _ProfileName_ for identifying the kind of _Profile_  
+* UUID for identifying the instance of _Profile_  
+* Set of additional attributes that are specific to the individual kind of _Profile_  
+
+Its independence from individual interfaces is also obvious from the core information model and the _Profile_ class being separated from the LogicalTerminationPoint, respectively the LayerProtocol.  
 ![Location of Profiles](./pictures/220628_core_classes_profile_s.png)  
 
 **ProfileName**  
-The name of the Profile must describe the data object in one or two meaningful nouns followed by "Profile".  
+The name of the _Profile_ must describe the data object in one or two meaningful nouns followed by "Profile".  
 The name must be written in UpperCamelCase and it must be unique within the scope of the individual application.  
 
 **UUIDs**  
-UUIDs of Profiles have to comply with the rules defined in [Structure of UUIDs](../StructureOfUuids/StructureOfUuids.md).  
+UUIDs of _Profiles_ have to comply with the rules defined in [Structure of UUIDs](../StructureOfUuids/StructureOfUuids.md).  
 
 **Additional Attributes**  
-The ApplicationOwner is free to define a set of additional attributes in the ProfileList.  
+The _ApplicationOwner_ is free to define a set of additional attributes in the _ProfileList_.  
 Attributes have to be substructured into:  
-  * Invariant attributes that are for identifying the instance of Profile (Capability)  
-  * Attributes that are available for storing values during run-time of the application (Configuration)  
-(Capability attributes will only be represented by GET method in the OaM section of the OAS, while Configuration attributes will have PUT method, too.)
+  * Invariant attributes that are for identifying the instance of _Profile_ (_Capability_)  
+  * Attributes that are available for storing values during run-time of the application (_Configuration_)  
+(_Capability_ attributes will only be represented by GET method in the OaM section of the OAS, while _Configuration_ attributes will have PUT method, too.)
 
 
 ### Re-use of Profiles
 
-Re-using already existing Profile definitions is very much recommended.  
-Re-using is not just easier and faster during elaborating OpenApiSpecification and CONFIGfile, also program code is already available.  
-The templates of the ProfileList and the ProfileInstanceList already contain the following definitions.
+Re-using already existing _Profile_ definitions is very much recommended.  
+Re-using is not just easier and faster during elaborating OpenApiSpecification and _CONFIGfile_, also program code is already available.  
+The templates of the _ProfileList_ and the _ProfileInstanceList_ already contain the following definitions.
 
 **ActionProfile**  
-The ActionProfile is for defining a potential next step in the workflow that shall be represented in the GenericRepresentation.  
-It is describing the label of a button that shall be shown and the request, which is to be sent, in case the button has been pushed.  
+The _ActionProfile_ is for defining a potential next step in the workflow that shall be represented in the _GenericRepresentation_.  
+It is describing the label of a button and a request, which is to be sent, in case the button has been pushed.  
 Even input fields for values, which need to be sent in the body of this request, can be defined.  
-The ActionProfile is the most complex, but also the by far most often used Profile.  
+The _ActionProfile_ is the most complex, but also the by far most often used _Profile_.  
 It occurs several times in all existing applications.  
 
 **FileProfile**  
-The FileProfile contains the information, which is required for connecting with a file that holds application data.  
+The _FileProfile_ contains the information, which is required for connecting with a file that holds application data.  
 Aside identifying and describing the referenced file, it makes file path, access credentials and allowed operations available for configuration.  
-The FileProfile is used whenever the application uses one or several files for storing internal data.  
+The _FileProfile_ is used whenever the application uses one or several files for storing internal data.  
 
 **GenericResponseProfile** 
-The GenericResponseProfile contains one out of potentially several response values of an *-in-generic-representation request.
-The operation-name attribute works like a filter on the responses, which have to be put into an *-in-generic-representation request.
+The _GenericResponseProfile_ contains one out of potentially several response values of an _GenericRepresentation_ request.
+The _OperationName_ attribute works like a filter on the responses, which have to be put into an _GenericRepresentation_ request.
 The name of the field and its datatype a are invariant, but the value is configurable.
-The GenericResponseProfile occurs several times in all existing applications.  
+The _GenericResponseProfile_ occurs several times in all existing applications.  
 
 **IntegerProfile**  
-The IntegerProfile is for storing a single Integer value.  
-In addition to the bare value, the Profile also allows to define unit, minimum and maximum values.  
+The _IntegerProfile_ is for storing a single Integer value.  
+In addition to the bare value, the _Profile_ also allows to define unit, minimum and maximum values.  
 It has been used for several times in multiple applications.  
-E.g. it is holding the configuration of the number of records to be stored in the ExecutionAndTraceLog application.  
+E.g. it is holding the configuration of the number of records to be stored in the _ExecutionAndTraceLog_ application.  
 
 **StringProfile**  
-The StringProfile is for storing a single String value.  
-In addition to the bare string, the Profile also allows to define an array of legal values (enumeration) or a structure of the string (Regex pattern).  
+The _StringProfile_ is for storing a single String value.  
+In addition to the bare string, the _Profile_ also allows to define an array of legal values (enumeration) or a structure of the string (Regex pattern).  
 It has been used in some applications.  
-E.g. it is holding the operational mode of the OperationKeyManagement application.  
-
+E.g. it is holding the operational mode of the _OperationKeyManagement_ application.