on 06-21-2016 7:06 AM
Hi HCI Experts,
We're trying to build an iFlow in HCI that looks something like the Async-Sync bridge in PI. I understand that there's the Request-Reply pattern in HCI that could accomplish this, as discussed here . However, I'm getting no luck so far when trying to deploy the iFlow.
So the scenario is:
ECC IDoc (Async) -> HCI -> C4CWebService_Request (Sync) -> C4CWebService_Response -> HCI -> Custom Web Service in ECC
1. ECC sends an IDoc to HCI.
2. HCI takes care of the mapping and sending of the request message to the standard Web Service (WS) in C4C. The standard WS in C4C is Synchronous.
3. Now, the response of the standard WS in C4C must be sent back to ECC thru a Custom web service created in SOAMANAGER.
4. Response of WS from C4C is sent back to HCI where message mapping will take place and send it to the web service in ECC.
During deploy, I'm getting an error that says 'Receiver Channel cannot be configured for synchronous WSDL configuration.' Is it because the custom web service in ECC is synchronous and HCI cannot handle that?
Has anyone ever done this scenario with success?
Appreciate any inputs.
Thanks in advance.
Mark
Hello Mark,
You would need to switch this a little.
- Add an additional Request-Reply Step post the response mapping. This request reply will make the call to ECC and get the response.
- The Response will then need to be connected to the End Event.
Regards
Bhavesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Bhavesh,
Do you know by any chance if it's possible to get the value of a certain field in my source IDoc message and assign that value into one of the fields in my source message for the 2nd message mapping (after the 1st Request-Reply)? Is this possible using Content Modifier, Externalized Parameters or Variable?
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello Mark,
Ideally to ensure that threads are searchable for users with same issues, etc it is recommended to have a new thread for a new question. Here is the answer to this one though!
There are multiple ways to persist a value and then use them in subsequent steps. One of the options is to use Variables.
Updated iFlow
Write Variable is used to Write a Local Variable
In this case I have created a Variable called " variable1" and assigned it a "Constant" Value "India".
You may use XPATH to access your Input Payload and persist the variable.
Accessing Variable in Content Modifier Step
Use ${header.variable1} where variable1 is the name of the Variable.
Data in the Runtime where variable value in inserted into Payload
Regards,
Bhavesh
PS: This makes me also realise that this concept is probably very confusing in HCI. Will think of a means to write a blog to explain these concepts!
Thanks Bavesh for the reply! Right, will create a separate thread for this.
So in my case, since I'm using Mapping instead of Content Modifier, I need to add a new Content Modifier before the 2nd mapping/after the 1st Request-Reply and create a Body that would access the Variable just like what you've shown. Is that right?
Hi Bhavesh,
Here's my updated iFlow. I added Write Variable and Content Modifier. For the variable, I used a constant value for now instead of XPATH.
It's not working. It's either the Variable is not working / getting saved or I messed up with the Content Modifier. How do you fill up the message in the Body tab of the Content Modifier? The example in the guide is too simple. What if we need to assign the Variable's value in an existing field of a message payload like in my case?
What I did so far is copy pasted the whole message payload (this is the actual response message of the 1st Request-Reply from COD) and assigned the placeholder of the variable in one of the fields.
Thanks in advance.
Hi Bhavesh,
Here's the new thread that I created.
This is what my iFlow for the same requirement looks like,
- Instead of mappings, I have Content Modifiers to set my Payload.
- 1st Request Reply ==> Equivalent to making a call to C4C in your case.
- 2nd Request Reply ==> Equivalent to making a call to ECC Webservice
- While the 2nd Request Reply makes the call to the Original System, it still has to be a Receiver System as Request Reply only works with Receiver System.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Bhavesh! It works. I just had to do some minor tweak in your iFlow and remove the connector from End back to the Sender. Otherwise, I'm getting an error 'Cannot model response back to the sender for asynchronous WSDL Configuration' perhaps because I'm using IDoc as the sender interface.
This is my final iFlow:
Thanks again!
Yes indeed., As your IDoc WSDL does not contain a response type it will not let you connect your request reply to the Send Step. Logically as well - If your Idoc did get an XML response it wouldnt know what to do with.
Have you also looked at the fact that the Idoc goes into error mode if your iFlow goes into error?
As the Idoc is sent over SOAP XML Port, until the iFlow does not complete processing and return a HTTP 200 OK, the IDoc continues to wait. So from ECC you can directly tell if the Iflow was successful or not. Its not the classical way and a learning in itself
Regards
Bhavesh
Hello Mark,
For sending the response back don't configure the Receiver channel ,just drag connector from End Message step to Sender System and then try to deploy.
Usually this works fine when we are having synchronous sender SOAP Channel. I tried this scenario and it worked fine.Make sure in the response mapping SOAP Response structure only sent ( As per WSDL Response Structure).
Regards,
Sriprasad S Bhat
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
76 | |
9 | |
8 | |
7 | |
6 | |
5 | |
5 | |
5 | |
5 | |
5 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.