Hi Folks,
I’m reaching out to seek some guidance and assistance regarding Mocking. I’m currently working on implementing mocking for a SOAP API within the webMethods API Gateway. If anyone here has experience with webMethods API Gateway and knows the ins and outs of setting up mocking for a SOAP API, I would greatly appreciate your insights.
Looking forward to hearing from you amazing people!
Waiting for some expert’s reviews on this
commenting for better reach to get response
So that you don’t feel completely ignored, I’ll give you my opinion though it won’t be very helpful. Many people find mocking useful and productive. I am not one of those people. 
Thus my suggestion is to not do it. I prefer connecting to the real thing, not a mock. Pros and cons to both approaches but IME the challenges related to mocking are not overcome by the relatively limited benefits. This is definitely a YMMV item.
but I need mocking for some testing purposes
Connecting to the real thing, which should be a dev/test instance, would serve that purpose more reliably, no?
Is there a specific reason why connecting to the real endpoint is not possible/reasonable? I’m not necessarily asking you to justify using a mock – there are cases where can be useful. I’m really just asking that you explore the perceived “need” to make sure the benefit outweighs the relative cost.
each real call/invocation costs me more than $40 like $40/request so thats why.
Even in dev/test? Seems unusual.
You can follow the below link to enable mocking
https://documentation.softwareag.com/webmethods/api_gateway/yai10-15/webhelp/yai-webhelp/#page/yai-webhelp%2Fapi_mocking.html%23
As per my experience you cannot directly mock the SOAP API. But there a catch, you can apply rest transformation on API and then you can MOCK the transformed rest resource.
In this fashion you can achieve mocking over the soap.
There is support for mocking SOAP API in APIGateway. Please follow the documentation link i pasted in the earlier comment.
I have to transform SOAP to REST, I mentioned earlier as well that I need SOAP mocking in webMethods API gateway
These are not conceptually equivalent things, per se. REST does not define/specify a format. Nor a protocol. REST is an architectural style that defines various principles to which an architecture would follow.
Of course “REST” has been abused and now is more generally thought to mean “JSON over HTTP”, without any regard to following any of the principles of the REST architectural style. As an industry, we morph terms that have perfectly good meanings into something completely different.
In any case, beware the constraints that you may need to address when transforming XML (SOAP enveloped or or not) to JSON. Single element arrays, attribute naming, complex elements, etc. are things you may need to be aware of and explicitly address, depending upon the complexity/nature of the XML that needs to be processed.