Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Nickel Contributor
Posts: 56
Registered: ‎03-26-2009

GroupTranslator.DLL woes

I am accessing the GroupTranslator.DLL externally and it works great on most sites.

 

I am working with a site right now though where it seems that even though they are on SLX 7.5.2, NONE of the workstations seem to have GroupTranslator.DLL installed.

 

1. Is there a legitimate reason why this could be?

2. What is the best way of fixing this?

 

I've tried just copying the file and registering the DLL, but when I invoke it, it fails to create the object on a Win7/32 machine with admin priveleges.

 

Any other helpful suggestions are welcome...

 

ws

Gold Super Contributor
Posts: 3,087
Registered: ‎03-19-2009

Re: GroupTranslator.DLL woes

 


@wshpuntoff wrote:

I am accessing the GroupTranslator.DLL externally and it works great on most sites.

 

I am working with a site right now though where it seems that even though they are on SLX 7.5.2, NONE of the workstations seem to have GroupTranslator.DLL installed.

 

1. Is there a legitimate reason why this could be?

2. What is the best way of fixing this?

 

I've tried just copying the file and registering the DLL, but when I invoke it, it fails to create the object on a Win7/32 machine with admin priveleges.

 

Any other helpful suggestions are welcome...

 

ws


 

On the dll reg issue - take a look at this post:

 http://community.sagesaleslogix.com/t5/Administration/Windows-7-install-problems/m-p/17979#M1195

--
RJ Ledger - rjledger@rjlSystems.net +1 603.369.3047 x101

".. Innovators in Mobility - Experts in Workflow Automation..."
http://www.rjlSystems.net - blog: www.rjlSystems.net/blog.html
Nickel Contributor
Posts: 56
Registered: ‎03-26-2009

Re: GroupTranslator.DLL woes

Thanks for the link...

 

I did register the DLL with run as Admin, but that DEP stuff might be worth a shot.

 

Any ideas why the DLL wasn't there in the first place?

I'm wondering if this might be part of a bigger issue.

 

ws

Employee
Posts: 629
Registered: ‎04-24-2009

Re: GroupTranslator.DLL woes

What is it you are trying to accomplish that you cannot accomplish in the LAN client? GroupTranslator.dll is strictly designed to be used on the web server and is installed by the web host install. It is not designed to be used by customizations, but by the group functionaltiy on the web, which is exposed through HTTP handlers. In addition, GroupTranslator.dll has some special group processing that only applies to the web; if you are trying to tie it into the LAN client you may run into issues other than the install issue.

 

Thanks

 

Mike

Nickel Contributor
Posts: 56
Registered: ‎03-26-2009

Re: GroupTranslator.DLL woes

I am running an external application that uses the SalesLogix group as a starting point in a process. Since it runs as a service, it will not be a big issue to make sure it has access to the GroupTranslator dll. I believe that the DLL is part of the admin tools installation, probably part of the Application Architect install.  I had not realized that it was a server componenent only. I ran into problems where a client gave me a workstation for their test environment and it did not have the server components on it, so i got confused...

 

The alternative to using the GroupTranslator DLL would be to parse the blob - which i made a fair amount of progress on before i switched to the GroupTranslator world. Since neither one is documents as far as i know - it was a "pick your poison" situation. With the blob - i had extracted the base SQL, but was starting to figure out the paramater substitution when i changed gears and went for the GroupTranslator.

 

I am quite willing to use whatever is Sage recommended (& documented) - just let me know which one to use here before i get too many more installs going.

 

BTW - there is a bug in group translator - the ViewSQL method strips the AdHoc GroupID. I had to handle that in my wrapper function.

Employee
Posts: 629
Registered: ‎04-24-2009

Re: GroupTranslator.DLL woes

[ Edited ]

I understand your dilemma; however, GroupTranslator.dll is strictly designed for the web and there are post-processing steps that take place in the HTTP handlers to further process the XML information returned by GroupTranslator.dll. You may find you run into issues with DateTime values and/or parameters, in addition to multibyte/Unicode issues. My recommendation would be to use the existing HTTP handlers to request group information from the web portal or use SData.

 

I'm not sure if it will help your scenario, but in 7.5.2 LAN HF14 we added a new function to Application.BasicFunctions named GetGroupSQLInfo; it will return all of the separate parts of the group SQL (e.g. SELECT, FROM, WHERE, etc.). I've attached an example of this new function in a bundle included in the archive "Example of GetGroupSQLInfo."

 

