Sync Catalog item variable set in Service Bridge at provider side
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
08-08-2025 10:52 AM
Hi,
I have implemented service bridge in two of my instances. I have created a catalog item at provider side which have some simple variables and one variable set in which I again have around 15 variables listed.
I have a Remote task definitions created for sc_request and sc_req_item table.
I have a flow triggered at creation or updating of sc_request at provider side only, which in turn looks up respective RITM request.
If the RITM request is found, it creates a remote task for consumer of it, which then syncs to consumer side.
While testing the flow, the flow the failing at step 3 (Null pointer exception) which is create remote task for consumer with below error:
Error: Cannot invoke "Object.getClass()" because "this.val$data[index]" is null
While debugging I found, this error is coming because of variable set added in catalog item. If I remove the variable set or make variables inactive inside it, the flow works fine.
I don't know how do I make the flow validate these variables in variable set, I don't know how to proceed further. Attaching some screenshots for reference.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Hi Suraj.
Even though you can create a Remote Task Definition for sc_req_item, this isn’t going to be the best solution because the Catalog Item and its associated variables do not exist in the Consumer Instance. Instead, you should use a Remote Record Producer (RRP). In the Provider Instance you can create an RRP with a subflow which will order the Catalog Item. Updates can be passed from the Requested Item in the Provider Instance to the Consumer Instance via comments via the connected provider task.
I haven't tried to setup and test your particular configuration to be able to troubleshoot the issue.
I am curious to hear more about the use case that you are trying to solve for and if using an RRP work for you.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi Kenny,
Thanks for your response but RRP won't work in my case. The requirement is to create a REQ, RITM and SCTASK request at the provider side first and then sync it to consumer side. With REQ and SCTASK, I am getting no problem in creating a remote task for consumer with the help of respective RTD's but when I try to create the same for RITM in a flow, it gives me null error mentioned above. Standard variables with respect to catalog item causes no issue but as far as I understand problem lies with the variables inside a variable set that is added to the catalog item. The RTD for sc_req_item is not able to find variables inside that variable set. I even tried to explicitly mention all the variables inside the variable set shown below in screenshot but still no luck. Any findings on this would be helpful, otherwise at worst case scenario I have to go for REST implementation.
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
How are you passing the standard variables?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hello,
I think last time when I checked even if I don't pass any variable field in the RTD, the flow has no problem with standard one's irrespective whether it creates variables to the consumer side or not. Currently, for standard ones I don't have any specific mapping, and I think by default the flow has no issue if I create any mapping for them or not. In my scenario even if I somehow can pass all the variables in the work notes or description, that would be fine. I just want the remote RITM task to sync to the consumer side and let's say all the variables coming in description or work notes. That would also work for me.