Prev
Next
Forums Integration / Customization IPA/ProcessFlow

IPA Scheduler Not Working

 8 Replies
 0 Subscribed to this topic
 52 Subscribed to this forum
Sort:
Author
Messages
Roger French
Veteran Member
Posts: 549
Veteran Member
8/10/2017 3:05 PM

    This is a new instance. Win/SQL.

    LSF 10.0.9, Landmark 10.1.1.51.

    LSF and Landmark have been running for a few months. IPA's have been installed, configured and running OK.

    Trying to schedule an existing IPA flow using Rich Client. The IPA runs fine and OK for a manual schedule meaning "Start". It runs fine in IPD too.

    The issue is that if I create a schedule in My Actions, Schedule for any type of periodic schedule for the IPA to run (one a day, once a week, etc.) it fails to launch. I'm logged in as the 'lawson' user to schedule it. Lawson has full rights and permissions. I've checked and rechecked all permissions and credentials.  Inbaskets work fine and OK.

    The status on "Action Instances" says "Terminanted Abnormally".

    And the exception log says below. I've already rebooted full stack all of servers. Tried deleting the schedule, creating new one, etc. Still does not work. Going on two weeks and support still does not have any solution. We're trying not to have to apply a new CU if at all possible. Thanks for your help.

    com.lawson.rdtech.type.ViewException: Error Deserializing parameter view.
    at com.lawson.rdtech.framework.batch.BatchTaskHelper.getViewFromXML(BatchTaskHelper.java:157)
    at com.lawson.async.LandmarkActionExecutor.getRequestedAction(LandmarkActionExecutor.java:133)
    at com.lawson.async.LandmarkActionExecutor.execute(LandmarkActionExecutor.java:54)
    at com.lawson.rdtech.gridadapter.async.AsyncImplContainer.executeAction(AsyncImplContainer.java:380)
    at com.lawson.rdtech.gridadapter.async.AsyncImpl.executeActionLocal(AsyncImpl.java:343)
    at com.lawson.rdtech.gridadapter.async.AsyncImpl.runRemoteAsyncAction(AsyncImpl.java:260)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at com.lawson.grid.proxy.ProxyServerImpl$ProxyRequestThread.invoke(ProxyServerImpl.java:2715)
    at com.lawson.grid.proxy.ProxyServerImpl$ProxyRequestThread.processRequest(ProxyServerImpl.java:2502)
    at com.lawson.grid.proxy.ProxyServerImpl$ProxyRequestThread.runThread(ProxyServerImpl.java:2425)
    at com.lawson.grid.util.thread.PooledThread.run(PooledThread.java:137)
    at java.lang.Thread.run(Thread.java:745)
    Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 212; Error at line 1 char 212: Remote call failed: invalid credentials supplied for session method IServiceProxy.getDataView(ExecutionContainerKey, DataContext, Action, String, int, String)
    at org.apache.commons.digester.Digester.createSAXException(Digester.java:3181)
    at org.apache.commons.digester.Digester.createSAXException(Digester.java:3207)
    at org.apache.commons.digester.Digester.startElement(Digester.java:1456)
    at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
    at org.apache.xerces.impl.dtd.XMLDTDValidator.startElement(Unknown Source)



    The above line ^^^ referencing credentials. Not sure how or why that message would appear. All of the credentials for 'lawson' and the databases are OK. 


     

    Tim Cochrane
    Veteran Member
    Posts: 154
    Veteran Member
    8/29/2017 8:07 PM
      What CU you on...prob doesn't matter...but just wondering.

      I've got items that were scheduled in CU56, we just went to CU63 a few weeks ago...everything is still running fine.
      Did you get an initial run, or did it fail on first run??
      Tim Cochrane - Principal LM/IPA Consultant
      JimY
      Veteran Member
      Posts: 510
      Veteran Member
      8/30/2017 9:38 AM
        Have you checked Grid Management to see if there are any errors? Also is it possible that you are timing out and that is what is causing the error? You might want to check the Default Session Timeout value under the Security Properties section in Grid Properties. Our is undefined, but maybe yours needs to be increased.
        Roger French
        Veteran Member
        Posts: 549
        Veteran Member
        8/30/2017 1:03 PM

          Already increased time out per the other KB article. Rebooted everything. It seemed to work for about 24 hours then it went back to the same errors.

          We're on CU51, and probably in the end, a upgrade to a later CU is what it will take most likely, to get it running again.

           Haven't really received any response from support on a solution.

          JimY
          Veteran Member
          Posts: 510
          Veteran Member
          8/30/2017 1:51 PM
            If you haven't changed the severity to High then I would do that and see if you can get a response. We have had to do that in the past. I would also look at the Net Change report for the CU to see if there is anything in there about scheduling.
            Roger French
            Veteran Member
            Posts: 549
            Veteran Member
            8/30/2017 5:11 PM
              The incident has been at a level 2 already for a few weeks. This environment has only one single data area/productline.

              They have been referring me to a "best practice" KB article (1669230) from 4/2016 for LPA Grid Node. Basically that has been saying to not use the LmkDeferred node which is delivered with the Grid installation, and to instead use the LmkAsync node.

              I guess then the question is, has anyone actually configured their IPA grid node to not use the LmkDeferred node and instead use the LmkAsync? I've never seen or used this "best practice" before. Just trying to cautiously gauge whether this is actually performed by other environments, as opposed to performing this this best practice and breaking something else. If the actual solution to fixing the issue is upgrading to later/latest CU, then so be it.

              Thank you for your input.
              JimY
              Veteran Member
              Posts: 510
              Veteran Member
              8/30/2017 11:48 PM
                Ours was installed by an Infor Consultant and they used Async.
                SWilkins
                Advanced Member
                Posts: 29
                Advanced Member
                8/31/2017 5:42 PM

                  We were having the same result after a certified partner upgraded us.  Flows ran fine manually from Rich Client or from the designer but scheduling failed.  Our fix ended up being reconfiguration in Grid that was needed (see following):

                  We've verified that Async and LPA are in LmrkDeferred node in Grid. As best practice, I suggest splitting the Async and LPA out from the LmrkDeferred node and remove the binding for the LmrkDeferred node.

                  Please see KB 1669230 - IPA Best Practices - LPA Grid Node. Attached to this KB is a video > HOWTO-LmrkDeferredToLPA-Async.arf

                  Also make sure you clear the failed triggers for the scheduled flows because the schedule will not update until they are taken care of.

                  You can clear the failed triggers on the Failed tab of the Async page.

                  In Rich Client: Start > Applications > Async Administrator > Async Overview. Select the Failed tab and delete the failed triggers.

                  Roger French
                  Veteran Member
                  Posts: 549
                  Veteran Member
                  9/11/2017 8:26 PM

                    Yep, I ended up doing what the KB article said to do and removed the LmkDeferred node and putting in the Async and LPA nodes. So far the scheduler is now working after 3 days. It's looking good.