Interested to work in UK


Visit the NYSolutions career page http://www.nysolutionsltd.com/careers/

NYS is hiring !!!

Looking for Motivated Senior Oracle/Java/Salesforce Professionals at all capacities to work across the UK. Individuals applying for this role must have at least 8-10+ years of solid experience in top MNC’s and should have prior consultancy experience.

Candidates must be able to work independently without any guidance and be confident engaging with end customers. Prior UK experience would be preferred.

Interested candidates please send your CV’s to applications@nysolutionsltd.com along with the following details.

Total Years of Experience/Onsite Experience

Current and Expected Salary in GBP

Please specify the UK work eligibility or Visa status

Candidates needing sponsorship welcome but must be willing to fund the sponsorship themselves.

Looking for a Salesforce Lead Developer / Technical Consultant – Permanent – UK


Looking for a Salesforce Lead Developer / Technical Consultant – Permanent – UK

Candidates needing Sponsorship are welcome to apply but must be willing to fund their sponsorship.

NY Solutions Ltd company is a specialized Consultancy based in London providing high end consultancy services to clients in Media, finance sectors based all over UK. The successful Salesforce lead Developer / architect will work on niche Salesforce projects for our high end clients.

Key skills Required

Experience in integrating third party applications
Successfully delivered 2 end to end large scale Salesforce projects
Strong technical leadership experience
Excellent communicator with the ability to liaise with business stakeholders
Experience working in distributed teams Desirable;

Ideally will have Salesforce Developer Certification Dev 401, DEV 501

Interested Candidates should send their CV and cover letter to

applications@nysolutionsltd.com

http://www.nysolutionsltd.com/

OSB FTP Poller continuously throwing exception – while no file pending on FTP Location


We have been recently facing an issue with an OSB Proxy using FTP Protocol, where in we kept getting the errors on the logs even when we were not putting new files in.

Errors lead us to believe there were some permission issues.

Unable to get file NYSolutionsSourcedir/43646343-dfh34d2.232dfg3d__testFile.txt.Stage on attempt number 0: java.io.IOException: Data: OpenSocket, Permission Denied? java.io.IOException: Data: OpenSocket, Permission Denied?

It ultimately lead to stuck threads and other issues on the server.

We even tried to restart the servers but still faced the same issue.

Stack Trace.

