121
MP Server / Re: LDAP Synch and Netsted Groups
« on: April 18, 2019, 07:01:17 AM »
It should work.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
122
MP Server / Re: LDAP Synch and Netsted Groups
« on: April 03, 2019, 10:20:14 AM »
Are you talking about ensuring that users listed in nested groups are populated correctly in the root group in cmod?
123
Documentation / Re: Legal hold (ERM)
« on: March 15, 2019, 03:18:14 PM »
If it is a new application group have a look at Implied Hold
"When Content Manager OnDemand loads documents, it applies a hold to all the documents in that load. You can apply this type of hold only to documents in new application groups. Use this type of hold if you are using another solution as your retention management tool."
This would be the preferred solution for large scale holds.
"When Content Manager OnDemand loads documents, it applies a hold to all the documents in that load. You can apply this type of hold only to documents in new application groups. Use this type of hold if you are using another solution as your retention management tool."
This would be the preferred solution for large scale holds.
124
MP Server / Re: Listing of Load IDs with Index Values
« on: March 15, 2019, 07:01:00 AM »
While I don't have time at the moment to write up entire instructions here is, at a high level, what I would do.
1. Find the load ID of the load you're interested in looking at the index data for.
2. Use arsadmin retrieve to pull the index object (ex: 123FAA1)
3. Use arsadmin decompress to uncompress the object.
--> All meta data that was loaded to the database will be contained in the uncompressed data.
By following this method you can simply use supported, native OnDemand commands to perform the task before you.
Thanks,
RR
1. Find the load ID of the load you're interested in looking at the index data for.
2. Use arsadmin retrieve to pull the index object (ex: 123FAA1)
3. Use arsadmin decompress to uncompress the object.
--> All meta data that was loaded to the database will be contained in the uncompressed data.
By following this method you can simply use supported, native OnDemand commands to perform the task before you.
Thanks,
RR
125
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 14, 2019, 07:54:59 AM »
1. If its the same user (connection pool) make sure you use getDocID.
2. The docID should be returned in the response URLEncoded
URLEncoder.encode(odHit.getDocId(), java.nio.charset.StandardCharsets.UTF_8.toString()
3. Whether you need to decode the docID before you call recreateHit depends on how you send the data back to your rest api.
It shouldn't be to hard to do some logging and see how it gets passed in so you can determine whether you need to decode or not.
2. The docID should be returned in the response URLEncoded
URLEncoder.encode(odHit.getDocId(), java.nio.charset.StandardCharsets.UTF_8.toString()
3. Whether you need to decode the docID before you call recreateHit depends on how you send the data back to your rest api.
It shouldn't be to hard to do some logging and see how it gets passed in so you can determine whether you need to decode or not.
126
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 13, 2019, 10:10:48 AM »
Yes, that docID looks urlencoded.
127
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 13, 2019, 08:41:05 AM »
I would turn on ODWEK trace, rerun your test and then look for more detailed errors there. Report back..... Also, what is the exact version you are running, 10.1.0.?
128
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 12, 2019, 05:16:24 PM »
Using the getOpenDocID() comes with some overhead so it should be used wisely. Since there is no user tied to it we must makes sure the user who now has possession of the docid is authorized to see the content they are requesting.
So in the case of REST based services one should be using connection pooling (whenever possible) and therefor the getOpenDocID really shouldn't be needed..... At least in most cases.....
So in the case of REST based services one should be using connection pooling (whenever possible) and therefor the getOpenDocID really shouldn't be needed..... At least in most cases.....
129
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 12, 2019, 10:04:53 AM »
Assuming you have permission to the doc it's probably an encoding issue.....
Create yourself a little stand alone app. Get it working and then incorporate into your rest service.
In most cases the docID you include in your rest response should be URL encoded. Something like:
URLEncoder.encode(odHit.getOpenDocId(), java.nio.charset.StandardCharsets.UTF_8.toString()))
However, when you pass it back in to retrieve the content you shouldn't have to decode....
You're very close.... Good luck
-RR
Create yourself a little stand alone app. Get it working and then incorporate into your rest service.
In most cases the docID you include in your rest response should be URL encoded. Something like:
URLEncoder.encode(odHit.getOpenDocId(), java.nio.charset.StandardCharsets.UTF_8.toString()))
However, when you pass it back in to retrieve the content you shouldn't have to decode....
You're very close.... Good luck
-RR
130
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 12, 2019, 09:39:10 AM »
I see it now....
You should really log on before you try and open the folder
odFolder = odServer.openFolder(inFolder);
try
{
odServer.logon(inServerName, inUserName, inPassword);
}
Swap those two calls and watch the magic happen.
-RR
You should really log on before you try and open the folder
odFolder = odServer.openFolder(inFolder);
try
{
odServer.logon(inServerName, inUserName, inPassword);
}
Swap those two calls and watch the magic happen.
-RR
131
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 12, 2019, 08:13:59 AM »
So you confirmed you are using getOpenDocId()?
What error are you getting when you attempt to recreate the hit?
What error are you getting when you attempt to recreate the hit?
132
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 12, 2019, 07:07:47 AM »
See if this (albeit crude) example helps:
odServer.logon("shortrib", "admin", "password");
ODFolder folder = odServer.openFolder("Baxter Bay");
Vector<ODHit> hits = folder.search();
ODHit odHit = (ODHit)hits.get(0);
String hit = odHit.getOpenDocId();
odServer.logoff();
odServer.terminate();
odServer = new ODServer(odConfig);
odServer.initialize("TestOpenDocId");
odServer.setPort(0);
odServer.logon("shortrib", "rjrussel", "password");
folder = odServer.openFolder("Baxter Bay");
ODHit hit2 = folder.recreateHit(hit);
System.out.println("Recreated:" + hit2.getDocumentName());
Keep in mind in order for recreate hit to work the user recreating the hit MUST have permissions to the document. If that user doesn't you will still get an error.
Thanks,
RR
odServer.logon("shortrib", "admin", "password");
ODFolder folder = odServer.openFolder("Baxter Bay");
Vector<ODHit> hits = folder.search();
ODHit odHit = (ODHit)hits.get(0);
String hit = odHit.getOpenDocId();
odServer.logoff();
odServer.terminate();
odServer = new ODServer(odConfig);
odServer.initialize("TestOpenDocId");
odServer.setPort(0);
odServer.logon("shortrib", "rjrussel", "password");
folder = odServer.openFolder("Baxter Bay");
ODHit hit2 = folder.recreateHit(hit);
System.out.println("Recreated:" + hit2.getDocumentName());
Keep in mind in order for recreate hit to work the user recreating the hit MUST have permissions to the document. If that user doesn't you will still get an error.
Thanks,
RR
133
OD/WEK & JAVA API / Re: ODWek Java API - recreateHit issues
« on: March 12, 2019, 05:49:36 AM »
What version of OnDeamand are you running?
My guess is you need to switch to getOpenDocId() as the docID's are now tied to a user.
Thanks,
RR
My guess is you need to switch to getOpenDocId() as the docID's are now tied to a user.
Thanks,
RR
134
OD/WEK & JAVA API / Re: What is your AFP to PDF Transform of choice?
« on: March 11, 2019, 07:04:49 AM »
Justin,
You left off TargetStream from your list. Another excellent choice for AFP to PDF conversion.
https://targetstream.com/products/streameds/
Thanks,
RR
You left off TargetStream from your list. Another excellent choice for AFP to PDF conversion.
https://targetstream.com/products/streameds/
Thanks,
RR
135
z/OS Server / Re: Automatic User and Group synchronization with LDAP
« on: November 26, 2018, 08:32:45 AM »
Not sure this will answer your question but the subtree is the base DN. For example:
CN=Users,DC=example,DC=com
If you don't know your baseDN you can find it by doing the following from your AD server:
Type the command: dsquery user -name <known username>
The result will look something like: "CN=John.Smith,CN=Users,DC=MyDomain,DC=com"
Based on the above results your base DN would be CN=Users,DC=MyDomain,DC=com
-Rob
CN=Users,DC=example,DC=com
If you don't know your baseDN you can find it by doing the following from your AD server:
Type the command: dsquery user -name <known username>
The result will look something like: "CN=John.Smith,CN=Users,DC=MyDomain,DC=com"
Based on the above results your base DN would be CN=Users,DC=MyDomain,DC=com
-Rob