...

Characteristics

...

The SAP object types are mapped to yuuvis® Momentum object types that are defined in the repositorymanager app schema. The access to yuuvis® Momentum is managed via a technical user account having full access to objects of types defined in the repositorymanager app schema.

Inserting a Document in yuuvis® Momentum by Barcode Upload

The Document and its Data

If a document is inserted into the yuuvis® Momentum system, the corresponding document will be given a barcode and an ArchiveLink version (AL version) is created. The barcode is specified during the capture process (e.g., a barcode label is applied to a document).

The barcode links the document with a business process until the SAP system has linked an SAP business object to the document ID.

At this point it is not yet allowed to set the 'Barcode sent to R3' document flag. All other index data of the document and components need to be already filled in, in particular the unique DocID.

In regular intervals, yuuvis® Momentum REPOSITORYMANAGER determines all documents that have a barcode and no BarcodesenttoR3 flag. For these documents, an entry will be inserted in the barcode file, which is written in the configured Work/Barcode directory.

Reporting the Document to the SAP System

By calling the function WriteBarcodeFile, the REPOSITORYMANAGER service determines in cyclic intervals all barcodes and document IDs that have not yet been reported to the SAP system. The corresponding values of the documents to be reported are written to a file in the Work\Barcode directory by the REPOSITORYMANAGER service. This file contents may look as follows:

<Barcode1> FI <Document-ID1> 20090623 FAX
<Barcode2> FI <Document-ID2> 20090623 FAX
<Barcode3> FI <Document-ID3> 20090623 FAX

Barcode values cannot contain any spaces because the space is used as a separator here.

The documents concerned by this process can be specified using the BarcodesenttoR3 field as otherwise this field's value is set to true. This field will be created in the REPOSITORYMANAGER service by reporting the barcode to the SAP system.

The barcode file is read again and contained information reported to SAP. For each reported document, the BarcodesenttoR3 document flag will then be set in yuuvis® Momentum. This is a sign that the barcode has been reported successfully. Additionally, all information about the sent barcode will be entered in the current barcode file of the Success subdirectory of the Work/Barcode directory. If errors occur, an entry will be made in the current barcode file in the Error directory parallel to the Success directory. There also exists an RDY file in this context.

Referencing a Document in the SAP System

When the barcode is reported to SAP, the document ID and the barcode will be entered into the SAP table BDS_BAR_EX for open external barcodes. This table includes all externally captured documents that own a barcode and are therefore identified by a document ID but could not have been internally assigned to an SAP object and a business process respectively in the SAP system.

Barcode files are exchanged in the <WorkingDirectory> in the barcode subdirectory. If the exchange file has been processed correctly by the content server, the barcodes will be entered in the <WorkingDirectory>\barcode\successful\yyyymmdd.txt file.

If barcodes have not been processed correctly, they will be entered in the <WorkingDirectory>\barcode\error\yyyymmdd.txt file.

A maximum of 5,000 barcodes can be reported in a reporting interval.

Linking a Document to an SAP Object

In the SAP system, a business process (SAP object) can be assigned to a document. For example, the booking of a payment transaction. During this process, the barcode of a business transaction will be filed together with the SAP object ID in the SAP table BDS_BAR_IN of open internal barcodes.

The document ID is referenced with the barcode in the SAP table for the open external barcodes and the barcode is referenced with an SAP object ID in the table for the open internal barcodes. Thus, the SAP object ID and the document ID can be linked. This is done automatically. Thereby, SAP object ID and document ID will be included in the SAP link table TOAXX taking into account the repository. Linking an yuuvis® Momentum document to an SAP process is thus completed. After linking, the barcode is no longer known to the SAP system and can only be searched in the yuuvis® Momentum system.

Data Flow Diagram

The following diagram depicts the data flow when a document is given to the SAP system.

Image Removed

Archiving of Data from the SAP System

Receipts (documents), print lists, and reorg data (data backups) may be stored. In this case, the document ID is transferred to the yuuvis® Momentum system. Barcodes are not transferred here.