In addition to the new GetGroupSQLInfo function, you may be interested in a newer built-in function implemented by SLXOLEDB named slx_GetSecuredSQL(sql) that was introduced in SLX - 7.5.2 HF12. You can pass in your "unsecured" SQL and it will secure it for processing through the "native" OLEDB provider (i.e. MSSQL or Oracle; [NOT] SLXOLEDB; THE SECURED SQL WILL FAIL THROUGH SLXOLEDB). This function is designed so that SQL requests can be made to the native OLEDB provider with the addition of our security joins and calculated field processing, etc.

 

Example (for SLX eval user "robert"):

 

slx_GetSecuredSQL('SELECT * FROM sysdba.CONTACT')

 

Produces:

 

SELECT CONTACT.CONTACTID,CONTACT.TYPE,CONTACT.ACCOUNTID,CONTACT.ACCOUNT,CONTACT.DEPARTMENT,CONTACT.ISPRIMARY,CONTACT.LASTNAME,CONTACT.FIRSTNAME,CONTACT.MIDDLENAME,CONTACT.PREFIX,CONTACT.SUFFIX,CONTACT.ADDRESSID,CONTACT.SHIPPINGID,CONTACT.WORKPHONE,CONTACT.HOMEPHONE,CONTACT.FAX,CONTACT.MOBILE,CONTACT.PAGER,CONTACT.PINNUMBER,CONTACT.PAGERNUMERIC,CONTACT.EMAIL,CONTACT.SECONDARYEMAIL,CONTACT.WEBADDRESS,CONTACT.DESCRIPTION,CONTACT.TITLE,CONTACT.ASSISTANT,CONTACT.BIRTHDAY,CONTACT.SPOUSE,CONTACT.SPOUSEBIRTHDAY,CONTACT.ALUMNI,CONTACT.YEARGRADUATED,CONTACT.INTERESTS,CONTACT.PREVIOUSEMPLOYER,CONTACT.DIRECTIONS,CONTACT.REPORTSTO,CONTACT.SECCODEID,CONTACT.ACCOUNTMANAGERID,CONTACT.REGIONALMANAGERID,CONTACT.DIVISIONALMANAGERID,CONTACT.STATUS,CONTACT.CREATEDATE,CONTACT.CREATEUSER,CONTACT.MODIFYDATE,CONTACT.MODIFYUSER,CONTACT.REFERRAL,CONTACT.LASTNAME_UC,CONTACT.INITIALS,CONTACT.ALTERNATEKEYPREFIX,CONTACT.ALTERNATEKEYSUFFIX,CONTACT.LOCATIONCODE,CONTACT.USERFIELD1,CONTACT.USERFIELD2,CONTACT.USERFIELD3,CONTACT.USERFIELD4,CONTACT.USERFIELD5,CONTACT.USERFIELD6,CONTACT.USERFIELD7,CONTACT.USERFIELD8,CONTACT.USERFIELD9,CONTACT.USERFIELD10,CONTACT.WEBPASSWORD,CONTACT.WEBUSERNAME,CONTACT.WEIGHT,CONTACT.DONOTSOLICIT,CONTACT.SCORE,CONTACT.EMAIL3,CONTACT.DONOTEMAIL,CONTACT.DONOTPHONE,CONTACT.DONOTMAIL,CONTACT.DONOTFAX,CONTACT.IMPORTSOURCE,CONTACT.SUBTYPE,CONTACT.OTHERPHONE,CONTACT.PREFERRED_CONTACT,CONTACT.WEBPASSWORDHINT,CONTACT.ISSERVICEAUTHORIZED,CONTACT.CUISINEPREF,CONTACT.CHILDREN,CONTACT.LASTHISTORYDATE,CONTACT.LASTHISTORYBY,CONTACT.WEBADDRESS2,CONTACT.SALUTATION,CONTACT.CATEGORIES,(isNull(C_AAD.COUNTY,'') + ' ' + isNull(C_AAD.COUNTRY,'')),(isNull(CONTACT.LASTNAME,'') + ' ' + isNull(CONTACT.SUFFIX,'') + ', ' + isNull(CONTACT.FIRSTNAME,'') + ' ' + isNull(CONTACT.MIDDLENAME,'')),(isNull(CONTACT.LastName,'') + ', ' + isNull(CONTACT.FirstName,'')),(isNull(CONTACT.FIRSTNAME,'') + ' ' + isNull(CONTACT.LASTNAME,'')),(isNull(C_AAE.ADDRESS1,'') + ' ' + isNull(C_AAE.ADDRESS2,'')),(isNull(C_AAF.CITY,'') + ', ' + isNull(C_AAF.STATE,'') + ' ' + isNull(C_AAF.POSTALCODE,'')),(isNull(CONTACT.PREFIX,'') + ' ' + isNull(CONTACT.FIRSTNAME,'') + ' ' + isNull(CONTACT.LASTNAME,'')),CONTACT.SECCODEID SLXSECCODEID91 FROM sysdba.CONTACT INNER JOIN SECRIGHTS S_AA ON (S_AA.ACCESSID = 'UDEMOA00000B' AND CONTACT.SECCODEID = S_AA.SECCODEID )  INNER JOIN ADDRESS C_AAD ON (CONTACT.ADDRESSID=C_AAD.ADDRESSID) INNER JOIN ADDRESS C_AAE ON (CONTACT.ADDRESSID=C_AAE.ADDRESSID)  INNER JOIN ADDRESS C_AAF ON (CONTACT.ADDRESSID=C_AAF.ADDRESSID)

  

