Log in as a System Administrator then go to Setup | Develop | API. On the API WSDL page you may then choose which WSDL to generate and download. I typically choose Enterprise WSDL.
You can then develop any web service client you need for interfacing with Salesforce / Remedyforce in Java, C#, etc.
Check out Salesforce's SOAP API Developer's Guide too.
Thank you Doug;
That´s exactly what i was looking for...
I have generated apex class from wsdl but I dot not know hot to proceed from there? what is the next thing to do? How do fields in the wsdl mapped to fields under the incident? Do I need to do some mapping as was done with email services? I am stalk. Could someone please, help me out.
Happy new year Doug, many thanks for your help in my integration journey. My wsdl integration is now working. I generated an apex class from the wsdl that was given to me and I tested it using execute anonymous window and it works. It writes data back to the application. The fields in the wsdl/apex class matches those from the application JTrac but they don't match the ones in RemedyForce (RF). I want the wsdl/apex class to be fired when an incident is created in RF force and when the same ticket is updated in the application (JTrac), I want the update to be written back to RF. To start with, how can I get the Apex class to be fired when an incident is created in RF? Thank you for your help. Regards, Hola
It sounds like you want bi-directional syncing between Remedyforce and JTrac.
Remedyforce will need to make SOAP/WSDL calls to JTrac to create/update JTrac records based on create/updates that occur in Remedyforce.
Likewise, JTrac will need to make SOAP/WSDL calls to Remedyforce to create/update Remedyforce records based on create/updates that occur in JTrac.
With bi-directional sync, do be cautioned against creating infinite loops. That is to say, if incident is created in Remedyforce that then causes JTrac to create a new record, you don't want the JTrac workflow to subsequently call back to Remedyforce to create a duplicate record.
Assuming you resolve the bi-directional infinite loop problem, you will be working with two (2) SOAP/WSDL web services. It sounds like you've already taken the JTrac WSDL and created apex classes for invoking the JTrac web service. That's half the battle. The other half is taking the Salesforce Enterprise WSDL and making whatever modifications necessary in JTrac to invoke it in order to create/update Remedyforce records.
I would recommend possibly introducing a third system into this mix purely for ETL purposes and alleviate much of the integration work out of Remedyforce and JTrac proper. For example, you could use the free community edition of MuleSoft (www.mulesoft.com) that periodically queries Remedyforce and JTrac systems and syncs the other system accordingly. This route, using an ETL tool, keeps your Remedyforce and JTrac systems abstracted from most of the nuances involved with the integration efforts.
If you do not use an ETL system but stick to making the web service callouts directly from Remedyforce and JTrac, then at least from the Remedyforce side you would need to call out to JTrac from within an apex trigger on the incident object. However, be cautioned, BMC already has a trigger on the incident object whose code you cannot change. So you would be adding a second trigger. Salesforce platform does not guarantee order of execution when 2 or more triggers exist for the same object. The BMC trigger does compute certain field values and SLA logic among other things, such as the Priority field computed from Impact and Urgency. So, for example, if your second trigger actually executed before the BMC trigger and if you wanted to send the Priority field to JTrac, it is likely that you would end up sending a null value to JTrac unless your trigger implemented the same logic as the BMC trigger. This and other issues, such as governor limits for how many web service callouts can occur per database transaction are reasons why I would reconsider using a formal ETL tool.
Keep up your efforts, sounds like you're making progress.
Many thanks for your response. Incidents will only be created in Salesforce and data sent to JTrac. but the tickets will only be updated in JTrac. No tickets will be created in JTrac. For ticket creation, its one way but olny the update is bidirectional.
The dataloader from mulesoft is asking for access to production. They don't even allow testing through sandbox. That sounds creepy to me.
Right now, I have used the JTrac wsdl to generate an apex class. I used test data and pass them into the fields through execute anonymous window but I don't know how to link it with the normal incident creation interface in RemedyForce. How can I links the fields in RemedyForce to the fields in the web service? To me this is similar to the mapping that you directed me to do through incident email settings when I was trying incident email creation. How can I accomplish the same with webservices/wsdl that I have just configured? It is definitely working when I passed data through the execute anonymous window.
Many thanks in advance for your further assistance.
I use the MuleSoft Anypoint Studio (community edition, free)
When you specify the salesforce configurations with the Salesforce Connector, you can indicate which URL to log in to, such as sandbox or production.
Good to hear you'll create in one system only, that will make it a bit better. I'm not sure about bi-directional updates... that might still throw you into an infinite loop unless you have some flag or something in each system to know "not to send reciprocal update back to other system because other system is the one updating me".
Taking things one step at a time, we can work on replicating a newly created Remedyforce incident into JTrac. Now that you've used the Developer Console to send data to JTrac web service, you essentially want to wrap that apex code into an Apex Class, something like "JTracWebServiceClient" or some similar. You can define methods in that class that take a BMCServiceDesk__Incident__c object as a parameter. You could create an apex trigger (note my cautions from earlier post) and for each new incident, invoke your apex class that would map the incident field values to the apex wsdl parameters to send to JTrac.