Requirements

The REPOSITORYMANAGER service requires the yuuvis® Momentum core services (version 2021 Autumn or later) and the corresponding infrastructure.
>> yuuvis® Momentum Requirements

Additionally, the service requires:

• ActiveMQ
• Space for PersistentVolumeClaim, 10 GB recommended

Installation

The service is delivered as docker container image. For the deployment to the yuuvis® Momentum cluster, you need a deployment and a service script as shown in the example code blocks below. The parameters have to be adjusted according to your own cluster. However, please use the /working-dir path for the PersistentVolumeClaim.

apiVersion: v1
kind: Service
metadata:
  namespace: $NAMESPACE
  labels:
    app: yuuvis
    name: repositorymanager
    yuuvis: "true"
  name: repositorymanager
spec:
  ports:
    - name: "http"
      port: 80
      targetPort: 8010
      nodePort: 30036
  type: NodePort
  selector:
    name: repositorymanager

...

Each tenant can have a single ILM repository and several ArchiveLink repositories (if needed), since ArchiveLink model includes the ContentRepository field.

ArchiveLink retention propagation

If an ILM-Object contains a link to an ArchiveLink object, the REPOSITORYMANAGER service ensures following rules:

• If a legal hold or an retention date is apecified for the ILM-object, these metadata are propagated to the linked ArchiveLink object itself.
• Same behavior in case of lifting the legal hold.

An ArchiveLink object with an legal hold and/or with an retention date lying in the future are prevented from deletion by ArchiveLink directly.

Inserting a Document in yuuvis® Momentum by Barcode Upload

The Document and its Data

If a document is inserted into the yuuvis® Momentum system, the corresponding document will be given a barcode and an ArchiveLink version (AL version) is created. The barcode is specified during the capture process (e.g., a barcode label is applied to a document).

The barcode links the document with a business process until the SAP system has linked an SAP business object to the document ID.

At this point it is not yet allowed to set the 'Barcode sent to R3' document flag. All other index data of the document and components need to be already filled in, in particular the unique DocID.

In regular intervals, yuuvis® Momentum REPOSITORYMANAGER determines all documents that have a barcode and no BarcodesenttoR3 flag. For these documents, an entry will be inserted in the barcode file, which is written in the configured Work/Barcode directory.

Reporting the Document to the SAP System

By calling the function WriteBarcodeFile, the REPOSITORYMANAGER service determines in cyclic intervals all barcodes and document IDs that have not yet been reported to the SAP system. The corresponding values of the documents to be reported are written to a file in the Work\Barcode directory by the REPOSITORYMANAGER service. This file contents may look as follows:

<Barcode1> FI <Document-ID1> 20090623 FAX
<Barcode2> FI <Document-ID2> 20090623 FAX
<Barcode3> FI <Document-ID3> 20090623 FAX

Barcode values cannot contain any spaces because the space is used as a separator here.

The documents concerned by this process can be specified using the BarcodesenttoR3 field as otherwise this field's value is set to true. This field will be created in the REPOSITORYMANAGER service by reporting the barcode to the SAP system.

The barcode file is read again and contained information reported to SAP. For each reported document, the BarcodesenttoR3 document flag will then be set in yuuvis® Momentum. This is a sign that the barcode has been reported successfully. Additionally, all information about the sent barcode will be entered in the current barcode file of the Success subdirectory of the Work/Barcode directory. If errors occur, an entry will be made in the current barcode file in the Error directory parallel to the Success directory. There also exists an RDY file in this context.

Referencing a Document in the SAP System

When the barcode is reported to SAP, the document ID and the barcode will be entered into the SAP table BDS_BAR_EX for open external barcodes. This table includes all externally captured documents that own a barcode and are therefore identified by a document ID but could not have been internally assigned to an SAP object and a business process respectively in the SAP system.

