Firstly – this blog assumes you’ve set up a standard
NetSuite to PBCS integration – please see my blog here
for a step-by-step walkthrough to set up a standard integration.
There are, however, a few problems with the standard
integration. It’s powered by a role in NetSuite called, intuitively, PBCS
Integration. A role in NetSuite effectively acts like a Security
Group in Hyperion, it grants you access to other NetSuite items. By
assigning this role to a user account, you can log-in with the user account in
FDMEE and power your integration through it.
However, this role is locked – so you can’t amend any of its
permissions. This is a problem because:
- It has very high-level access – in our experience we wanted to integrate time records but not financials – and our integration admin would have access to everything.
- It doesn’t have access to custom modules, and as it’s locked you can’t add this in
The solution to both problems is to create a custom role –
but there’s an extra step that makes it slightly harder than it ought to be.
To do this, navigate to Setup > Users/Roles > Manage
Roles and locate the PBCS Integration role – note the little padlock
indicating it is locked. Press Customise and you will have the
option to duplicate – give it any name that you like (in our case, PBCS
Integration 4) and now you have an identical role which can have
unnecessary access removed. We also took the extra step of ensuring the ID
contained customrole_nspbcs to follow other patterns, but this might not
be necessary.
However, there’s one extra step needed – because we found
that switching to our custom role broke our existing integrations, which were
powered by the standard role. FDMEE would give an error code of “You do not
have privileges to view this page”.
Very odd, considering our custom role is exactly the
same as the standard one. Switching to log level 5 revealed this helpful nugget
– it was attempting to connect to a RESTlet known as a Script Deployment.
By navigating to Customization - > Scripting ->
Script Deployments and finding the deployments mentioned above, we found
that by default the deployment is available only to Administrators and
the standard role PBCS Integration.
We opened ours up to all roles to avoid this issue in
future, safe in the knowledge that it’s still securely protected by the
username and password required to obtain any data. Repeat this step for all
three deployments.
Now our integrations work beautifully, and we were able to
add access to our custom module to this role to power even more custom
integrations with no extracts or hassle.
Want to know more about creating custom queries for
integrating metadata and custom module data? There’s a blog for that too –
check it out soon.
Until next time,
Mike