I'm trying to use Talend Open Studio to sync contacts from a variety of input sources into an Exchange 2007 server.
I know Talend can talk SOAP, and EWS has a WSDL, but having bumped into all
sorts of problems trying to marry the two together (since Exchange's WSDL is lacking elements which Talend needs) I don't know if that's the best plan of attack, or if I should be looking at building a more Exchange-specific plugin for Talend using the EWS Java API from MS.
Alternatively, if these are both known to not be possible, I'd appreciate a pointer to an explanation as to why - all the buzzwords seem to line up on each side, after all.
I work at Talend and would be happy to try and help you out a bit, but I myself am not familiar with the Exchange WSDL. I would assume that a SOAP interface from an established vendor like Microsoft is going to be WS-I Basic Profile compatible and should be easily invoked directly just like any regular WS. Would you mind trying the following:
What particular elements are missing from the MS WSDL, or is it trying to use some non-standard feature? CXF is fully JAX-WS compliant, and it is certified WS-I BP compliant, so I have to assume something odd is going on.
post the WSDL from exchange that you are trying to invoke from Talend.
create a proxy client for that WSDL using CXF.
Give it a try and send the error message.
Generate a mock service provider based on that wsdl using CXF and run the CXF mock and try against that with the CXF wsdl client. This will give you added confidence that the client and wsdl have no problems.
you can also try generating a simple test case with just SOAP UI or similar tooling against the Exchange WS.
ps: CXF is apache based open source. It is easy to use and has tight integration with Talend via the ASF suite. But you can also just use it by itself for diagnostic purposes.
Ed
I have been struggling with that too...
You can use tSoap for that purpose.
tWebServiceInput does not work for me with EWS.
tSoap->tLogRow
eg:
tSoap component that resolves a given name is the method ResolveNames()
Value to resolve = Thierry
Set "Need Authentication" with username and password
Set End Point, eg "https://yourserver/EWS/Exchange.asmx"
Set SOAP Action,
"http://schemas.microsoft.com/exchange/services/2006/messages/ResolveNames"
SOAP Version 1.1
Set SOAP Message:
... Enter Soap Method enclosed with ".
Joins tSoap to tLogRow
Run the Job. Voila the result...
Starting job xSoap_ResolveNames_LogRow at 13:43 30/05/2012.
[statistics] connecting to socket on port 3682
[statistics] connected
<Header><t:ServerVersionInfo xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" MajorBuildNumber="685" MajorVersion="8" MinorBuildNumber="24" MinorVersion="0" /></Header>|<m:ResolveNamesResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"><m:ResponseMessages><m:ResolveNamesResponseMessage ResponseClass="Success"><m:ResponseCode>NoError</m:ResponseCode><m:ResolutionSet IncludesLastItemInRange="true" TotalItemsInView="1"><t:Resolution><t:Mailbox><t:Name>Thierry TYS. Yen Suin</t:Name><t:EmailAddress>thierry.suin#sc-mauritius.com</t:EmailAddress><t:RoutingType>SMTP</t:RoutingType><t:MailboxType>Mailbox</t:MailboxType></t:Mailbox><t:Contact><t:DisplayName>Thierry Yen Suin</t:DisplayName><t:GivenName>Thierry</t:GivenName><t:EmailAddresses><t:Entry Key="EmailAddress1">SMTP:thierry.suin#sc-mauritius.com</t:Entry></t:EmailAddresses><t:ContactSource>ActiveDirectory</t:ContactSource><t:Surname>Yen Suin</t:Surname></t:Contact></t:Resolution></m:ResolutionSet></m:ResolveNamesResponseMessage></m:ResponseMessages></m:ResolveNamesResponse>|
[statistics] disconnected
Job xSoap_ResolveNames_LogRow ended at 13:43 30/05/2012. [exit code=0]
It should work similarly with a method that creates a contact.
Hope it helps because I haven't found a lot of post on integrating Talend with Exchange Web Services despite searching for a long time.
Related
$Service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService([Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013_SP1);
In the above line Exchange2013_SP1 is hardcoded. Using powershell how can I dynamically get the version when running the script?
In the Code provided, you are trying to create an instance of WebServices.Data.ExchangeService(something similar to this), specifying exchange version via ExchangeVersion Enum.
However - the query after that is about knowing how to obtain Exchange Version via PowerShell. Probably this is very well documented and googling shows many hits about checking Exchange Version:
https://blogs.msdn.microsoft.com/deva/2012/04/27/powershell-determine-version-number-build-number-and-service-pack-of-exchange-server/
https://blog.jasonsherry.net/2012/12/27/get-exchangever/
If you make a request like Binding to the Inbox of a Mailbox in the response the build details of the CAS Server the processed the response is returned https://msdn.microsoft.com/en-us/library/microsoft.exchange.webservices.data.exchangeservicebase.serverinfo(v=exchg.80).aspx and exposed via the ExchangeService Class this can be used to tell the CU that's been applied to the Target and is the most useful thing if you trying to track errors etc.
EWS Schema version (which is what you have hardcoded) and Server versions are two different things so I would suggest you read https://msdn.microsoft.com/en-us/library/office/dn741586(v=exchg.150).aspx . Autodiscover can be used to find the highest EWS Schema version of CAS server.
We are using WSO2 Carbon 4.2.0 through the WSO2 Application Server (AS) package. In replacing an older, highly customized Carbon installation (provided by a company that no longer supports the product, has abandoned it and refuses to work on it, and left us no details on how/what they modified in Carbon), we have deployed a couple web applications in the webapps container as they were deployed before in the older instance. We have changed our WebContextRoot in the carbon.xml from the default "/" to a sub-URL of ex: "/stuff", as is also detailed in the self-answered SO question here. However the answer given there is not detailed in what the OP actually encountered when he modified his WSO2 instance.
In testing the above configuration we noticed that if a user were to go to a non-existent web address on the server, depending on the format of the URL they are either:
redirected to a blank page;
receive a "500 Internal server error" (I suspect this is the embedded Tomcat?);
get sent to the Carbon login page (which we definitely do not want to happen for security reasons); or
get an XML document stating:
<faultString> The service cannot be found for the endpoint reference (EPR) /stuff/services/nonexistantservicename </faultString>
At least in the case of missing content we wish the user to be sent to a standardized 404 error page, or at the least be sent an HTTP 404 error by the server. For services the XML error is palatable, we can deal with that.
The only option for us right now to circumvent this issue is to place a proxy in front of the WSO2 instance, which would be another layer to manage and tune, and possibly degrade performance. Please know that I am not a programmer but just an admin with DevOps experience. I would not know how to handle this with e.g. a Java solution or re-coding parts of WSO2. Customizing the core product would also hamper future upgrades of WSO2, a scenario we are trying to dig ourselves out of now as detailed above. Is there no internal WSO2 mechanism to handle non-existent content? Can we not redirect any errors to a standard canned response page?
I'm using IBM Integration Bus v10 (previously called IBM Message Broker) to expose COBOL routines as SOAP Web Services.
COBOL routines are integrated into IIB through MQ queues.
We have imported some COBOL copybooks as DFDL schemas in IIB, and the mapping between SOAP messages and DFDL messages is working fine.
However, when the message reaches a node where a serialization of the message tree has to take place (for example, a FileOutput or a MQ request), it fails with the following error:
"The PIF data could not be found for the specified application"
This is the last part of the stack trace of the exception:
RecoverableException
File:CHARACTER:F:\build\slot1\S000_P\src\DataFlowEngine\TemplateNodes\ImbOutputTemplateNode.cpp
Line:INTEGER:303
Function:CHARACTER:ImbOutputTemplateNode::processMessageAssemblyToFailure
Type:CHARACTER:ComIbmFileOutputNode
Name:CHARACTER:MyCustomFlow#FCMComposite_1_5
Label:CHARACTER:MyCustomFlow.File Output
Catalog:CHARACTER:BIPmsgs
Severity:INTEGER:3
Number:INTEGER:2230
Text:CHARACTER:Caught exception and rethrowing
Insert
Type:INTEGER:14
Text:CHARACTER:Kcilmw20Flow.File Output
ParserException
File:CHARACTER:F:\build\slot1\S000_P\src\MTI\MTIforBroker\DfdlParser\ImbDFDLWriter.cpp
Line:INTEGER:315
Function:CHARACTER:ImbDFDLWriter::getDFDLSerializer
Type:CHARACTER:ComIbmSOAPInputNode
Name:CHARACTER:MyCustomFlow#FCMComposite_1_7
Label:CHARACTER:MyCustomFlow.SOAP Input
Catalog:CHARACTER:BIPmsgs
Severity:INTEGER:3
Number:INTEGER:5828
Text:CHARACTER:The PIF data could not be found for the specified application
Insert
Type:INTEGER:5
Text:CHARACTER:MyCustomProject
It seems like something is missing in my deployable BAR file. It's important to say that my application has the message flow and it depends on a shared library that has all the .xsd files (DFDLs).
I suppose that the schemas are OK, as I've generated them using the Toolkit wizard, and the message parsing works well. The problem is only with serialization.
Does anybody know what may be missing here?
OutputRoot.Properties.MessageType must contain the name of the message in the DFDL schema. Additionally when the DFDL schema is in a shared library, OutputRoot.Properties.MessageSet must contain the name of the library.
Sounds as if OutputRoot.Properties is not pointing at the shared library. I cannot remember which subfield does that job - it is either OutputRoot.Properties.MessageType or OutputRoot.Properties.MessageSet.
You can easily check - just check the contents of InputRoot.Properties after an input node that has used the same shared libary.
Faced a similar problem. In my case, a message flow with an HttpRequest node using a DFDL domain parser / format to parse an HTTP response from the remote system threw this error (PIF data could not be found for the specified application). "Re-selecting" the same parser domain & message type on the node followed by build / redeploy solved the problem. Seemed to be a project reference related issue within the IIB toolkit.
you need to create static libraries and refer to application.
in compute node ur coding is based on dfdl body
I have to implement a simple client to a XDS.b server (SubmitObjectRequest and RetrieveDocumentSetRequest operations), but I'm struggling to get even a simple example of use to work.
I've tried using Mirth Connect's Channel for XDS.b also, but with no use. I even tried to copy its SOAP envelope to use with SoapUI. Didn't work.
I'm using HIEOS deployed on Glassfish as my XDS.b server.
I'm lost and confused. Could anyone give me a guidance on how to make this work?
If the HIEOS is deployed correctly within the Glassfish the service endpoint provides a wsdl definition where the interface is specified. Check the Glassfish for the wsdl of the service.
http://localhost:8080/my-ws/simple?WSDL
Quelle: docs.oracle.com/cd/E18930_01/html/821-2418/gbiyw.html
The list of provided endpoints you can see here:
https://kenai.com/projects/hieos/pages/WebServices
So to retrieve the wsdl you should use for example:
http://localhost:8080/axis2/services/xdsrepositoryb?wsdl
which applies for the ProvideAndRegisterDocumentSet-b transaction of the XDS Repository actor.
You can use the WSDL definition to create a WS request using SOAP UI at first.
SOAP UI creates a request based upon the wsdl definition which can be used to
test a against your XDS repo.
When you know how a SOAP request must be constructed you can try it using Mirth or
create your own client using Apache CXF http://cxf.apache.org/ for example.
Or you use AXIS2 to create a client from the WSDL. Of course does Visual Studio and C# also offer mechanisms to create a WS client directly from a WSDL definition.
I have been going through the google tutorial ( which I find very good ) at
https://developers.google.com/web-toolkit/doc/latest/tutorial/RPC
I have the service up and running on my local server and my JavaScript client can call it fine. OK so far. Now, what I want to do is deploy the service on a remote server JoeSoapHost:8080
How do I now tell my client where to send it's requests? I can't see any server/url being created in my RPC call. It just works by magic but now I want to get under the bonnet and start breaking it.
[Edit}
This is the Interface my client uses to know what service on the Server is to be called. I know that my Web.xml web descriptor must have a url that matches this. It has this because my server is invoked ok. Problem is, if I now decide to deploy my server elsewhere how do I tell my client what server/domain name to use?
#RemoteServiceRelativePath("stockPrices")
public interface StockPriceService extends RemoteService
{
StockPrice[] getPrices(String[] symbols);
}
What I want to achieve first is have a simple GWT client calling into an RPC service. I have this working but only when the server is localhost.
Next step, I deploy my app to the Google App Engine. What must I change now because my RPC service in my JavaScript is not being called when I deploy my app to
http://stockwatcherjf.appspot.com/StockWatcher.html
1) Brian Slesinsky excellent document on RPC - https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit#heading=h.amx1ddpv5q4m
2) #RemoteServiceRelativePath("stockPrices") allows GWT code to determine relative to your host/server/domain i.e http//mydomain.com/gwtapp/stockPrices
3) You can search GOOGle IO Sessions from 2009 - 2012 for some more in depth stuff on GWT RPC usage.
#RemoteServiceRelativePath gives the path of the servlet relative to the GWT.getModuleBaseURL() (which is more or less the URL of the *.nocache.js script); it doesn't "just work by magic".
If you deploy your services on a different server than the one serving your client code, then you'll likely hit the Same Origin Policy. CORS can help here, but you'll lose compatibility with IE (up to IE9 included). You'd better stick serving everything from the same origin.