Barcode files are exchanged in the <WorkingDirectory> in the barcode subdirectory. If the exchange file has been processed correctly by the content server, the barcodes will be entered in the <WorkingDirectory>\barcode\successful\yyyymmdd.txt file.

If barcodes have not been processed correctly, they will be entered in the <WorkingDirectory>\barcode\error\yyyymmdd.txt file.

A maximum of 5,000 barcodes can be reported in a reporting interval.

Linking a Document to an SAP Object

In the SAP system, a business process (SAP object) can be assigned to a document. For example, the booking of a payment transaction. During this process, the barcode of a business transaction will be filed together with the SAP object ID in the SAP table BDS_BAR_IN of open internal barcodes.

The document ID is referenced with the barcode in the SAP table for the open external barcodes and the barcode is referenced with an SAP object ID in the table for the open internal barcodes. Thus, the SAP object ID and the document ID can be linked. This is done automatically. Thereby, SAP object ID and document ID will be included in the SAP link table TOAXX taking into account the repository. Linking an yuuvis® Momentum document to an SAP process is thus completed. After linking, the barcode is no longer known to the SAP system and can only be searched in the yuuvis® Momentum system.

Data Flow Diagram

The following diagram depicts the data flow when a document is given to the SAP system.

Image Added

Archiving of Data from the SAP System

Receipts (documents), print lists, and reorg data (data backups) may be stored. In this case, the document ID is transferred to the yuuvis® Momentum system. Barcodes are not transferred here.

Requirements

The REPOSITORYMANAGER service requires the yuuvis® Momentum core services (version 2021 Autumn or later) and the corresponding infrastructure.
>> yuuvis® Momentum Requirements

Additionally, the service requires:

• ActiveMQ
• Space for PersistentVolumeClaim, 10 GB recommended

Installation

The service is delivered as docker container image. For the deployment to the yuuvis® Momentum cluster, you need a deployment and a service script as shown in the example code blocks below. The parameters have to be adjusted according to your own cluster. However, please use the /working-dir path for the PersistentVolumeClaim.

apiVersion: v1
kind: PersistentVolumeClaimService
metadata:
  namenamespace: data-repositorymanager$NAMESPACE
  namespacelabels:
$NAMESPACE spec:   storageClassNameapp: local-pathyuuvis
  volumeMode: Filesystem   accessModesname: repositorymanager
   - ReadWriteOnce yuuvis: "true"
  resourcesname: repositorymanager
spec:
  requestsports:
    -  storagename: 2Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: $NAMESPACE
  labels:"http"
      port: 80
       apptargetPort: yuuvis8010
    name: repositorymanager   namenodePort: repositorymanager
spec:30036
  replicastype: 1NodePort
  selector:
  
 matchLabels:       name: repositorymanager
  template:
   

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-repositorymanager
  labelsnamespace: $NAMESPACE
spec:
  storageClassName: local-path
  namevolumeMode: Filesystem
  accessModes:
repositorymanager    - spec:ReadWriteOnce
  resources:
    containersrequests:
      storage: 2Gi
---
nameapiVersion: repositorymanagerapps/v1
kind: Deployment
metadata:
  namespace: $NAMESPACE
  labels:
 image: docker.optimal-systems.org/team-kookaburra/$CI_PROJECT_NAME:commit-$CI_COMMIT_SHORT_SHA   app: yuuvis
    name: repositorymanager
  name: repositorymanager
imagePullPolicyspec:
Always  replicas: 1
  selector:
    envmatchLabels:
      name: repositorymanager
  template:
 -   namemetadata:
JAVA_OPTS      labels:
        valuename: repositorymanager
-Xmx128m    spec:
      containers:
 - name: SPRING_CLOUD_CONFIG_URI     - name: repositorymanager
       value: "http://configservice/config"   image: docker.optimal-systems.org/team-kookaburra/$CI_PROJECT_NAME:commit-$CI_COMMIT_SHORT_SHA
          imagePullPolicy: Always