Unable to get file NYSolutionsSourcedir/43646343-dfh34d2.232dfg3d__testFile.txt.Stage on attempt number 0: java.io.IOException: Data: OpenSocket, Permission Denied? java.io.IOException: Data: OpenSocket, Permission Denied? at com.bea.wli.sb.transports.ftp.resource.FtpClient.openPassiveDataSocket(FtpClient.java:1349) at com.bea.wli.sb.transports.ftp.resource.FtpClient.executeDataCommand_in_PassiveMode(FtpClient.java:1526) at com.bea.wli.sb.transports.ftp.resource.FTPResource.getDataInputStream_in_PassiveMode(FTPResource.java:1398) at com.bea.wli.sb.transports.ftp.resource.FTPSource.getInputStream(FTPSource.java:52) at com.bea.wli.sb.transports.ftp.resource.FTPSource.writeTo(FTPSource.java:59) at com.bea.wli.sb.sources.StringTransformer.transform(StringTransformer.java:81) at com.bea.wli.sb.sources.MetaTransformer.doTransform(MetaTransformer.java:138) at com.bea.wli.sb.sources.MetaTransformer.transform(MetaTransformer.java:89) at com.bea.wli.sb.pipeline.PipelineContextImpl$LazyInitTransformer.transform(PipelineContextImpl.java:1694) at com.bea.wli.sb.context.SOAPMessageImpl.parseCheckPayload(SOAPMessageImpl.java:1227) at com.bea.wli.sb.context.SOAPMessageImpl.generateBody(SOAPMessageImpl.java:1040) at com.bea.wli.sb.context.SOAPMessageImpl.getBody(SOAPMessageImpl.java:260) at com.bea.wli.sb.context.BodyVariable.getTypedValue(BodyVariable.java:106) at com.bea.wli.sb.context.BodyVariable.getTypedValue(BodyVariable.java:25) at com.bea.wli.sb.context.SystemVariable.getValue(SystemVariable.java:49) at com.bea.wli.sb.context.MessageContextImpl.getVariableValue(MessageContextImpl.java:233) at com.bea.wli.sb.stages.expressions.xquery.XQueryExprExecutor.getVariables(XQueryExprExecutor.java:182) at com.bea.wli.sb.stages.expressions.xquery.XQueryExprExecutor.executeJavaObject(XQueryExprExecutor.java:129) at com.bea.wli.sb.stages.expressions.xquery.XQueryTransformExecutor.getVariables(XQueryTransformExecutor.java:216) at com.bea.wli.sb.stages.expressions.xquery.XQueryTransformExecutor.execute(XQueryTransformExecutor.java:108) at com.bea.wli.sb.stages.expressions.xquery.XQueryTransformExecutor.execute(XQueryTransformExecutor.java:90) at stages.transform.runtime.AssignRuntimeStep.processMessage(AssignRuntimeStep.java:51) at com.bea.wli.sb.stages.StageMetadataImpl$WrapperRuntimeStep.processMessage(StageMetadataImpl.java:346) at com.bea.wli.sb.stages.impl.SequenceRuntimeStep.processMessage(SequenceRuntimeStep.java:33) at com.bea.wli.sb.pipeline.PipelineStage.processMessage(PipelineStage.java:84) at com.bea.wli.sb.pipeline.PipelineContextImpl.execute(PipelineContextImpl.java:1098) at com.bea.wli.sb.pipeline.Pipeline.processMessage(Pipeline.java:141) at com.bea.wli.sb.pipeline.PipelineContextImpl.execute(PipelineContextImpl.java:1098) at com.bea.wli.sb.pipeline.PipelineNode.doRequest(PipelineNode.java:55) at com.bea.wli.sb.pipeline.Node.processMessage(Node.java:67) at com.bea.wli.sb.pipeline.PipelineContextImpl.execute(PipelineContextImpl.java:1098) at com.bea.wli.sb.pipeline.Router.processMessage(Router.java:214) at com.bea.wli.sb.pipeline.MessageProcessor.processRequest(MessageProcessor.java:101) at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:597) at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:595) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:363) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146) at com.bea.wli.sb.security.WLSSecurityContextService.runAs(WLSSecurityContextService.java:55) at com.bea.wli.sb.pipeline.RouterManager.processMessage(RouterManager.java:594) at com.bea.wli.sb.transports.TransportManagerImpl.receiveMessage(TransportManagerImpl.java:398) at com.bea.wli.sb.transports.ftp.connector.FTPPublishedTask.processDirectStreaming(FTPPublishedTask.java:292) at com.bea.wli.sb.transports.ftp.connector.FTPPublishedTask.process(FTPPublishedTask.java:104) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.__onMessage(PolledMessageListenerMDB.java:52) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.access$000(PolledMessageListenerMDB.java:31) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB$1.run(PolledMessageListenerMDB.java:41) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB$1.run(PolledMessageListenerMDB.java:39) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.security.Security.runAs(Security.java:41) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.onMessage(PolledMessageListenerMDB.java:39) at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:583) at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:486) at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388) at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659) at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345) at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3821) at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115) at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170) at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:531) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:252) at weblogic.work.ExecuteThread.run(ExecuteThread.java:221) Caused By: java.lang.Exception: 550 Failed to open file. at com.bea.wli.sb.transports.ftp.resource.FtpClient.openPassiveDataSocket(FtpClient.java:1330) at com.bea.wli.sb.transports.ftp.resource.FtpClient.executeDataCommand_in_PassiveMode(FtpClient.java:1526) at com.bea.wli.sb.transports.ftp.resource.FTPResource.getDataInputStream_in_PassiveMode(FTPResource.java:1398) at com.bea.wli.sb.transports.ftp.resource.FTPSource.getInputStream(FTPSource.java:54) at com.bea.wli.sb.transports.ftp.resource.FTPSource.writeTo(FTPSource.java:60) at com.bea.wli.sb.sources.StringTransformer.transform(StringTransformer.java:81) at com.bea.wli.sb.sources.MetaTransformer.doTransform(MetaTransformer.java:138) at com.bea.wli.sb.pipeline.PipelineContextImpl$LazyInitTransformer.transform(PipelineContextImpl.java:1694) at com.bea.wli.sb.context.SOAPMessageImpl.parseCheckPayload(SOAPMessageImpl.java:1227) at com.bea.wli.sb.context.SOAPMessageImpl.generateBody(SOAPMessageImpl.java:1040) at com.bea.wli.sb.context.SOAPMessageImpl.getBody(SOAPMessageImpl.java:260) at com.bea.wli.sb.context.BodyVariable.getTypedValue(BodyVariable.java:106) at com.bea.wli.sb.context.BodyVariable.getTypedValue(BodyVariable.java:25) at com.bea.wli.sb.context.SystemVariable.getValue(SystemVariable.java:49) at com.bea.wli.sb.context.MessageContextImpl.getVariableValue(MessageContextImpl.java:233) at com.bea.wli.sb.stages.expressions.xquery.XQueryExprExecutor.executeJavaObject(XQueryExprExecutor.java:129) at com.bea.wli.sb.stages.expressions.xquery.XQueryTransformExecutor.execute(XQueryTransformExecutor.java:90) at stages.transform.runtime.AssignRuntimeStep.processMessage(AssignRuntimeStep.java:54) at com.bea.wli.sb.stages.StageMetadataImpl$WrapperRuntimeStep.processMessage(StageMetadataImpl.java:346) at com.bea.wli.sb.stages.impl.SequenceRuntimeStep.processMessage(SequenceRuntimeStep.java:33) at com.bea.wli.sb.pipeline.PipelineStage.processMessage(PipelineStage.java:84) at com.bea.wli.sb.pipeline.PipelineContextImpl.execute(PipelineContextImpl.java:1098) at com.bea.wli.sb.pipeline.Pipeline.processMessage(Pipeline.java:141) at com.bea.wli.sb.pipeline.PipelineContextImpl.execute(PipelineContextImpl.java:1098) at com.bea.wli.sb.pipeline.PipelineNode.doRequest(PipelineNode.java:55) at com.bea.wli.sb.pipeline.Node.processMessage(Node.java:67) at com.bea.wli.sb.pipeline.PipelineContextImpl.execute(PipelineContextImpl.java:1098) at com.bea.wli.sb.pipeline.Router.processMessage(Router.java:214) at com.bea.wli.sb.pipeline.MessageProcessor.processRequest(MessageProcessor.java:101) at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:598) at com.bea.wli.sb.pipeline.RouterManager$1.run(RouterManager.java:595) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:146) at com.bea.wli.sb.security.WLSSecurityContextService.runAs(WLSSecurityContextService.java:55) at com.bea.wli.sb.pipeline.RouterManager.processMessage(RouterManager.java:594) at com.bea.wli.sb.transports.TransportManagerImpl.receiveMessage(TransportManagerImpl.java:398) at com.bea.wli.sb.transports.ftp.connector.FTPPublishedTask.processDirectStreaming(FTPPublishedTask.java:292) at com.bea.wli.sb.transports.ftp.connector.FTPPublishedTask.process(FTPPublishedTask.java:104) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.__onMessage(PolledMessageListenerMDB.java:52) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.access$000(PolledMessageListenerMDB.java:31) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB$1.run(PolledMessageListenerMDB.java:42) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB$1.run(PolledMessageListenerMDB.java:39) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120) at weblogic.security.Security.runAs(Security.java:41) at com.bea.wli.sb.transports.poller.listener.PolledMessageListenerMDB.onMessage(PolledMessageListenerMDB.java:45) at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:388) at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:4659) at weblogic.jms.client.JMSSession.execute(JMSSession.java:4345) at weblogic.jms.client.JMSSession.executeMessage(JMSSession.java:3822) at weblogic.jms.client.JMSSession.access$000(JMSSession.java:115) at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:5170) at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:531) at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