Thanks

 

Mike

Nickel Contributor
Posts: 56
Registered: ‎03-26-2009

Re: GroupTranslator.DLL woes

Long term I will be moving to SDATA, but in the meantime I have customers and prospects on 7.2x LAN that I need to support, and I'm not about to require the SDATA portal to install my product. (I don't want to put up barriers to adoption). And yes, believe it or not - I actually have TWO prospects that are on 6.2 LAN of all things.

 

I will take a look at the contents of the bundle in a little bit.

 

In the meantime - I need a strategy for working with groups. Right now - using the DLL, I have to have some rules that

1. No selection criteria against calculated fields

2. no relative dates

 

I would love to remove that restriction. Is there any documentation on how to deal with those items, or even better - documentation on how to parse the blob directly to handle parameters and relative dates?

Employee
Posts: 629
Registered: ‎04-24-2009

Re: GroupTranslator.DLL woes

[ Edited ]

There is no documentation available for parsing blobs, or for how GroupManager handles the XML; you can use Reflector to see how GroupManager processes the XML.

 

The calculated fields simply need to have the @ stripped from their names, to be passed to SLXOLEDB (assuming you are going through SLXOLEDB). If you need to expand them yourself to go through the native provider, then you will have to create a lookup table to translate how SLXOLEDB expands these.

 

Example of  a layout containing a calculated field:

 

|CONTACT:@NameLF|NAMELF|Name|150||0|0|0|0|T|F||

 

As processed by SLXOLEDB:

 

SELECT NameLF FROM CONTACT is equivalent to:

 

SELECT (isNull(CONTACT.LastName,'') + ', ' + isNull(CONTACT.FirstName,'')) NameLF1 FROM CONTACT

 

You would have to handle the unique aliasing, if not using SLXOLEDB.

 

As far as date ranges for Conditions, these are normally stored in the TParameters part of the blob, but they are initialized when the component is instantiated, so you wouldn't have the right values. You would also have to handle UTC conversions.

 

Example of conditions: |CONTACT:MODIFYDATE|A1.MODIFYDATE| WITHIN- |30|END|11|F|||F|

 

Meaning: Within the last 30 days (WITHIN-).

 

Within the last 30 days is interpreted as:

 

The first date should be 30 days in the past (e.g. 1/17/2011 (in UTC) if today is 2/16/2011; for CST that would be 1/17/2011 6:00:00 AM); the second date should be 2/17/2011 (in UTC) if today is 2/16/2011; for CST that would be 2/17/2011 6:00:00 AM).

 

This would result in the following condition:

 

WHERE (A1.MODIFYDATE>='1/17/2011 6:00:00 AM' AND A1.MODIFYDATE<'2/17/2011 6:00:00 AM')

 

The WITHIN+ (within next) is similar:

 

WHERE (A1.MODIFYDATE<'3/19/2011 5:00:00 AM' AND A1.MODIFYDATE>='2/16/2011 6:00:00 AM')

 

Thanks

 

Mike

 

Nickel Contributor
Posts: 56
Registered: ‎03-26-2009

Re: GroupTranslator.DLL woes

Mike,

 

Thanks for that info.It was very helpful.

 

I finally bit the bullet and reverse engineered my own "Group Translator". The final straw was when I had to implement on a v7.0 system and provide that functionality.

 

If anybody has a "Group Translator Killer" query out there that you can share with me - i would love to add that to my testing.

 

ws