Working with the API Gateway and SCRUD Test Harness

the docuflow api gateway provides the below functions reporting of all docuflow processing, useful for a wide array of reporting and analysis an entry point to the scrud (and pl) test harness load mdpro (metadata push) from an api gateway results set regardless of the function above, execute the docuflow api gateway via either transaction /dflow/docuflowsys and choose the button api gateway enter the transaction /dflow/docuflowgtw once a results set is displayed, you see all data columns left to right these can be filtered to provide a more focused view depending on what you are looking for/at by choosing the "views" menu path when viewing the report results within the both summary and detail level line, you can drill down on the columns indicated with a green checkbox to view further data, eg viewing metadata, viewing the full return table, etc due to the volume of logging, it is recommended you routinely purge the gateway (primarily at the detail level) to keep table space to a minium refer to the section in this document "utilities archiving gateway data" selection criteria setting description sample value(s) cms profile the cms profile to filter on box 1 cms tag the cms use tag to filter on docuflow document storage cms repository type the cms repository type (filenet p8, documentum, or box) bx rfc destination the rfc destination to filter on zdocuflow cmsapi 01 api source the source of the process to filter on like viewing or choice list processing storenew api type the underlying api call to filter on (search, create, read, update, delete, ping and load) these calls are used together to form various processing so it may be interesting to focus the results on just a port of say the viewing process read sap key the unique sap archivelink key for a particular object to filter on 00000000013000 doctype the archivelink document type to filter on zcontract call date the date when the api call was made to filter on 12/25/2020 call time the time when the api call was made to filter on 00 00 00 call user the originating user that made the api call docuflow call return message type the return that was associated with the api call which can either be an (e)rror, (s)uccess, (w)arning, or (i)nfo e sap user the originating user that made the api call docuflow cms id the content management system document id number to filter on 123456 label migration and mdpro labels docuflow is great hide system ping if selected the ping api messages are not reported hide docviewing if selected, and if docuflow docmanager or the toaex method is used for viewing content, then those entries are not reported hide detail entries if selected the detail api messages are not reported by default, the gateway summarizes api calls into 1 “summary” entry in the gateway for ease of reporting if you wish to see the underlying api calls (for example, the create and update for a docmanager storage request), click this off default layout optionally you can select a previously saved layout for the gateway dashboard before displaying the results default reporting on docuflow processing all docuflow processing is logged at a summary and detail level within the api gateway, and therefore reporting can done so for various reasons such as viewing general activity troubleshooting and unhappy path scenerios exporting results for performance and load analysis etc familiarize yourself with the input selection criteria and drill down information available also note that by default document viewing activity and "detailed entries" are hidden see input criteria above "hide docviewing" and "hide detail entries" for more information and to see what additional data is available scrud "test" harness the scrud "test" harness allows the testing of basic scrud api's with no coding via the docuflow api gateway the (s)earch, (c)reate, (r)ead, (u)pdate, and (d)elete api's that are executed are identical to those called when using the abap scrud api set (refer to the docuflow developers guide) or the docuflow enterprise connector test harness all docuflow processing leverages the same endpoint api calls and resulting calls in the docuflow middleware and therefore the test harness can provide you the ability to simulate all docuflow processing to enter the scrud "test" harness execute the api gateway using input parameters that will return a small dataset or no dataset or a dataset that contains the line(s) that you wish to use to action (or "re process") using scrud functions "re process" in this context means that for read and update, you can choose an existing line in the api gateway report and the test harness will use those values as the input to the test harness (you have the option to change those values of course, but they can be handy to reduce entring all the data) choose the "execute" menu path and choose the applicable scrud function the "new" options bring up a new/empty scrud input screen the "again" options require you to select a reported line (click once anywhere on the desired results screen on the line of choice) and basically pre populates the scrud input screen with already utilized values in the case of (r)ead and (u)pdate not to worry these values can be changed prior to execution note even though this is referred to as "test harness", all actions are processed fully to the cms endpoint so albeit you can use this to test (search/read of course have no lasting effect other than load and performance), in the case of create/update/delete, especially in a production environment, these actions must be approached with caution loading mdpro mdpro allows you to push metadata from sap to your cms endpoint, and can be executed directly or alternatively, you can "load" the input selection criteria from the api gateway if you are reporting on (u)pdate api activity refer to the section "utilities metadata push (mdpro) for more detail on how to run mdpro