Solution:

After much troubleshooting it felt something is stuck somewhere, the challenge was where…

Checking the error directory we found that file NYSolutionsSourcedir/43646343-dfh34d2.232dfg3d__testFile.txt.Stage was in this directory.

Then we identified that the message is stuck in the internal JMS queue.
In the WLS console, monitoring the JMS queue, there was 1 message in wlsb.internal.transport.task.queue.ftp.

Root Cause:

The file NYSolutionsSourcedir/43646343-dfh34d2.232dfg3d__testFile.txt.Stage in the stage directory cannot be processed correctly, so it was moved to the error directory. But some error occured, so that the message in wlsb.internal.transport.task.queue.ftp (poller-transport-specific JMS queue) was not discarded. This leads to the domain-wide message-driven bean (MDB) receiving the JMS task again and again, which triggers XA transaction to begin and rollback repeatedly.

Resolution Steps:

1. Delete message in wlsb.internal.transport.task.queue.ftp:

a. In the Administration Console, expand Services > Messaging > JMS Modules.
b. In the JMS Modules table, click JMS module: jmsResources.
c. In jmsResources’s Summary of Resources table, click the queue wlsb.internal.transport.task.queue.ftp.
d. Click the Monitoring > show Messages.
e. Choose the message which leads to this issue and delete it.
PS: Since we are using this proxy with a split join it had over 3 dozen messages for us, and hence we had to delete them all. but for others it may just be one message.

