[Apiman-user] Transformer policy plugin issue

Eric Wittmann eric.wittmann at redhat.com
Tue Jun 14 08:49:43 EDT 2016


Regarding #1 - yes good point.  If the transformation policy is not 
working for the input, then it is broken and we need to fix it.  I will 
create a new jira for this (I shouldn't have changed yours, sorry about 
that).

https://issues.jboss.org/browse/APIMAN-1188

Regarding #2 - SOAP uses namespaces and attributes which I doubt will 
get transformed in a sensible way with the generic transformation policy 
(e.g. the 'actor' attribute on a header).  I think a transformer that 
understands that it's dealing with SOAP will result in a much better 
implementation.

As for #3 - the Developer Guide should be pretty thorough.  Here is a 
blog post that might help as well:

http://www.apiman.io/blog/micro-services/development/2015/11/12/micro-services.html

-Eric


On 6/14/2016 1:57 AM, Ashish Patel wrote:
> Yes, sure will definitely try the custom plugin + contribution to OSS.
>
> On guiding part, below are my initial queries.
>
> 1. Currently XML Transformation plugin definition does not mention that it only works one way -> from backendAPI response to ClientApp. Ideally it should also work from ClientApp -> backendAPI request. I thought this is a bug and so logged as bug, if not then in Plugin Description it should mention that it only work for backendAPI responses.
>
> 2. SOAP is XML and so XML<->JSON should work for SOAP (as XML) message. Can you please elaborate more on the difference of transformation for SOAP/XML  ?
>
> i.e. <<SOAP-XML>>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:com:ia:eai:crm:cust:search">
>    <soapenv:Header/>
>    <soapenv:Body>
>       <urn:CustSearchReq>
>          <Mobile>1234567890</Mobile>
>       </urn:CustSearchReq>
>    </soapenv:Body>
> </soapenv:Envelope>
>
>
> <<SOAP-JSON>>
>
> {
> "soapenv:Envelope": {
> "soapenv:Body": {
>         "urn:CustSearchReq": {  "Mobile": "1234567890" }
> "xmlns:soapenv": "http://schemas.xmlsoap.org/soap/envelope/"
>  "xmlns:urn":"urn:com:ia:eai:crm:cust:search"
> "soapenv:Header": ""
> }
> }
> }
>
> 3. I have gone through http://www.apiman.io/latest/developer-guide.html, for environment setup (to start with CustomPlugin). Kindly guide if anything on top of this.
>
> Thanks & Regards,
> Ashish Patel
>
> "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein.
>
>
>
>
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: 13 June 2016 21:37
> To: Ashish Patel; apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Transformer policy plugin issue
>
> SOAP<->JSON conversion is, in my opinion, a separate feature request.  I
> have updated APIMAN-1182 to reflect that.
>
> I think this is a valuable feature to have, but given our current
> backlog of work I cant' give you any great idea of when it might be
> implemented.
>
> If you are up for it, it should be very possible to implement this
> functionality yourself as a custom policy.  Perhaps that could serve as
> a contribution back to the community which could then be improved upon
> for the benefit of all!  :)
>
> I'd be happy to provide some direction on such an effort.
>
> If that's not possible, we'll have to get to it as soon as we can. :)
>
> -Eric
>
>
> On 6/13/2016 1:04 AM, Ashish Patel wrote:
>> Thanks Eric for quick response.
>>
>> We want SOAP to JSON for our legacy Apps (like SAP ECC) which can't expose JSON. We want to have standard input for all our Mobile / APIs as JSON and so we need this conversion (though not 100% REST compatible).
>>
>> Sure, APIMAN-1182, opened.
>>
>> Thanks & Regards,
>> Ashish Patel
>>
>>
>> "Scientists investigate that which already is;Engineers create that which has never been." - Albert Einstein.
>>
>>
>>
>> -----Original Message-----
>> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
>> Sent: 10 June 2016 20:29
>> To: Ashish Patel; apiman-user at lists.jboss.org
>> Subject: Re: [Apiman-user] Transformer policy plugin issue
>>
>> The transformation policy may not be suitable for converting soap to
>> json.  Soap is xml, for sure, but it has a pretty specific format.  I'm
>> not sure a direct mapping with JSON is possible, so you might need a
>> custom plugin policy to accomplish this.
>>
>> That said, I would have expected the JsonToXmlTransformer to at least be
>> invoked on the request payload, even if the results aren't exactly what
>> is needed.
>>
>> Can you please open a JIRA for this bug?
>>
>> https://issues.jboss.org/projects/APIMAN
>>
>> Thanks,
>>
>> Eric
>>
>> On 6/9/2016 8:45 AM, Ashish Patel wrote:
>>> Hi,
>>>
>>>
>>>
>>> We are facing issue while using Transformer plugin.
>>>
>>>
>>>
>>> Scenario: We have SOAP Service in backend and want to expose as JSON to
>>> client App.
>>>
>>>
>>>
>>> 1. we have registered the SOAP service in Implementation (with Basic Auth).
>>>
>>> 2. added policy for using Transformation plugin (Client: JSON, Server:XML).
>>>
>>> 3. Published as Public API.
>>>
>>>
>>>
>>> Through Rest Client -> Called Public API (POST -> content type as
>>> application/json and json input), however it failed with 500 error (able
>>> to read stacktrace - suggest input is not passed correctly).
>>>
>>>
>>>
>>> With more debugging: As there are no logs from Transformation plugin,
>>> have added sysouts and found that JsonToXmlTransformer is NOT being
>>> called for input (json -> xml) transformation, however, on response
>>> XmlToJsonTransformer is being called successfully.
>>>
>>>
>>>
>>> Kindly suggest.
>>>
>>>
>>>
>>> Thanks & Regards,
>>>
>>> Ashish Patel
>>>
>>>
>>>
>>> "Scientists investigate that which already is;Engineers create that
>>> which has never been." - Albert Einstein.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> Disclaimer: This message may contain privileged and confidential
>>> information and is solely for the use of intended recipient. The views
>>> expressed in this email are those of the sender and not Future Group's.
>>> The recipient should check this email and attachments for the presence
>>> of viruses. Future Group accepts no liability for any damage caused by
>>> any virus transmitted by this email. Future Group may monitor and record
>>> all emails.
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>
>> Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails.
>>
>
> Disclaimer: This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not Future Group's. The recipient should check this email and attachments for the presence of viruses. Future Group accepts no liability for any damage caused by any virus transmitted by this email. Future Group may monitor and record all emails.
>


More information about the Apiman-user mailing list