
Hi All,
I am new to the BMC products and have recently been trying to work with the Atrium Orchestrator. My question is:
AO has a default security feature which mandates the presence of "SecurityHeader" in the incoming Soap request. In some scenarios, it might not be possible for the incoming request to carry all the security information.
Is it possible to disable this feature in AO so that any request without the secure header could be consumed?
If yes, then How? Else where can I find more information on the same.
Thanks in Advance,
Annu
Look in the 3.0 documentation series on the BMC support site for Web Services User Guide
Thanks Jake, for your reply. I have been through the document "RBA 3.0.00 Web Services User Guide.pdf".
It describes the process of exposing a process as a webservice and the corresponding wsdl.
My concern is regarding manipulating the wsdl format exposed by AO. Is there any way in which I can specify that the security information (which is by default mandatory) can be skipped in an incoming request?
I hope I am making myself clear!
I'm not aware of a method that allows you to acheive this. What is the use case for an un-athenticated web service call?
Hi Jake,
Thanks for assisting me with your reply.![]()
I am describing the use case below:
Lets consider a scenario in which the Web service client has been constructed already (say for a previous implementation). Now, I have been given a WSDL, on the basis of which I need to design my AO webservice. Here, the client is not expected to change.
So, all the AO specific information i.e. authentication info like grid username, password etc and some more additional imformation (like namespace which must point to the project name) will not be coming from the client. I either need to disable these in AO or I should intercept the SOAP request coming to AO using SOAP intermediaries to append this into the message.
I am trying to find some way to do this. Please suggest what would be the most appropriate way of resolving this issue.
Warm Regards,
Annu
Annu,
What you are trying to do here is not within the default realm/capabilities of any packaged product?
You are looking at having to write a SOAP/Web Services Bridge between your source application and Atrium Orchestrator where the bridge simulates the Web Service Operations 100% that the source system (which you state cannot change) is expecting. The Bridge would then turn around and execute the call against AO, get a response, and then reply back to the source system in the format it is expecting.
You are looking at having to write the Bridge in a low level language such as Java, or .Net, and I would question the overall design of this approach as well as its resilience to failure etc...
Unless you have the expertise available to build the Bridge in one of these languages then I would suggest you find an alternative approach, by either modifying the source system to be able to call AO directly, or finding an alternate communication mechanism (such as SNMP Traps, Polled Database Table, Flat File, Email, MQ/JMS etc...)
Robin.