2. Reprocess: When you reprocess the file it will process correctly.

References: Oracle Support KB (Doc ID 1636352.1)

Using JMS Transport with OSB


JMS Transport – Advanced settings

  • The option Enable Message Persistence is by default enabled, which guarantees message delivery because the messages persist and will survive server shutdowns and failures.
    • To improve throughput, deselect this option if the occasional loss of a message is tolerable.
  • Set a time interval in milliseconds in the Expiration field to specify the message time-to-live.
    • After the time-to-live is passed, the message will automatically be treated according to the Expiration Policy defined on the JMS destination (that is, the queue) and either discarded, logged, or redirected to another JMS destination.
    • The default value of 0 for Expiration means that a message never expires and therefore waits to be consumed forever or until the server is shutdown, if the message is not persistent.
  • Any JMS destination can override the Expiration set on the business service by setting the Time-to-Live Override setting through the WebLogic console when configuring the JMS destination.

Changing JMS transport Headers

  • When sending a message to JMS queue or topic through a business service, default values for several JMS Transport message headers are used. The message headers as well as the message properties can be overwritten by using a Transport Header action in a proxy service when routing to the business service.

Set the properties and deploy the project. On testing you will see these

Check the messages on the destination queue.

We have successfully overwritten the JMS header values configured in business service using the transport header action.

Note: The Transport Header action can be placed into the Request Action of the Routing action or Publish action in order to override the jms header values.

Consuming from a JMS Queue

Testing the JMS Consumer

Deploy the JMSConsumer proxy and the message is gone.

You can now check the OSB server logs and you should see the logged body element [highlighted].

Key points

  • On a proxy service, the JMS protocol always works inbound, that is, the proxy service is consuming messages from a queue.
  • On a business service in contrast, the JMS protocol always works outbound, that is, the business service is putting the message to a queue.

Configuring Retry handling in JMS

