Kann DOC_INFO_BY_NAME von einem benutzerdefinierten WCC-Java-Dienst nicht aufrufen

Question

Ich erstelle eine benutzerdefinierte Java-Komponente für oracle-ucm, um einige Verarbeitung basierend auf übergebenen Excel-Dateien zu tun. Die Dateien werden von Content ID ausgetippt. Eines der ersten Dinge, die die Anwendung nach dem Lesen der Excel-Datei ausführt, ist der Aufruf DOC_INFO_BY_NAME.

Kurz: Warum kann nicht DOC_INFO_BY_NAME namentlich dProcessingState finden und wie kann ich es beheben?

unten nähere Angaben

---

Allerdings, wenn ich bekomme ich folgende Fehlermeldung:

Fehler DOC_INFO immer für 'LOCALHOST16200000001'. Die Informationen für 'LOCALHOST16200000001' konnten nicht abgerufen werden. Die Informationen zum Dateiformat konnten nicht abgerufen werden. Der Parameter 'dProcessingState' konnte nicht gefunden werden. [Details]

Ein Fehler ist aufgetreten. Die Stapelverfolgung unten zeigt mehr Informationen.

!$Error getting DOC_INFO for 'LOCALHOST16200000001'.!csUnableToGetRevInfo2,LOCALHOST16200000001!csUnableToGetFileFormatInfo!syParameterNotFound,dProcessingState 
intradoc.common.ServiceException: !csUnableToGetRevInfo2,LOCALHOST16200000001!csUnableToGetFileFormatInfo 
     at intradoc.server.ServiceRequestImplementor.buildServiceException(ServiceRequestImplementor.java:2176) 
     at intradoc.server.Service.buildServiceException(Service.java:2404) 
     at intradoc.server.Service.createServiceExceptionEx(Service.java:2398) 
     at intradoc.server.Service.createServiceException(Service.java:2393) 
     at intradoc.server.DocCommonHandler.getDocFormats(DocCommonHandler.java:271) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at intradoc.common.IdcMethodHolder.invokeMethod(IdcMethodHolder.java:86) 
     at intradoc.common.ClassHelperUtils.executeMethodReportStatus(ClassHelperUtils.java:324) 
     at intradoc.server.ServiceHandler.executeAction(ServiceHandler.java:79) 
     at intradoc.server.Service.doCodeEx(Service.java:622) 
     at intradoc.server.Service.doCode(Service.java:594) 
     at intradoc.server.ServiceRequestImplementor.doAction(ServiceRequestImplementor.java:1693) 
     at intradoc.server.Service.doAction(Service.java:566) 
     at intradoc.server.ServiceRequestImplementor.doActions(ServiceRequestImplementor.java:1483) 
     at intradoc.server.Service.doActions(Service.java:561) 
     at intradoc.server.ServiceRequestImplementor.executeActions(ServiceRequestImplementor.java:1415) 
     at intradoc.server.Service.executeActions(Service.java:547) 
     at intradoc.server.ServiceRequestImplementor.doRequestInternalEx(ServiceRequestImplementor.java:958) 
     at intradoc.server.ServiceRequestImplementor.executeServiceTopLevelSimple(ServiceRequestImplementor.java:1070) 
     at com.lowes.content.edam.massMetaDataUpdate.service.types.ServicesWrapper.executeService(ServicesWrapper.java:139) 
     at com.lowes.content.edam.massMetaDataUpdate.service.file.GetFileService.getDocInfo(GetFileService.java:478) 
     at com.lowes.content.edam.massMetaDataUpdate.service.ServiceFieldMapper.getMappings(ServiceFieldMapper.java:76) 
     at com.lowes.content.edam.massMetaDataUpdate.file.mapper.impl.FieldMapWorker.doInBackground(FieldMapWorker.java:107) 
     at com.lowes.content.edam.massMetaDataUpdate.file.mapper.impl.FieldMapWorker.doInBackground(FieldMapWorker.java:37) 
     at javax.swing.SwingWorker$1.call(SwingWorker.java:277) 
     at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) 
     at java.util.concurrent.FutureTask.run(FutureTask.java:138) 
     at javax.swing.SwingWorker.run(SwingWorker.java:316) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) 
     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) 
     at java.lang.Thread.run(Thread.java:662) 
