on 02-02-2012 5:58 PM
Hi,
At Velocity event (october) we had a SAP ERP workflow configured for publishing to SharePoint; after triggering workflow instances, an XML payload document was successfully published to SharePoint.
Now, in the same environment; without changes on Duet Enterprise config level, publishing of task changes of that same workflow no longer publishes into SharePoint.
We executed the report jobs OSP_DELTA and OSP_FULL to make sure that the sync from SAP to SharePoint would be done / task changes are notified. The SAP workflows are delivered into the SAP inbox; but not published to SharePoint.
We added a breakpoint (internal + external) in the default outbound handler S_OSP_WF_PAT_DEFAULT_CH_OB; it is not invoked when we reach the workflow decision step that is published.
We inspected the SCL Logs, but didn't find any relevant log entries.
Any clue what can be wrong here; where to start with the problem analysis?
Best regards, William.
Hi William,
maybe this would be too simple, but sometimes you can overlook the easy things: after executing the RSWNSEL did you also execute the S_OSP_WF_ITEM_SELECTION report? This is the one which pushes the workflows to the Gateway system.
(I assume you mean that the workflows are not sent from the backend system to the Gateway system; the S_OSP_WF_PAT_DEFAULT_CH_OB is only used on the backend system to push the workflow items to Gateway -- and from there to SharePoint)
Regards,
Holger.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Holger,
we also executed the report S_OSP_WF_ITEM_SELECTION; actually did it repeatedly and in mixed orders: this report and RSWNSEL.
And you're right: the publication from backend into GW is not performed; and thus as natural consequence the download into SharePoint business data doc library isn't done/possible.
Best regards, William.
Hi William,
just because I was struggeling with a similar issue at another customer:
in the "Workflow Pattern Customization" under Applications -> Workflow you have specified with Counter 1 your customer Handler API and with Counter 2 the default outbound handler, S_OSP_WF_PAT_DEFAULT_CH_OB.
(in the case where my customer was working on the Counter 2 with the S_OSP_WF_PAT_DEFAULT_CH_OB was missed because of which the items were never sent).
Regards,
Holger.
Hi Holger,
Update: part of the problem was that the published SAP task was no longer present in the notification filters OSP_FULL and OSP_DELTA.
Unknown how it disappeared, we are only aware of some infra updates done in this SAP environment; not of explicitly made changes to these filter configurations.
After we re-added the task entry to OSP_DELTA and OSP_FULL; RSWNSEL now finds notifications for the task we configured for Duet Enterprise publication.
Next issue we then run into is that execution of report C_OSP_WF_ITEM_SELECTION faults, at invocation of function 'S_OSP_WF_GET_NOTIFICATIONS'
E899(S_OSP_WF_MSG) SoapFaultCode:5 ExecutionError: details in WS-errorlog (transaction SRT_UTIL)
E140(S_OSP_WF_MSG) User not managed: check Device Manager or User Management Engine
Looks as if more is 'broken' in our infra; e.g. configured logical ports ? Or the authorization of user that is executing the C_OSP_WF_ITEM_SELECTION report?
Regards, William.
Hi William,
I am not execatly sure where this error is coming from, but one step that is performed in this report is the lookup to the Gateway system whether the User for which this workflow is for, is granted permissions to receive it (you might remember that in SharePoint you have to "Grant access to users" for the workflows that you have configured).
So maybe this user is not yet configured (you can check table /IWTNG/D_USR_SUB on the Gateway system) or -- like you already suggested -- the logical ports (/OSP/CO_RMWRAPPER_VI_DOCUMENT and CO_OSPWACTION_ITEM_VI_DOCUMENT) are not working anymore (so that the connection to the Gateway system itself is no longer working). Since the logical ports (or better the services that are called via these logical ports on Gateweay are configured for SAP Assertion Tickets (SSO) you must also make sure that the username that executes the reports is also available on the Gateway system)
Regards,
Holger.
Hi Holger,
The user account is granted access via SharePoint, and present in table /IWTNG/D_USR_SUB.
The SAP user account also has rights on both the SAP system as SCL server; so is known there.
Is it possible to do a simple check to determine whether the logical ports are working [for this user]; e.g. open the url in browser, or in SProxy ?
Regards, William.
Hi William,
testing from a browser might be complicated because no SAP Assertion Ticket is available and SSO will fail. But you can take the Path Suffix from LPCONFIG and open the RFC destination mentioned in the HTTP Destination. Then paste the path to the Path Prefix field in the RFC destination and perform a connection test.
If everything is fine, you should get a
Status HTTP Response 415
Status Text Unsupported Media Type
(which is because the Connection test does not send all the fields required by the receiving web service).
Regards,
Holger.
Hi Holger,
We validated the configuration of the logical ports; they appear correct.
The exact error message when executing report ' C_OSP_WF_ITEM_SELECTION '
Users not maintained: check Device Manager or User Management Engine
SRT_UTIL does not contain log-entries for the SAP user account that is running the report (?)
Best regards, William.
Hi Holger,
The error 'Users not maintained...' appears to be caused due lack of SAP permissions of the SAP account that is executing the report S_OSP_WF_ITEM_SELECTION; with another account we succesfully pass the 'GetNotifications' calls within that report; and actually now do get into the default outbound handler.
But still no task document published into SharePoint; the default outboundhandler faults on Send Action item; error details:
ERROR_CONTEXT>
<ERROR_INFO>ICF Error when sending the request: HTTPIO_ERROR_SEND_STATE-Fehlermeldung beim Senden der Daten.</ERROR_INFO>
- <CONSUMER_INFO>
<CONSUMER_PROXY>CO_OSPWACTION_ITEM_VI_DOCUMENT</CONSUMER_PROXY>
<LOGICAL_PORT>CO_OSPWACTION_ITEM_VI_DOCUMENT</LOGICAL_PORT>
<OPERATION_NAME>maintainActionItem</OPERATION_NAME>
<OPERATION_NAMESPACE>urn:ActionItemWsd/ActionItemVi/document</OPERATION_NAMESPACE>
<PROCESSING_UNIT>Sector 1: WS-Consumer</PROCESSING_UNIT>
<PROCESSING_MODE>Synchronous</PROCESSING_MODE>
<COMMUNICATION_TYPE>Remote</COMMUNICATION_TYPE>
<WORK_PROCESS_NUMBER>1</WORK_PROCESS_NUMBER>
<WORK_PROCESS_PID>25034814</WORK_PROCESS_PID>
<TERMINAL_NAME>C0269450</TERMINAL_NAME>
</CONSUMER_INFO>
- <TRANSPORT_INFO>
<PROTOCOL>HTTP/1.1</PROTOCOL>
<AUTHENTICATION_METHOD>BasicAuth</AUTHENTICATION_METHOD>
</TRANSPORT_INFO>
</ERROR_CONTEXT>
We want to check the settings of Consumer Proxy for Workflow (page 76 in deployment guide); however we don't see 'Connection Settings' entry in the SCL server.
--> 4. Select Connection Settings > SCL to Consumer > Configure Service Endpoint.
Regards, William.
Hi William,
I am not sure if we are already on the SCL (so the SCL -> Consumer might not be relevant).
From my understanding we are still in the step Backend -> SCL. And in this case, the error might be in the way the WebService on the SCL is set up.
It looks like you are trying to connect to this webservice with Basic Authentication (at least that could be the hint from the error message). Usually the web service on the SCL is setup to only allow SSO.
So I would first check the RFC destination that is used by the logical port in LPCONFIG CO_OSPWACTION_ITEM_VI_DOCUMENT. Is this set to SSO or do you have a username / password maintained?
You can also check on the SCL. Just open SOAMANAGER and search for the related webservice "\*actionitem\*". I guess this is only set to SAP Assertion Ticket.
If you adjust any one of those, maybe this helps...
Regards,
Holger.
Hi William,
please take a look at "2.7 Create Type H RFC Destination to SAP NetWeaver Gateway ". Especially the part:
In the Logon & Security tab, select the SAP RFC Logon radio button.
x Select the Current User check box.
x Select the Send Assertion Ticket for Dedicated Target Sys. radio button.
Regards,
Holger.
Hi Holger,
In our environment we don't have an Type H connection, but instead a Type G. This corresponds with the Duet Enterprise 1.0 Deployment Guide, chapter 2.9. That document doesn't describe to setup a Type H; only Type G.
Which is correct: the Duet Enterprise Deployment Guide; or the Duet Enterprise FP1 Configuration Guide ?
Note: we did see it working with workflow publishing, during the Velocity event; in Velocity preparation our BASIS guys did an upgrade from Duet Ent 1.0 --> FP1.
Further: when we checked the Type G connection; we don't see the "Basic Authentication radio button" (?)
Best regards, William.
Hi William,
yes, stick with the Type G ("HTTP Connection to External Serv"). In newer NetWeaver versions that Type H ("HTTP Connections to ABAP System") will also work, but with Type G you can explicitly make sure that a SAP Assertion Ticket is sent.
So just make sure that "Send Assertion Ticket" is checked (it doesn't matter if you select "No Logon" or "Basic Authentication").
Regards,
Holger.
Hi Holger,
both our type G connections on backend had:
Basic Authentication enabled
Send SAP assertion ticked
We changed from Basic Authentication to No Logon.
Error message now is: ICF Error when receiving the response: HTTPIO_PLG_CANCELLED
consumer proxy: CO_OSPWACTION_ITEM_VI_DOCUMENT
operation name: maintainActionItem
Authentication method is still: BasicAuth ?
Best regards, William.
Hi,
through means of OSS Message / SAP Support our Duet Enterprise workflow infra is now solved. Afterwards (...) it appeared to be just a small thing: inconsistency in the setting of the Workflow HTTP Destination to SCL Server.
The service from Gateway system is HTTPS enabled; however SSL was set inactive in the configured RFC-destination on backend to Gateway server
*Duet Enterprise 1.0 Deployment Guide; page 54
😘6. Select the Logon & Security tab.
7. In the Logon Procedure section, select the Basic Authentication radio button.
A dialog box asking if you want to change the HTTP logon procedure is displayed.
8. Click Yes.
9. Select the Send SAP Logon Ticket checkbox.
a. In the Status of Secure Protocol section, select the SSL Active radio button.
After we set SSL Active button on this RFC Connection; SAP ERP workflows are now again succesfull published from SAP backend via Gateway Server into SharePoint workflow subsites.
Regards, William.
Hi Holger,
sorry to hijack this thread, but we have exactly the same error message "Users not maintained..." for report "C_OSP_WF_ITEM_SELECTION", but table /IWTNG/D_USR_SUB is empty. Since the user who executes the report does have sufficient permission, I guess it depends on this table.
How is table /IWTNG/D_USR_SUB being filled up with data? I have not found any editing view for this table?
Thanks a lot for any help and Best Regards
Philipp
Hi Philipp,
Word of advice: instead of hijacking (answered) threads; better to start a fresh one.
It keeps the thread-archive clear; and also your particular question will be better noticed.
Wrt your question: you actually manage table /IWTNG/D_USR_SUB from SharePoint side 🙂
Go to your Duet Enterprise Workflow root site; Site Settings \ SAP Workflow Configuration \ Grant user access to SAP Workflow tasks.
This opens the external list 'UserAccessList' (via Duet Enterprise External Content Type 'WorkflowUserSubscription') to table IWTNG/D_USR_SUB; and you can add entries per user or role you give access on a Duet Enterprise workflow (identified by GPW Bound Item type; that you define in SIMGH).
Best regards, William.
Hi William,
thanks for the quick answer. It helped to get to a different error. For this I have opened up the following thread:
http://scn.sap.com/thread/3196330
Best Regards
Philipp
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.