
On page 19/20 of the BMC Analytics for BSM 2.0 Administrator's Guide is the description of how the multitenancy is done.
On page 20 it shows the SQL for creating the derived table. This shows that it is based on CONTACT_COMPANY.
I can't find a 2.5 Admin Guide, but testing shows that it now correctly uses the CUSTOMER_COMPANY.
However, as it happens, that is not the company field that is most appropriate for us.
It is the correct one for multitenancy in an outsourcing context,
therefore correct for what the ITSM model was based on.
How do we get to this SQL statement so we can modify it to use the Assigned Group company?
(or anything else we desire really).
As an aside, I am having a lot of trouble finding easily how to do things in the Analytics system when you
don't know Business Objects, i.e. when you are from the BSM ITSM world. There is information on how
to do reporting etc. but not for permissions etc. Might be a useful extra guide or chapter.
thanks ... Daniel
p.s. but yes, I do have it installed and working, very powerful tool indeed
Hello Daniel:
I'm not able to address your issue about the company field, as I'm the technical writer assigned to this product, but I am able to respond to your comments about the documentation.
You are correct in that there is no administrator's guide for version 2.5, as there is now an installation guide, a user guide, and a reference guide. The information to which you are referring is now in the installation guide, in Appendix B, "Troubleshooting". Unfortunately, it still mentions Contact_Company instead of Customer_Company. I'll submit a defect for this and make sure that it is updated in the next release of the doc.
In reference to your comment about the Business Objects information, we've tried to minimize the amount of BusinessObjects information that is duplicated within the BMC Analytics for BSM product documentation. For the 2.5 release, we now post the Business Objects documentation on the BMC Analytics for BSM customer support page, for easier reference. However, I will bring up the permissions question to the team to see how we can better address this in the next release.
I appreciate any comments you have on the user documentation. Thank you for bringing these specific items to my attention.
Regards,
Mary Gwynne
Thanks for the response.
We have discovered that the permissions and which field is stranger than we thought so once I tallk to the technical folks there may be more clarifications needed.
my official advice for you is NOT to try and customize the SQL query.
multi-tenancy is a fundamental concept of BSM.
With ITSM 7.0.x, it leverages the company field.
In the next releases of ITSM, this concept will be more and more flexible, and Analytics will evolve to leverage these changes.
take-aways:
- everytime you upgrade ITSM and/or Analytics, any customization you've done will have to be QA'ed / redone for non-regression.
- it may be easier for you to change your foundation data so that it matches semantics of ITSM (but it sure depends on your implementation (production status, etc)
That being said, if somebody can find the SQL-tweak (I can't, but will ask around in R&D), it may be an ok answer for you in the short term.
In the mid-term/long-term, it will be far easier for you if you follow the semantics of the Product.
Assumed Answered
Matt et al,
The SQL for the multi-tenacy support is stashed in the derived tables in the Universe definition e.g. HPD_HELP_DESK
SELECT *
FROM HPD_HELP_DESK
WHERE HPD_HELP_DESK.CONTACT_COMPANY IN (SELECT DISTINCT COMPANY
FROM CTM_PEOPLE_PERMISSION_GROUPS
WHERE REMEDY_LOGIN_ID = @VARIABLE('BOUSER')
AND COMPANY IS NOT NULL
UNION
SELECT DISTINCT COMPANY
FROM CTM_PEOPLE_ORGANIZATION
WHERE (SELECT 1
FROM CTM_PEOPLE_PERMISSION_GROUPS
WHERE REMEDY_LOGIN_ID = @VARIABLE('BOUSER')
AND PERMISSION_GROUP = 'Unrestricted Access') = 1
AND COMPANY IS NOT NULL)
I found this when trying to resolve a case mismatch problem between REMEDY_LOGIN_ID and @VARIABLE('BOUSER')
It turns out that there is a significant number of these derived tables so it isn't practical to modify them all as upgrading the Universe (2.5.0.1 is now available) will remove all of your customizations
I would suggest that this multi-tenancy code should exist in a single derived table, that is used throughout the Universe so only one place needs to be customized
Roger
ps
the enhancement I was looking for was to change
WHERE REMEDY_LOGIN_ID = @VARIABLE('BOUSER')
to
WHERE UPPER(REMEDY_LOGIN_ID) = UPPER(@VARIABLE('BOUSER'))
R