- name: SPRING_PROFILES_ACTIVE        env:
      value: prod,docker,kubernetes     - name:  JAVA_OPTS
  ports:            value: -Xmx128m
containerPort:  8010          - volumeMounts:name: SPRING_CLOUD_CONFIG_URI
            -   value: "http://configservice/config"
            - name: storageSPRING_PROFILES_ACTIVE
              mountPath: /working-dirvalue: prod,docker,kubernetes
          volumesports:
            - namecontainerPort: storage8010
          persistentVolumeClaimvolumeMounts:
            claimName- name: data-repositorymanagerstorage
      restartPolicy: Always       imagePullSecretsmountPath: /working-dir
      volumes:
 - name: osgitlab      - name: storage
          persistentVolumeClaim:
            claimName: data-repositorymanager
      restartPolicy: Always
      imagePullSecrets:
        - name: osgitlab

Configuration

Configure Kubernetes Cluster

...

...

SSL Configuration

...

As a general rule, a certificate for data consistency and security must be imported and the repositorymanager-prod.yml configuration file must be modified accordingly, the certificate needs to be integrated in yuuvis® Momentum service-manager, and corresponding adaptations must be made to the SAP SSL configuration to communicate with SAP.

Certificate

The free software OpenSSL can be used to generate a certificate for development and test systems. For example, once OpenSSL has been installed, the following commands can be executed to generate a certificate. The first commands define an individual password for the certificate and its parameters.

...

Executing them will create the ca.crt, ca.key, and ca.p12 files.

Copy the ca.p12 file to the directory specified in the repositorymanager-prod.yml configuration file. Example:

\service-manager\apps\repositorymanager

The repositorymanager-prod.yml Configuration File

The repositorymanager-prod.yml configuration file in the \services\service-manager\config\ directory must have the following entries added to it:

...

Following this, the 'REPOSITORYMANAGER' microservice must be restarted.

Integration in yuuvis® Momentum service-manager

A certificate can be integrated using the command prompt or using tools such as KeyStore Explorer.

Command prompt:

Execute the following commands in the command prompt:

<Path_service-manager>\jdk\bin\keytool ^
    -importkeystore -srckeystore <Path_service-manager>\apps\archiveservice\ca.p12 ^
    -srcstorepass optimal -destkeystore <Path_service-manager>\jdk\jre\lib\security\cacerts ^
    -srcstoretype PKCS12 -deststoretype JKS ^
    -deststorepass changeit

...

Password for certificate administration

Default: changeit

SAP Configuration

• Call the 'STRUST' transaction.

• Go to 'SSL Client Standard'.

• Switch to the Edit mode.

• Click the Import button.

• Specify the certificate.

• Select 'Add to Certificate List'.

• Save the configuration.

In addition, the host name of the respective SAP system must be edited such that the host name of the imported certificate is mapped to the IP address of the server for which the certificate was issued.

AL and ILM Connections

For AL and ILM connections, the HTTP server inputs must correspond to the hostname of the certificate, not the IP address.

In the 'Logon&Security' section, enable the 'SSL active' option and select the appropriate certificate list into which you have previously imported the certificate.

For configuration details, refer to the SAP documentation.

Configuration of the SAP System

...

To connect the SAP system with the HTTP content server and make all necessary settings, we recommend following the SAP guidelines using the SPRO transaction under Netware > Application Server > Basis Services > ArchiveLink.

For customizing the interface for print lists and outbound documents, we recommend attending the SAP course BIT615.

For filing reorg data, we recommend attending the SAP course BIT660.

The main transactions required to establish a connection are listed below:

Transaction OAC0 defines one or several repositories.

This and all further activities within the SAP system have to be undertaken by the SAP system administrator or another authorized user of the customer.

These activities include:

• For the first time:

  • Creation of a communication user (SU01) with the corresponding authorizations (SAP_BC_ENDUSER, SAP_BC_SRV_ARL_ADMIN, SAP_BC_SRV_ARL_USER, SAP_BC_SRV_COM_ADMIN)

  • ArchiveLink: maintenance of basic settings (OAG1)

  • Creation of number range intervals (OANR) for print lists

  • Create log (OAA3) or import prepared transports from OPTIMAL SYSTEMS with the log.

  • Creation of an archive device (name ARCH) as output device (SPAD), assignment of the SAP ArchiveLink archiver, hostspool access method (I: archiver)

• One or several times; depending on how many content repositories have to be defined:

  • Creation of a content repository (OAC0)
    DocArea – ArchiveLink
    Filing method – HTTP content server
    Log – OPTIMALA
    Version no. – 0046 or 0047
    http script – cs/contentserver
    Output device – ARCH
    HTTP server – name or IP address of the server on which yuuvis® Momentum REPOSITORYMANAGER is running
    Port number – The port used to access yuuvis® Momentum REPOSITORYMANAGER (default: 8010).

  • After successful configuration of yuuvis® Momentum REPOSITORYMANAGER, the certificate (OAC0/CSADMIN) has to be sent and activated for each repository.

Image Removed

Organizational Notes

...

The environment will need to be configured specifically in order to run yuuvis® Momentum REPOSITORYMANAGER properly in a compliant and high-performance manner.

...

The objects/resources should be archived using the yuuvis® Momentumarchiving actions to ensure that they cannot be changed or deleted. This action should be run at least once a day to ensure that the documents can be deleted on the exact day they should be deleted.

...

Retention periods are propagated to supported storage systems such as NetAPP vis the yuuvis® Momentum standard mechanism. If, on the SAP side, the retention time is still unknown, nothing is propagated and the media configuration defines the retention time for an object.

...

To ensure that the retention time is specific to the object, the retention time for the media should be set to the minimum, which is usually 1 day.

...

ILM documents should only be deleted using the ILM interface, which is why only the technical user should have this right.

...

AL documents should only be deleted using the AL or ILM interface, which is why only the technical user should have this right. Even if the expiration date is in the past, data needs to be retained until the deletion command is issued by SAP.

...

Combination with Library-based Client

If a client application for yuuvis® Momentum is used that is based on our developer libraries, the IDs of properties and object types should be localized.
>> Localization for Clients

An example key-value mapping is shown in the following code block.

{
	"appRepositorymanager:Contentrepository_label": "Content Repository",
	"appRepositorymanager:ArchiveLinkversion_label": "Archive Link Version",
	"appRepositorymanager:Documentprotection_label": "Document Protection",
	"appRepositorymanager:DocID_label": "Document ID",
	"appRepositorymanager:Creationdate_label": "Creation Date",
	"appRepositorymanager:Creationtime_label": "Creation Time",
	"appRepositorymanager:Datelastmodification_label": "Last Modified Date",
	"appRepositorymanager:Timelastmodification_label": "Last Modified Time",
	"appRepositorymanager:Legalholdlock_label": "Legal Hold Lock",
	"appRepositorymanager:Expirationdate_label": "Expiration Date",
	"appRepositorymanager:Barcode_label": "Barcode",
	"appRepositorymanager:BarcodesenttoR3_label": "Barcode Sent to R3",
	"appRepositorymanager:CompID_label": "Component ID",
	"appRepositorymanager:Contenttype_label": "Content Type",
	"appRepositorymanager:Filename_label": "File Name",
	"appRepositorymanager:Applicationversion_label": "Application Version",
	"appRepositorymanager:Charset_label": "Chartset",
	"appRepositorymanager:Compressionstring_label": "Compression String",
	"appRepositorymanager:archiveLinkComponent_label": "ArchiveLink object type",
	"appRepositorymanager:archiveLinkComponent_description": "Type used for ArchiveLink documents and components",
	"appRepositorymanager:timestampProperties_label": "Timestamp properties",
	"appRepositorymanager:componentProperties_label": "Component properties",
	"appRepositorymanager:documentProperties_label": "Document properties",
	"appRepositorymanager:type_label": "Type",
	"appRepositorymanager:url_label": "URL",
	"appRepositorymanager:properties_label": "Properties",
	"appRepositorymanager:contentlength_label": "Content Length",
	"appRepositorymanager:ilmObject_label": "ILM object type",
	"appRepositorymanager:ilmObject_description": "Type used for ILM collections and resources"
}

