A New Web Service for 22.1 - Get SAP Link Information

[Ron_Simko]

The OnBase Connector for use with SAP ArchiveLink has long contained a web service endpoint for getting link information from OnBase.  But starting with version 22.1, there is now an endpoint to get link information from SAP.  This can allow a business process to now include a check to ensure that a link exists on the SAP side of the aisle, or to pull back useful information such as SAP Business Object ID and Business Object Type that can later be used to get back additional metadata.

This new 'GetArchiveLinkConnections' endpoint can be found in the existing GenericLinkingService web service, and like the other endpoints can be called using the OnBase WorkFlow action 'Call Web Service'.  As seen in the below examples, the service takes in the OnBase doc handle as well as the SAP sender ID.  

When a link is found, a structure is returned that contains one or more sets of link information for that document - information typically stored in SAP table: TOA01.  When no link is returned, a value of 'NOTHING_FOUND' returns in the Exceptions Message.

So, how can this be used?  Here are a couple thoughts:

- Let's say an SAP user utilizes the GOS button and performs the Store Business Object operation.  The document goes to OnBase, but isn't indexed.  This document can now go directly into WorkFlow and GetArchiveLinkConnections can be used to get the SAP Object ID (i.e. invoice number, company code, fiscal year) and Business Object Type which can then be used to execute a custom query or an external autofill to fully index the document.

- A business process can be enhanced with a rule to ensure that a link exists in SAP before a document exits a life cycle, or is transitioned to another queue.

What other ideas do you have?

[Brian_Karcher]

Great idea! Another use case would be "check for existing SAP Object ID". This is not related to linking documents but to creating SAP objects using the Archivelink "object generation services" calls.

So instead of using OnBase Doc Handle to get SAP Object ID, I would want to check the other way: Use SAP Object ID to get find out if this Object ID already exists in SAP/S4.   

In other words, if an AP Invoice already exists in SAP, don't call Archivelink to create the Invoice, in order to avoid duplicates.

[Ron_Simko]

I appreciate the suggestion.  In our full blown AP for SAP solution, the posting bapis are enhanced with the standard SAP duplicate check logic to avoid this scenario.  Unfortunately, the standard bapis that are ultimately called by the Create Vendor/Incoming Invoice Web Services don't do this.  

Since the SAP business object ID is only created on successful posting (or parking)... you will only have that value if it does exist.  If your concern is that you might have two of the same documents in OnBase that will post a duplicate invoice then you might consider creating a workflow rule to check that based on specific keywords and divert into a 'potential duplicate' queue.  Something like this:

[Brian_Karcher]

Thanks for the info, Ron. What I'm after is not related to documents at all.  What I'm looking for is possibly outside the scope of ArchiveLink.  I'm looking for either a check or a query to find out if an AP Invoice already exists in SAP based on 3 values:  Vendor number, Invoice Number, and Invoice Date.

So before I call the ArchiveLink service to create an FB60 invoice, I need to know if the FB60 object already exists based on the combination of three parameters: Vendor number, Invoice Number, and Invoice Date. If I got an SAP Object ID back, I know it exists and would not proceed to create it again.  

This may need be an API or query from SAP but since ArchiveLink connector seems to be able to query SAP already, it would be a handy lookup service to have for FB60 invoices, modelled off the GetIncomingInvoiceDetails call that currently exists for MIRO invoices.

[Ron_Simko]

Ah yes.  I see what you're saying now.  That will require some additional research on my end to see if there is an existing BAPI that takes in those 3 fields.  The standard duplicate check function modules are unfortunately not remote enabled and the BAPI that I'm most familiar with that might handle this use case (FI_DOCUMENT_READ) doesn't accept vendor.

While this is fairly easily done with a custom BAPI/query, going that route makes it very unlikely it could be 'productized'  (or as you mention outside the scope of ArchiveLink).