Caused by: intradoc.data.DataException: !syParameterNotFound,dProcessingState 
     at intradoc.data.DataBinder.getEx(DataBinder.java:1258) 
     at intradoc.data.DataBinder.get(DataBinder.java:1057) 
     at intradoc.server.DocCommonHandler.getProcessingState(DocCommonHandler.java:277) 
     at intradoc.server.DocCommonHandler.getDocFormats(DocCommonHandler.java:184) 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
     at java.lang.reflect.Method.invoke(Method.java:597) 
     at intradoc.common.IdcMethodHolder.invokeMethod(IdcMethodHolder.java:87) 
     at intradoc.common.ClassHelperUtils.executeMethodReportStatus(ClassHelperUtils.java:324) 
     at intradoc.server.ServiceHandler.executeAction(ServiceHandler.java:79) 
     at intradoc.server.Service.doCodeEx(Service.java:622) 
     at intradoc.server.Service.doCode(Service.java:595) 
     ... 20 more 

Ich habe mehrere Möglichkeiten des Aufrufs des zusätzlichen Dienstes ausprobiert.
zur Zeit verwende ich:

public DataBinder executeService(DataBinder binder, Workspace workspace) 
     throws DataException, ServiceException 
{ 
    final String serviceName = binder.getLocal(Services.IdcService); 

    //check for REMOTE_USER 
    String username = binder.getEnvironmentValue("REMOTE_USER"); 

    if (null == username || "".equals(username.trim()))   
    { 
    log.warn("username not found, searching the binder."); 
    try { username = binder.get("dUser"); } 
    catch (DataException de) { log.error("Unable to get Username.", de); } 
    if (null != username && !"".equals(username.trim()))    
    { binder.setEnvironmentValue("REMOTE_USER", username); } 
    else { throw new IllegalStateException("Username required!"); } 
    } 

    //clear idcToken 
    binder.getLocalData().remove("idcToken"); 

    log.info("About to run '" + serviceName + "' as '" + username +"'"); 

    try 
    { 
    log.info("Calling service " + serviceName + ": " 
      + binder.getLocalData().toString()); 
    // Execute service 
    service.createRequestImplementor(); 
    service.getRequestImplementor() 
      .executeServiceTopLevelSimple(binder, serviceName, 
              service.getUserData()); 
    log.info("Finished calling service"); 
    return service.getBinder(); 
    } 
    catch (DataException e) 
    { 
    String msg = "Unexpected Failure executing service '"+serviceName+"'"; 
    log.info(msg, e); 
    throw e; //log and duck 
    } 
} 

Warum also nicht dProcessingState finden WCC kann, und wie kann ich es beheben?

Answer 1

Ihre Art, den Service anzurufen ist ziemlich Standard und ich denke nicht, dass das der Grund ist. Meine erste Vermutung ist, dass Ihr anderer Code Ihren Aufruf von DOC_INFO_BY_NAME stört. Wenn Sie alle anderen benutzerdefinierten Code deaktivieren (vielleicht einfacher gesagt als getan) und den Dienst in einer sauberen Komponente aufrufen, dann wird es funktionieren. Der zweite Kandidat ist es zu überdenken, ob Ihr benutzerdefinierter Dienst wirklich ein FileService sein sollte. Nicht sicher, ob das das Ergebnis beeinflusst, aber vielleicht einen Versuch wert.

Answer 2

Es scheint fast wie ein Fehler für mich.

getProcessingState() aus getDocFormats() genannt, die aus dem DOC_INFO * Service aufgerufen wird. Der Code für getProcessingState() ruft zuerst dProcessingState ab.

String curProcState = this.m_binder.get("dProcessingState"); 

Dann überprüft er, ob dies null:

if (curProcState != null) 

es aber nie auf die Null-Kontrolle bekommt. Dies liegt daran, DataBinder.get() einen Wert für jeden Schlüssel übergeben erfordern (in diesem Fall dProcessingState.)

dProcessingState auf einen Wert in dem Databinder Einstellung Versuch, bevor Sie den Kundendienst anrufen.

binder.setLocal("dProcessingState", "ignore"); 

Answer 3

Das Problem war total meine Schuld. Ich hatte versucht, ausgefallen zu sein, und erweitere Databinder, um es einfacher für mich zu machen. Stellt sich heraus, dass meine Erweiterung fehlerhaft war. Rollback auf den Standard und doppelte Überprüfung meiner Daten in der Sammelmappe behoben.