Configuration of the SAP System

To connect the SAP system with the HTTP content server and make all necessary settings, we recommend following the SAP guidelines using the SPRO transaction under Netware > Application Server > Basis Services > ArchiveLink.

For customizing the interface for print lists and outbound documents, we recommend attending the SAP course BIT615.

For filing reorg data, we recommend attending the SAP course BIT660.

The main transactions required to establish a connection are listed below:

Transaction OAC0 defines one or several repositories.

This and all further activities within the SAP system have to be undertaken by the SAP system administrator or another authorized user of the customer.

These activities include:

• For the first time:

  • Creation of a communication user (SU01) with the corresponding authorizations (SAP_BC_ENDUSER, SAP_BC_SRV_ARL_ADMIN, SAP_BC_SRV_ARL_USER, SAP_BC_SRV_COM_ADMIN)

  • ArchiveLink: maintenance of basic settings (OAG1)

  • Creation of number range intervals (OANR) for print lists

  • Create log (OAA3) or import prepared transports from OPTIMAL SYSTEMS with the log.

  • Creation of an archive device (name ARCH) as output device (SPAD), assignment of the SAP ArchiveLink archiver, hostspool access method (I: archiver)

• One or several times; depending on how many content repositories have to be defined:

  • Creation of a content repository (OAC0)
    DocArea – ArchiveLink
    Filing method – HTTP content server
    Log – OPTIMALA
    Version no. – 0046 or 0047
    http script – cs/contentserver
    Output device – ARCH
    HTTP server – name or IP address of the server on which yuuvis® Momentum REPOSITORYMANAGER is running
    Port number – The port used to access yuuvis® Momentum REPOSITORYMANAGER (default: 8010).

  • After successful configuration of yuuvis® Momentum REPOSITORYMANAGER, the certificate (OAC0/CSADMIN) has to be sent and activated for each repository.

Image Added

Multiple Instances of REPOSITORYMANAGER service

To achieve multi-tenancy, an independent instance of the REPOSITORYMANAGER service needs to be deployed for each individual tenant. The same service artifact can be used. In general, the following principles apply:

• Each instance should have its own ActiveMQ pod, distributed as separate image.
• Each pair of REPOSITORYMANAGER service and ActiveMQ instances should be deployed into its own namespace, have own ports and profile configuration (default is prod).
• Each pair of REPOSITORYMANAGER service and ActiveMQ must have its own tenant.

Namespaces, services ports and profiles should be specified in the deployment script. The following sections describe the required configuration steps. All scripts are applied via the command:

kubectl apply - f <filename>

Preparation

Decide on the namespace to be used, ports to be used (one port by the REPOSITORYMANAGER service and two ports by the repositorymanager-mq service) as well as the profile in which the application will be run (this determines the naming of the configuration file). For this example, the namespace will be repositorymanager-1, the ports are 10000 for the REPOSITORYMANAGER service, 10001 and 10002 for the ActiveMQ and the profile will be instance1. The cluster should have the repositorymanager app schema and the tenant that is going to be used by the REPOSITORYMANAGER service should be created and configured to use it as described above for the configuration of a single instance.

Namespace

Create the namespace using the following YML script:

apiVersion: v1
kind: Namespace
metadata:
  name: repositorymanager-1

ActiveMQ service

Deploy the repositorymanager-mq pod for ActiveMQ using the following two YML scripts:

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: repositorymanager-1
  name: repositorymanager-mq
  labels:
    app: yuuvis
    name: repositorymanager-mq
