Archivelink configuration with an external repository: filenames/types set to file.BIN

[matteo_montalto]

Hi all gurus,

I'm quite a newbie on the argument, maybe someone could help me figure out what's wrong in my configuration.

Shortly; we're connecting several backends to a common external repository which supports Archivelink.

To do so, I created an external repository by means of the OAC0 transaction, ARCHLINK type, using an HTTP registry and pointing to the connector (in this case we're using an ACSAP connector provided by IBM in order to store data on a Filenet IS system).

Everything seems to be fine, certificates have been exchanged, connections are fine.

The scenario is as follows: we want to store attachments to a specific inforecord type in this repository. In order to do so we created a ZXY inforecord type, configuring bindings with a certain busobject, and so on.

Now, we access CV01N to create an inforecord of type ZXY... and we are having the following issue: no matter what the filename is, or which MIMEType the file has: on the external repository, the created file has always name "file.BIN" and MIMEType "application/octet-stream".

As a consequence, entries in TOA01 have always the RESERVE field set to "BIN".

Probably we're missing some options in customizing; could anyone help us out to identify the problem?

Thanks in advance.

[janosdezsi · Accepted solution]

Hi there,

can you please give here the used settings from OAC3, OAC2 and OAD2?

So in the TOA01 entry you'll find a business object type and a document type.

From this you can find the corresponding OAC3 entry. Also you can check in OAC2 the details of the document type and which document class is assigned to it. Then in OAD2 you can see what is the MIME-Type maintained for the document class.

What is the scenario in which you're storing the document? Manually with GOS -> New -> Store business document?

Best regards,

Janos

[janosdezsi · Accepted solution]

Also please check that no BAdIs or user exists (table TOAEX)  effecting the behavior.

If you have the correct config during the manual storing the correct MIME-Type has to be passed. You can check it in the ICM (level 3) trace. If the MIME-Type is passed, but not stored on the content server, then you have to check it further with the vendor of the storage solution.

Also please note that in OAC0 for ArchiveLink the HTTP, R/3 database table and RFC types are allowed. Logical and file repositories are not supported in ArchiveLink.

[matteo_montalto · Accepted solution]

Hey Janos, thanks for your support!

So, in OAC3 we defined an entry as as follows:

obj type: DRAW

doc type: DRW

S: X

ID repository: ZXY (my ext. repository)

Link: TOA01

Retent.period: 0

In OAC2, we find the following setting (we didn't change anything on it):

Document Type: DRW

Description: DMS Objects

Document class: ALF

Status: <blank>

In OAD2, again, we didn't change anything, and the entry corresponding to ALF is as follows:

Doc. class: ALF

Description: Internal Format for Stored Print Lists

MIME: application/x-alf

According to the settings ( I admit, we only managed OAC0/OAC3 and OAA3, plus the customizing settings related to Document Management->Control Data and General Data), I don't understand why anytime a file.BIN, application/octet-stream is created on the ext. repository.

Thank you very much for your help!

M.

[janosdezsi · Accepted solution]

Ok. This is clearly not correct. ALF is for print lists.

How do you exactly create these ArchiveLink documents?

And in ArchiveLink you can only have content repository with name of 2 characters.

[matteo_montalto · Accepted solution]

Yes Janos,

sorry, I used to talk about ZXY but off course, it was just an example. My ext. repo is defined as ZG.

Now; to create these documents I create an inforecord by means of CV01N transaction, specifying that the Document Type should be a specific type, say "Z16".

In the following screen I can open/browse for a file on my local pc and then proceed with the check in, in order to archive the attached file in my ext. repository.

After that, I can see an entry has been created in TOA01:

MANDT         010

SAP OBJECT    DRAW

OBJECT ID     Z16000000000000001000000000800000 DOC1

ARCHIV ID     ZG

ARC DOC ID    5627A870F34B21D0E10080000AA01839

AR OBJECT     DRW

AR DATE       22.10.2015

DEL DATE

RESERVE       BIN

Hope this can clarify the scenario...

Thanks again for your support!

M.

[janosdezsi · Accepted solution]

Ahh okay I see.

I'm not an expert for CV01n, so maybe someone more familiar with it can check if this is correct.

What I can tell, that this is not one of the basic ArchiveLink scenarios, so in this case it just used as a service by the DMS. Maybe you can find some info starting here: SAP Document Management System - Product Lifecycle Management - SCN Wiki