Configure the redelivery limit and expiration policy on a Queue that will take part in a reliable communication. This option prevents an infinite loop: when the redelivery limit is reached, the message will be moved to the error queue. The redelivery limit on the queue will always override the value set on the message itself.

When creating a message from the weblogic console make sure to overwrite the -1 in the Redelivery Limit field to the same value as specified on the queue Otherwise the -1 will overwrite the setting on the queue and it will again retry forever.[Bug in console]

Explanation

When a proxy service reads a message from the NYSSourceQueue and there is an error somewhere in the process, the message will be rolled back and stays on the queue. WebLogic will detect this and wait for 15 seconds before the proxy service can consume it again. If this happens three times then WebLogic will move the message automatically to the error queue. Such an error queue can be monitored for new messages through the WebLogic diagnostic module. An administrator might be able to solve the problem and remove the message or move it back into the original queue.

These settings can also be done from the Advanced Settings section on the JMS Transport tab of the proxy service. In that case, they will overwrite any settings specified directly on the JMS queue:

We can also override the delivery mode in WebLogic, which takes precedence over all the settings that the producer of the message specifies in the delivery mode.

The Enable Message Persistence property on the business service will not override what we have set in a Transport Header action.

Effect of using Non XA Connection Factory

Non XA CF Testing

The message is lost because the processing of the proxy service has been done in a local transaction. Because of the error, the OSB transaction rolls back, but the consumption from the NYSSourceQueue has happened in a different transaction and was already committed, so the message is lost!

Moving messages in JMS Queues – using OSB Console

How to implement transactions and message persistence

QOS – Using Best effort

By setting the QoS setting in the Routing Options to Best Effort, we force the business service not to use the global transaction. This means that the enqueue of the message into the DestinationQueue happens in its own local transaction and is therefore, committed independently of the global transaction. Because the global transaction retries three times, we get four messages in the DestinationQueue, one for the original request and three for the retries. This is probably not the behaviour we want and therefore, we have to be careful when using the Best Effort QoS setting.

When we use XA-enabled resources, enable Same Transaction For Response, and use

Exactly Once QoS on the outbound transport, every resource will be rolled-back in case of an

error in the Request or Response lane. To make this work, we should check if we are using

a XA or non-XA resource and what the value of the QoS is, otherwise the resource won’t take

part in the global transaction.

In this recipe, we don’t need to set QoS to Exactly Once because this is the default value when

we use JMS with a XA Connection Factory as inbound transport.

To know the QoS values of your proxy service, we can read the following transport variables:

f $inbound/ctx:transport/ctx:qualityOfService

f $outbound/ctx:transport/ctx:qualityOfService

The inbound variable value can’t be changed and OSB uses the inbound value as a default

value for the outbound transport. We can change the outbound QoS value with a Routing

Options action.

Only use the Exactly Once of QoS when there is a transaction involved.

In case of a Publish or a Service Callout action, the default value of QoS is always Best

Effort. This means in case of a JCA resource such as a DB or an AQ adapter we need to set

the dataSourceName property of the resource adapter and not using the xADataSourcename

property, otherwise we will get a runtime error. If the Publish or Service Callout action should

be part of the global transaction, then use the Routing Options action and set the QoS to

Exactly Once. In the case of a JCA adapter, we need to use the xADataSourceName property

of the resource adapter.

If our business service Publish action or Service Callout does not support XA, then with

each retry of the proxy service, the service will be invoked. This can lead to many duplicate

messages or invokes.

We can also force this behavior in a XA-enabled business service by adding a Routing Option

in the Request Action of the Route Node. In the Routing Options, you need to enable

QoS and set it to Best Effort. With Best Effort, the resource won’t take part in the global

transaction even when XA is enabled.

Don’t use the OSB console for testing XA. The test of the proxy

or business service in the OSB console is not the same as

when putting a message on a queue. The OSB console can’t

start a transaction.