spec:
  replicas: 1
  selector:
    matchLabels:
      name: repositorymanager-mq
  template:
    metadata:
      labels:
        name: repositorymanager-mq
    spec:
      containers:
        - image: docker.optimal-systems.org/team-kookaburra/repositorymanager-momentum-mq:commit-b63206e4
          name: repositorymanager-mq
          imagePullPolicy: Always
      restartPolicy: Always
      imagePullSecrets:
        - name: osgitlab

Note: This script uses the image from OS GitLab which requires the osgitlab secret to be present in the same namespace. Different clusters might require some changes

apiVersion: v1
kind: Service
metadata:
  namespace: repositorymanager-1
  name: repositorymanager-mq
  labels:
    app: yuuvis
    name: repositorymanager-mq
spec:
  selector:
    name: repositorymanager-mq
  ports:
    - name: dashboard
      port: 8161
      nodePort: 10001
    - name: openwire
      port: 61616
      nodePort: 10002
  type: NodePort

Note: The ActiveMQ service exposes two ports, one to access the web admin page, internally on port 8161 and externally on 10001, the other to access the ActiveMQ itself, internally on port 61616 and externally on 10002

Repositorymanager service

Deploy the repositorymanager service using the following two YML scripts

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-repositorymanager
  namespace: repositorymanager-1
spec:
  storageClassName: local-path
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: repositorymanager-1
  labels:
    app: yuuvis
    name: repositorymanager
  name: repositorymanager
spec:
  replicas: 1
  selector:
    matchLabels:
      name: repositorymanager
  template:
    metadata:
      labels:
        name: repositorymanager
    spec:
      containers:
        - name: repositorymanager
          image: docker.optimal-systems.org/team-kookaburra/repositorymanager-momentum:commit-2d346b0e
          imagePullPolicy: Always
          env:
            - name: JAVA_OPTS
              value: -Xmx128m
            - name: SPRING_CLOUD_CONFIG_URI
              value: "http://configservice.yuuvis/config"
            - name: SPRING_PROFILES_ACTIVE
              value: instance1,docker,kubernetes
          ports:
            - containerPort: 8010
          volumeMounts:
            - name: storage
              mountPath: /working-dir
      volumes:
        - name: storage
          persistentVolumeClaim:
            claimName: data-repositorymanager
      restartPolicy: Always
      imagePullSecrets:
        - name: osgitlab

Note: This script uses the image from OS GitLab which requires the osgitlab secret to be present in the same namespace. Different clusters might require some changes. Additionally, the environment parameter SPRING_CLOUD_CONFIG_URI should point to the CONFIGSERVICE of the specific cluster. The SPRING_PROFILES_ACTIVE should contain the docker and kubernetes profiles as well as the service profile dedicated to that instance, in this case instance1.

apiVersion: v1
kind: Service
metadata:
  namespace: repositorymanager-1
  labels:
    app: yuuvis
    name: repositorymanager
    yuuvis: "true"
  name: repositorymanager
spec:
  ports:
    - name: "http"
      port: 80
      targetPort: 8010
      nodePort: 10000
  type: NodePort
  selector:
    name: repositorymanager

Note: the REPOSITORYMANAGER service exposes one port to allow internal access via port 8010 and external access via port 10000.

Configuration

Using the CONFIGSERVICE of the cluster to create the repositorymanager-instance1.yml file. This file will contain the configuration for the service instance running with the profile instance1.

The configuration be similar to the following code block:

core:
  api:
    url: http://client.yuuvis
    username: root
    password: optimal
    tenant: instance1tenant

spring:
  activemq:
    broker-url: tcp://repositorymanager-mq:61616

The tenant name as well as credentials to access the yuuvis® Momentum system are provided as well as the URLs to access the system and ActiveMQ.

Once the configuration is created, the REPOSITORYMANAGER service should be restarted to apply the changes.

Access

Once the service is deployed and configured, a reverse proxy should be created to allow two-way communication between the RM4yM service and SAP. This will also allow access to the KGS admin panel for service configuration.