About

This article is about the tia core proxy functionality.

Content

Introduction

tia® Proxy Core acts as a standard content service to tia® Content Server Core by forwarding storage requests to either a content service configured as primary for new documents being archived, or a secondary contant service accessing already existing storage.

By this flexible approach, tia® Proxy Core enables the access to archive storage created by tia® Content Server Classic using content service kgsstore with tia® Content Server Core without migration, while writing new documents into a fresh storage by the content service of choice.

tia® Proxy Core is embeeded in tia® Content Manager.

Architecture

In contrast to the OSGi plugin, tia® Proxy, which is a real archive link proxy, the described functionality just acting like a proxy while it is embedded inside the tia core and configures to content store backendsprotocol proxy.

The proxy plugin is used , when a customer had in a past a kgs classic content server in the past or is using uses a classic content server in parallel.

tia core® Content Server Core is able to interact with storages former formerly configured for kgs classic content servertia® Content Server Classic.

The picture abobe depicts the situation.

Before, the customer had a classic CS 5 with e.g. an FS storage.

Then he could replace the classic CS using tia core with the backend kgsstore and the specific shape SAPHTTP. It act like an archive link CS but using the tia core. (AD)

The config of SAPHttp can be used with the shape CMISApp as well. Then he could access via CMIS the old AL data.

A typical proxy sceenario it depicted in the picture on top. The customer uses CMIS, the proxy configuration and kgsstore as secondary. Now he can archive via CMIS zu a new storage like SFS or Azure (primary) Image Added

Let's outline the following scenario:

Historically, the customer has used a kgs Classic ContentServer in conjunction with a filesystem storage.

By switching to the latest kgs architecture "tia Core - saphttp", the new integrated proxy service has a decisive advantage.
The historical storage configuration of the former “kgsstore” is still used, which means that no data migration has to take place. At the same time, you address your new storage device (S3, Azure etc.) via tia Core.

It is also possible to access historical ArchiveLink documents via the new proxy service using the newly propagated CMIS interface.

A typical proxy scenario is designed in the picture above. The customer uses the tia Core CMIS interface, the proxy configuration uses e.g azure blob storage as primary and kgs store as secondary storage type.

That means you archive your data via the CMIS Interface in your new storage as your primary device and access legacy data (read only) via secondary and kgs store.

Configuration

The configuration has to be made in is done within the repository.cfg file.

The content server type is now proxy, now.

Please respect, that keep in mind that for this configuration you need to setup the meta services are effected, as well.

Pay attention to the secondary meta type!

...

For performance reasons you van try to set usefallback = false, but then it can lead to documents that are no longer found. Examples are documents that are decoded only once (on storage like data%37), documents that contains a plus (a+b.pdf is stored as a b.pdf) or documents with wrong encoding (stored like � � �+�.pdf)

Configuration example

Excerpt of repository.cfg for proxy configuration of example repository T1.

# the repository list for the default repositoryfactory.class
repositoryfactory.repositorylist = T1

#----------------------  T1 sample configuration (proxy) ----------------------------------

#===== T1 repository configuration 
T1.contentservice.type     = proxy
T1.accessmode              = rucd
T1.description             = T1 Proxy-Repository
T1.saphttp.security        = 1
T1.authentication.cmis.type                  = basic
T1.authentication.cmis.idprovider            = config
T1.authentication.cmis.config.login1.user    = admin:admin
T1.authentication.cmis.config.login1.role    = admin
T1.configdata.filesystem.root                = /temp/meta/

#===== T1 content service configuration (filesystem|azureblobstore|s3blobstore|kgsstore)
T1.contentservice.proxy.primary.azureblobstore.connectionstring=...
FIsplitfilesystemv2.root          = /temp/tiacore_data/
T1.contentservice.proxy.primary.splitfilesystemv2.contrepinpath = true
T1.contentservice.proxy.primary.azureblobstore.invalidcharacters=uFFFE\uFFF9\uFFF0\u0081\u008d

FItype                            = splitfilesystemv2

T1.contentservice.proxy.secondary.type                          = kgsstore
FIT1.contentservice.proxy.secondary.kgsstore.configfile=C:/Program Files/Tomcat 9.0/conf/Storage-SRC-CS-conf.txt
FI           = /temp/proxy/legacy-storage.cfg
T1.contentservice.proxy.secondary.kgsstore.context              = default

#===== T1 keystore service 
FI.metaservice.type = proxy

FI.metaservice.proxy.primary.type= database
FI.metaservice.proxy.primary.database.driver = org.h2.Driver
FI.metaservice.proxy.primary.database.url = jdbc:h2:C:/Users/m.wodarz/Documents/AutoDigit/configs/configSFS/h2metadata;FILE_LOCK=FS;TRACE_LEVEL_SYSTEM_OUT=1
FI.metaservice.proxy.primary.database.user = sa
FI.metaservice.proxy.primary.database.password =

FI.metaservice.proxy.secondary.type=kgsstoreconfiguration (none|pkcs12)
T1.keystoreservice.type         = pkcs12
T1.keystoreservice.pkcs12.name  = tiacore
T1.keystoreservice.pkcs12.path  = /temp/

#===== T1 meta service configuration (none|elastic|database|kafka)
T1.metaservice.type                 = elastic
T1.metaservice.elastic.host         = http://elasticsearch:9200
T1.metaservice.elastic.index.write  = tiacore-meta
T1.metaservice.elastic.index.search = tiacore-meta
T1.metaservice.elastic.index.update = tiacore-meta
T1.metaservice.elastic.index.delete = tiacore-meta
T1.metaservice.elastic.authentication.type  = none

#===== T1 meta service configuration (none|elastic|database|kafka)
T1.protocolservice.type = none